【ESB专题】之三 － Message Construction及其相关模式

在前面的关键组件中我们提到了Messages。当两个应用想要交换数据，他们将数据包装在一个message中。但是一个Message Channel不能传输原始数据，它只能传输包含在一个message中的数据（即传输特定格式的数据）。

<!----><o:p> </o:p>

Message在消息系统中处于信息载体的位置，而在ESB中，还消息识别、序列以及生存周期等职责。

<o:p> </o:p>

Message的结构涉及以下几个模式：

l         Command Message      

l         Document Message      

l         Event Message

l         Request-Reply

l         Return Address

l         Correlation Identifier

l         Message Sequence

l         Message Expiration

l         Format Indicator

<o:p> </o:p>

创建和发送一个Message产生以下几个问题：

<o:p> </o:p>

消息意图 － Message最终是为了运送一些数据，但是发送者可能有其他目的，比如它希望接受者使用消息做些事情。它可以发送一个Command Message，指定它希望调用的接受者上的函数或方法。发送者告诉接受者运行那些代码。发送者可以发送一个Document Message来传送它的数据结构到接受者。发送者发送数据到接受者，但是不指定接受者应该做什么。

或者它可以发送一个Event Message，通知接受者发送者那里有一个改变。发送者不应告诉接受者应该怎样适应这个改变，而只应提供通知。

<o:p> </o:p>

返回一个应答 － 当一个应用发送一个消息，它通常期望得到一个回应来确定消息被处理并提供一个结果。这是一个Request-Reply场景。Request通常是一个Command Message，而应答是一个包含返回值或异常的Document Message。请求者应该在请求中指定一个Return Address来告诉应答者使用哪个通道来传回应答。请求者可能在一个处理过程中发送多个请求，所以应答应该包含一个Correlation Identifier来指出这个应答对应哪个请求。

有两个Request-Reply场景需要注意；它们都包含了一个Command Message请求和一个对应的Document Message应答。在第一个场景中，Message RPC，请求不但要调用应答者的函数，而且期望一个返回值。这是RPC。另一个场景中，Message Query，请求者执行一个查询；应答者执行查询并在应答中返回结果。这是远程查询。

<o:p> </o:p>

大量的数据 － 有时应用想要传送大量的数据结构，放入一个单独的message里面不是很合适。在这种情况下，将他们分解成可管理的消息块并将他们作为Message Sequence发送。这些消息必须按顺序发送，以便接受者能够充足原始数据结构。

<o:p> </o:p>

慢速消息 － 消息系统的一个问题是发送者通常不知道接受者要多久才能接受到消息。然而，消息的内容可能是时间敏感的，所以如果消息在某一时间内没有被接受，它将被忽略并取消。在这种情况下，sender应该使用Message Expiration来指定一个到期时间。如果消息系统在规定时间内无法传输一个消息，应该将它取消并删除到Dead Letter Channel中。同样的一个receiver接受到一个超出该时间点的消息，也要取消该消息。

<o:p> </o:p>

总之，只选择使用消息是不够的。使一个消息工作的其他决定性因素来自于消息所要完成的任务。

<o:p> </o:p>