【精品】可靠的消息传输协议.doc

【精品】可靠的消息传输协议.doc可靠的消息传输协议,有必要吗?作者MarcdeGraauw译者马耀发布于2010年9月2日上午12时0分busnessdocumentWebServiceSendermessagingreliabilitymodulesecuritymoduletransactionmoduleetceteraEnvelopeHeaders:reliabilitysecurityPayload:businessdocumentWebServiceReceiverreliabilrtymodulemessagingsecuritymoduletransactionmoduleetcetera在S0A与Web服务的世界中,一个广为接受的理念是可靠消息传输的必要性。可靠消息传输确保消息发送方发出的消息能到达消息接收方,而且仅到达一次。REST而对的最常见的抵触Z—是,它不提供可靠的消息传输机制-StefanTilkov写道:“常有人提出,RESTfulHTTP里没有与WS-ReliableMessaging(后文简称为WSRM)等价的协议,于是许多人得岀结论,REST不能应用于讲究可靠消息传输的场景中(这等同于儿乎所有跟业务相关的系统)”也。当然,Tilkov不这么认为,他倾向丁•在应用层解决这个问题。JoeGregorio曾在RESTifyDdyTmder中发表过类似的观点[2]。正因为如此,“因为业务的需要,我们才需要可靠消息传输”这样的假设是错误的;而相反的说法“从业务的角度,我们绝对不需耍可靠消息传输”才是合理的。如呆我们有良好设计的业务语义及业务逻辑,独立的可靠消息机制就是多此一举。Web服务与可靠性Web服务提供了隔离消息交换的细节与业务逻辑的机制。其基本构想是通过服务的方式定义业务(譬如,“浏览冃录”,“下订单”,“检查订单状态”,等等)。服务通过业务文档的交换实现,业务文档中包含业务语义。如果我们使用的是Web服务,业务文档就装载在SOAP信封Z中。SOAP信封还包含SOAP头,它实现了一些消息传输的功能:消息安全、一致性、寻址、可靠性等。消息功能间互相独立:即,你完全可以只实现消息完整性也不实现消息可靠性,反Z亦可,二者都要或都不要也没有问题。businessdocument上图概括了以Web服务作为实现手段的若干SOA的重要特征:ReceiverDuplicateMessageProcessMessageAcknowledgement•业务层独立与消息传输层;•Web服务添加了若干独立的“即插即用”的消息传输功能块;•消息头中附带了所需消息传输功能的相关信息。Web服务木身并非总是可靠的。一个基本问题是:以订购一本书为例,假设我发出一条消息,由丁某些网络故障导致消息无法到达H的地,那么我就得不到要买的书。解决该问题仅需重发一次消息,如场景1所示。Seenario1:ResendingworksSender然而,如果消息送达了,但是响应却丢失了,重发就不能解决该问题:如果我已经订购了一本书,我将得到两本同样的书,见场景2。Scenario2:ResendingfailsSenderReceiverMessageAcknowledgementDuplicateMessageAcknowledgementProcessMessageProcessMessag