SOAP应用模式: 高级消息交换模式
2002 年 7 月 01 日
SOAP应用模式是一个由四篇文章组成的系列，主要讨论的是如何将SOAP应用到各种各样的应用环境中去。本文是系列的第三篇，讨论一些基于基本的消息交换模式而又进一步面向应用特化的方面，包括会话、异步消息和事件通知等。
<!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --><!--END RESERVED FOR FUTURE USE INCLUDE FILES-->
在商业伙伴之间的交互经常是远远比一个简单的请求/响应消息交换要复杂地多。举例来说，一个长时间运行的消息交换可能是用于实现诸如商品和服务的采购这样商业交互。在这种情况下，将多个个体形式出现的消息组成一个长时间的消息交换集可以带来很多实现上的好处。这样一种多次的消息交换的形式就是我们所熟知的会话。会话可以在一对交易伙伴之间长时间地继续。一个会话实例可能需要几天、几周甚至几个月来才能完成。
在两个交易伙伴之间的会话可以被类似ebXML交易伙伴协定(Trading Partner Agreement, TPA)这样的共享的构造信息来定义。一个交易伙伴协定(TPA)所包含的信息有诸如期望的响应次数、每个交易方承诺完成的商务流程的动作、安全信息以及消息内容结构等。在一个采购进程中，一个会话 实力可以是：
所有的这些消息交换的例子都是与TPA的实例相关的，这个TPA是在这两个参与者之间达成的。如果一个消息需要合法地作为约定规则的一部分，那么每一个参与方都需要去检验当前的消息是否是在TPA范围内合法。
图 1所展示的这个应用模式可以按照如下的方式来实现。每个参与者的SOAP处理器都能够访问一个按照TPA协定而配置的数据库，TPC协定是在两个参与者之间达成的。SOAP发送者中的会话状态处理模块负责处理的SOAP Header条目中包含的信息，能够表示该条目所在的消息是会话实例的一部分。而对等的SOAP接收者的相应的会话状态处理模块则使用发送者提供的信息来测试收到的消息是否是遵照TPA的规则的。该测试过程具体的是通过检查它自己的规则数据库来实现的，这个数据库里保存着每个当前活跃的会话实例的状态信息。如果当前消息违背了TPA的规则，那么应用程序可以产生一个错误。
需要注意的是，图 1中并没有包含一些用于处理其他的SOAP Header条目的处理模块，因此在TPA协约下所需要的可靠性或是安全性等特性并没有在该图中体现。
下面将给出的是一个请求和响应消息的例子，其中使用了一个名为ConversationState的SPAP Header条目来用于标识管理两个交易伙伴之间消息交换的协定，具体的，是使用AgreementId元素。为了支持在统一协定下的多个并发会话，在 ConversationState SPAP Header条目下还包含了另一个用于标识会话的ConversationId元素。在一个特定的会话交换的整个生命周期中，AgreementId元素和ConversationId元素的值将保持不变，同时将 即在请求消息中出现，也在响应消息中出现。
?
?
细心的读者应该已经发现，图2所展示的实现模式与我们曾经介绍过的请求/响应模式基本上是相同的。其唯一的不同点，是请求消息与响应消息在发生时间上是分离的，并且是以两个单向消息来实现的。其中，SOAP发送方的应用程序在发送完SOAP消息之后并不会阻塞并等待响应消息的返回。当最终的响应消息的接收者(不一定是初始的消息发送者，这我们一开始就指出了这一点)收到响应消息后，SOAP发送方的应用程序将会通知初始的SOAP发送应用程序。然后它就可以使用接收到的消息中的关联信息与之前发送的某个SOAP消息达成关联。
图2展示了一个可能的实现。对于请求消息中，消息标识处理器会生成一个唯一的消息标识并将其插入到一个SOAP Header条目中。这作为SOAP请求消息的一部分从SOAP应用程序A发送到SOAP应用程序B。然后SOAP接收者方的商业应用程序将处理这个请求消息，并装配响应消息。其中也将包括一个SOAP Header条目，该条目由消息关联处理器构建，它负责将响应消息与其相关的请求消息设置连接语义。
?
?
回页首
?
本模式描述了一个使用订阅机制的事件通知。这个模式实现使用了在先前我们介绍过的请求/响应模式注册了一个订阅，同时可以使用面向多个接收者的"Fire-and-forget"模式所描述的机制来分发事件通知。图3展示了通过使用一个订阅请求处理器，是如何通过请求/相应消息模式来注册对一组事件的订阅的。具体的注册的过程是由订阅服务来完成的。订阅注册成功与否将被返回给请求订阅的应用程序，具体的，是通过订阅应答处理器来实现的，订阅应答处理器包含了一个提供给请求订阅的应用程序的订阅应答。
将事件通知传输给一组订阅者的过程可以通过使用面向多个接收者的"Fire-and-forget"模式来实现。订阅服务首先需要给出所有订阅了指定事件的有效应用程序的列表，该列表将可能被转换成一个组地址(group address)或是一个分发列表，以支持应用"Fire-and-forget"模式。
同时，一个订阅请求中可以包含一个事件的列表，以减少交互的次数，具体的，是使用SOAP Body来包含这个列表的。在下面的例子代码 7 70中，是实施了对股票价格通知服务的订阅注册。请求订阅的应用程序将能够接受到来自股票价格通知服务的关于BigCo公司的股票价格、成交量以及成交价大于100的时间。
?
而相应的订阅应答包含了一个关于订阅的标识，具体可参见：
?
这个标识将在后继的作为订阅结构的事件通知中被使用。
?
参考资料
SOAP Version 1.2, W3C Working Draft 9 July 2001原文：http://www.ibm.com/developerworks/cn/xml/x-soapapp/part3/
