随笔 - 59, 文章 - 4, 评论 - 184, 引用 - 7
数据加载中……

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


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

 

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

 

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

 

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

 

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

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

 

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

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

 

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

 

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

 

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

 

posted on 2005-11-19 20:31 fisher 阅读(1387) 评论(6)  编辑  收藏 所属分类: Programing

评论

# 【ESB专题】之三 - Message Construction及其相关模式 [TrackBack]  回复  更多评论   

当两个应用想要交换数据,他们将数据包装在一个message中。但是一个Message Channel不能传输原始数据,它只能传输包含在一个message中的数据(即传输特定格式的数据)。

[引用提示]fisher on csdn 引用了该文章, 地址: http://blog.csdn.net/flyingbug/archive/2005/11/19/533102.aspx
2005-11-19 20:39 | fisher on csdn

# re: 【ESB专题】之三 - Message Construction及其相关模式  回复  更多评论   

好文,我也正想研究EAI平台,其中ESB则是EAI平台的核心,期待你的后文,
另:能否多讲一些有关IBM MQ的消息中间件,在大型企业应用中,往往都采用的是MQ渠道,毕境简单的基于SOAP连接的WEB SERVICE拥有先天缺陷---无法共享连接.
2005-11-21 11:23 | langds

# re: 【ESB专题】之三 - Message Construction及其相关模式  回复  更多评论   

呵呵,没用过MQ,所以没办法写关于MQ的内容了
我想SOAP的好处是基于XML的标准提供了互通的平台,并且它在消息转换、元数据交换以及安全方面都提供了标准的做法,我认为SOAP是一个很有前途的集成手段
SOAP的缺陷是由Http协议的基于请求的、无状态的特性决定的,这也没办法
但是可以通过一些设计模式来适当的改变这种状态,比如使用Cache
或硬性的保持一个通知连接等机制
2005-11-21 21:55 | fisher

# re: 【ESB专题】之三 - Message Construction及其相关模式  回复  更多评论   

是的,不论怎么样,在SOA应用架构下,基于SOAP协议的交互的确是相当重要的,因此才出现了面向消息的SOA实现,这就会在ESB里的消息通迅模式里解决.而IBM的MQ则是比较好的方案了
2005-11-22 10:04 | langds

# re: 【ESB专题】之三 - Message Construction及其相关模式  回复  更多评论   

呵呵,我个人感觉Message Queue并非什么神奇的技术,而且也不是普遍适用的技术
其实真正通用的整合标准就只有两个:Http和Socket
SOAP是Http上的技术,Socket则是十年前的整合标准
无论使用哪一种都一样

基于Socket的整合的中间件我都是自己写的,所以我没有用过MQ
只要通讯基础框架写的好,支持什么样协议我想都不是大问题^_^
2005-11-22 10:12 | fisher

# re: 【ESB专题】之三 - Message Construction及其相关模式  回复  更多评论   

MQ还是很好用的,值得研究一下。高率,稳定,事务保证,简单的开发接口,优点不少,
2007-03-09 16:03 | linan

只有注册用户登录后才能发表评论。


网站导航: