Message Endpoint及其相关模式

 

 

在ESB中另外一个重要的课题就是Message Endpoint，这是关于一个应用程序如何连接到一个消息系统，并通过它来发送和接收消息。如果你在面向一个消息API编程，则你就正在开发一个endpoint代码。商业中间件通常都提供了这些工具。

 

l         Messaging Gateway

l         Messaging Mapper

l         Transactional Client

l         Polling Consumer

l         Event-Driven Consumer

l         Competing Consumers

l         Message Dispatcher

l         Selective Consumer

l         Durable Subscriber

l         Idempotent Receiver

l         Service Activator

 

发送和接收模式


有些endpoint模式既可以使用在发送方也可以使用在接受方。它们描述一个应用连接一个消息系统的一般情况。

 

包装消息代码 － 一个应用不应该意识到正在使用消息同另外一个应用程序通讯，大多数应用代码应该在不知道message的情况下被编写。在应用集成的地方，应该有一个薄薄的一层代码来执行应用的集成部分。当集成是由消息实现的，这层将应用连接到消息系统的代码称为一个Message Gateway

 

数据转换 － 当发送者和接受者使用不同的数据格式，或者不同的消息格式（支持不同的发送和接收者），在这种情况下，使用一个Message Mapper来在应用格式和消息格式之间转换数据。

 

外部控制的事务 － 消息系统在内部和外部使用事务，默认的，每个发送和接收方法在他们自己的事务中运行。Message生产者和消费者应可选的使用一个Transactional Client来控制事务，当你需要将几个消息一起发送伙通过其他事务服务整理消息时是很有用的。

 

消息消费者模式

 

其他endpoint模式只适用于消息消费者，发送消息是简单的。棘手的问题是决定一个消息应该何时发送，它应包含什么，以及怎样将它送到接受者 － 这是为什么我们有很多消息结构模式 － 但是一旦消息被构建，发送它是很容易的。另一方面，接收消息 － 很麻烦。因此许多endpoint模式是关于接收消息的。

 

接收消息的一个最重要的主题就是流量控制：一个应用控制，或者调节它消费消息的速度。一个潜在的问题是任何server都面临着大量的客户端请求会使其超载。通过远程过程调用（RPI），server几乎受到客户端调用的支配。同样的，通过消息，server不能控制客户端发送请求的速度 － 但是server可是控制它处理这些请求的速度。应用不必像消息系统传送消息那么快的接收并处理消息；使用一个Message Channel可以使它在一个可接收的速率上处理消息。然而，当消息积累太多，而server还有资源可以处理的更快，它可以使用同步message消费者来加快速度。所以使用这些消息消费者模式可以让你的应用将速度控制在它可以承受的范围。

 

许多消息消费者模式都是成对出现的，你可以任选一个使用。

 

同步或异步接受者 － 可以使用轮询消费者或一个事件驱动消费者。轮询提供最好的流量控制，因为如果server忙，则它不再继续轮询消息，所以message将阻塞在队列。事件驱动的消费者倾向于消息到达便触发处理，所以有可能会使server超载，但是每个消费者每次只处理一个消息，所以限制消费者的数量可以有效的控制消费速度。

 

消息分派 vs 消息获取 － 另外一个二选一的模式是一堆消费者如何处理一堆消息。如果每个消费者获得一个消息，他们可以并行的处理消息。最简单的方法是Competing Consumers，也就是一个点对点的channel有多个消费者。每个都可能获得任何消息；消息系统的实现决定那个消费者获得消息。如果你想控制消息到消费者的匹配过程，使用Message Dispatcher。这时只有一个消费者接收消息，但是将委派消息到一个执行者去处理。一个应用程序可以通过限制消费者或执行者的数量来控制流量。当然，分派者Message Dispatcher也可以实现一个流量控制行为。

 

接收所有消息或者过滤 － 默认的，任何到达一个Message Channel的消息对于监听着这个channel的Message Endpoint都是可用的。然而有些消费者并不打算处理channel上的任何消息，而是希望只处理其中几种。这样一个识别的消费者可以使用一个Selective Consumer来描述它将接收什么类型的消息。然后消息系统将只将匹配的消息对该接受者描述为可用。

 

当断开连接的时候订阅消息 － Publish-Subscribe Channels带来的问题是，如果一个消费者感兴趣一个channel，但是现在网络是断开的怎么办？是不是一个未连接的应用将错过发布的消息，即使它已经订阅过该消息?默认的，是的，订阅只对连接的订阅者有效，为了使应用不会因为连接而错过订阅的消息，要使用Durable Subscriber。

 

等幂 － 有时一个消息可能被传输不只一次，可能因为消息系统不确定该消息是否已经被成功的传递过，或者可能因为Message Channel的QoS被设置较低来提高效率。另一面的，消息接受者认为每个消息只会被传输一次，并且当它们重复处理相同的消息，它们会出错。一个Idempotent Receiver可以优雅的处理重复的消息，并且阻止它们引起接收者应用的发生错误。

 

同步或异步服务 － 另外一个选择是一个应用应该暴露它的service为同步（RPI）还是异步的（Messaging）。不同的客户端可能喜欢不同的方式；不同的环境可能需要不同的方式。既然很难选择，就一起使用。一个Service Activator连接一个Message Channel到一个应用的同步服务以便当一个消息被接收，service就被调用。同步客户端可以简单的直接调用service；异步客户端可以通过发送消息调用service。

 

Message Endpoint的相关主题

 

Message Endpoint的另外一个重要主题是很难同其他模式共同应用Transactional Client。Event-Driven Consumer通常不能适当的在外部控制事务，Message Dispatcher也必须小心的设计这个问题，Competing Consumers的事务也是个重大问题。最安全的使用Transactional Client是使用一个单独的Polling Consumer，但是这不会是一个令人满意的解决方案。

 

这里特别要提到应该会保证成功的JMS风格的MDB，EJB的一种。一个MDB是一个消息消费者，它即使一个Event-Driven Consumer又是一个支持J2EE分布式事务的Transactional Client，并且它可以作为Competing Consumers动态的池化，甚至作为一个Publish-Subscribe Channel。这是在一个自由的应用中实现这些是一个困难且乏味的组合，但是这个功能作为一个EJB容器的内建的功能被提供。（MDB框架如何实现的？本质上，容器通过一个动态改变大小的可重用的执行者的线程池来实现了一个Message Dispatcher，在那里每个执行者自己使用自己的session和事务来消费消息。）

 

最后，紧记一个单独的Message Endpoint可以很好结合几个不同的模式。一组Competing Consumers可以被作为Polling Consumers实现，同时也可以是一个Selective Consumers并且可以作为一个Service Activator调用一个应用的service。

一个Message Dispatcher可以是一个Event-Driven Consumer和一个使用Messaging Mapper的一个Durable Subscriber。无论一个endpoint实现什么模式，它总是一个Messaging Gateway。所以，不要考虑使用哪种模式 － 而要考虑如何结合他们。这是使用模式解决问题的魅力所在。

 

要实现一个Message Endpoint有很多选择。Message Endpoint模式用于解释这些选择是什么以及如何最好的使用它们。