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-->

基于会话的消息交换

 

在基于会话的消息交换模式下，两个会话的参与者将进行一个长时间的会话进程，其中将包含多次消息交换。这种进程的例子可以是复杂的供应链管理、动态的制造日程安排或是信息修复等。在相同的两个参与者之间，可能会有同一个进程的多个实例存在。

Figure 1.?? 基于会话的消息交换

在商业伙伴之间的交互经常是远远比一个简单的请求/响应消息交换要复杂地多。举例来说，一个长时间运行的消息交换可能是用于实现诸如商品和服务的采购这样商业交互。在这种情况下，将多个个体形式出现的消息组成一个长时间的消息交换集可以带来很多实现上的好处。这样一种多次的消息交换的形式就是我们所熟知的会话。会话可以在一对交易伙伴之间长时间地继续。一个会话实例可能需要几天、几周甚至几个月来才能完成。

在两个交易伙伴之间的会话可以被类似ebXML交易伙伴协定(Trading Partner Agreement, TPA)这样的共享的构造信息来定义。一个交易伙伴协定(TPA)所包含的信息有诸如期望的响应次数、每个交易方承诺完成的商务流程的动作、安全信息以及消息内容结构等。在一个采购进程中，一个会话 实力可以是：

1. 一个买家向卖家发出对一些商品的报价请求，卖家响应了商品报价；
2. 买家发出了一个采购订单，卖家接收了这个订单；
3. 卖家通知买家交货的日期，而买家接收了这个通知；
4. 买家确认了商品已经送达，卖家收到了这一确认；
5. 买家提供对商品的支付，卖家发出收据响应。

所有的这些消息交换的例子都是与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元素的值将保持不变，同时将 即在请求消息中出现，也在响应消息中出现。

 

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
   <env:Header>
     <n:ConversationState xmlns:n="http://example.org/conversation">
       <n:AgreementId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6
         </n:AgreementId>
       <n:ConversationId>uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j
         </n:ConversationId>
     </n:ConversationState>
   </env:Header>
   <env:Body>
      <productQuoteRequest>…………</productQuoteRequest>
      -----
   </env:Body>
 </env:Envelope>

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
   <env:Header>
     <n:ConversationState xmlns:n="http://example.org/conversation">
       <n:AgreementId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6
         </n:AgreementId>
       <n:ConversationId>uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j
         </n:ConversationId>
     </n:ConversationState>
   </env:Header>
   <env:Body>
      <productQuoteResponse>…………</productQuoteResponse>
      -----
   </env:Body>
 </env:Envelope>

回页首

 

异步消息

 

在异步消息模式下，发送者以异步方式将消息发往接收者，同时期望在一段时间之后获取一些响应。其中，发送者为请求分配了一个标识，并标注了这个请求，这样之后的响应就可以使用这个标识与初始请求进行关联。同时，发送者也可以为请求分配了属于其他服务的一个标识，而这个服务将作为最终的响应的接收者，也就是说，响应并不一定会发回给发送者。

Figure 2.?? 异步消息模式

细心的读者应该已经发现，图2所展示的实现模式与我们曾经介绍过的请求/响应模式基本上是相同的。其唯一的不同点，是请求消息与响应消息在发生时间上是分离的，并且是以两个单向消息来实现的。其中，SOAP发送方的应用程序在发送完SOAP消息之后并不会阻塞并等待响应消息的返回。当最终的响应消息的接收者(不一定是初始的消息发送者，这我们一开始就指出了这一点)收到响应消息后，SOAP发送方的应用程序将会通知初始的SOAP发送应用程序。然后它就可以使用接收到的消息中的关联信息与之前发送的某个SOAP消息达成关联。

图2展示了一个可能的实现。对于请求消息中，消息标识处理器会生成一个唯一的消息标识并将其插入到一个SOAP Header条目中。这作为SOAP请求消息的一部分从SOAP应用程序A发送到SOAP应用程序B。然后SOAP接收者方的商业应用程序将处理这个请求消息，并装配响应消息。其中也将包括一个SOAP Header条目，该条目由消息关联处理器构建，它负责将响应消息与其相关的请求消息设置连接语义。

 

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
   <env:Header>
     <n:MsgHeader xmlns:n="http://example.org/requestresponse">
       <n:MessageId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6
         </n:MessageId>
     </n:MsgHeader>
   </env:Header>
   <env:Body>
      -----
   </env:Body>
</env:Envelope>

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
   <env:Header>
     <n:MsgHeader xmlns:n="http://example.org/requestresponse">
       <n:MessageId>uuid:09233523-567b-2891-b623-9dke28yod7m9
         </n:MessageId>
       <n:ResponseTo>uuid:09233523-345b-4351-b623-5dsf35sgs5d6
         </n:ResponseTo>
     </n:MsgHeader>
   </env:Header>
   <env:Body>
      -----
   </env:Body>
</env:Envelope>

回页首

 

多消息异步响应模式

 

在多消息异步响应模式下，应用程序向服务器以异步方式请求信息，依请求而给出的返回结果将在一段时间之后以多个响应消息的形式返回。这样的应用模式常常发生在被请求的信息无法一次被完整提供而又需要保证较好的系统性能的场合下，比如象分布式Web搜索这样的应用。

本节所介绍的多消息异步响应模式是异步消息模式的一个扩展。在异步消息模式中仅有一个响应消息，而本节的模式中，结束到请求消息的应用程序将会返回多个响应消息。多消息异步响应模式的实现示例的基本架构与异步消息模式中给出的实现示例是基本一致的，他们使用了相同的消息关联机制来关联请求消息和响应消息。而为了实现多消息响应，我们可以通过使用一个称为序列化处理器的模块来支持这一特性。序列化处理器确保在每一个响应消息中插入一个唯一的序列号。如果负责返回响应消息的应用程序预先就知道将会生成多少响应消息的话，那么序列化处理器可以使用"N of M"的格式(例如1 of 3, 3 of 3等)来指明有多少响应消息将被返回，以及当前的消息是处于序列中的哪个位置。下面给出了消息示例。

 

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
   <env:Header>
     <n:MsgHeader xmlns:n="http://example.org/requestresponse">
       <n:MessageId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6
         </n:MessageId>
     </n:MsgHeader>
   </env:Header>
   <env:Body>
      -----
   </env:Body>
</env:Envelope>

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
   <env:Header>
     <n:MsgHeader xmlns:n="http://example.org/requestresponse">
       <!-- MessageId will be unique for each response message -->
       <!-- ResponseTo will be constant for each response message
             in the sequence-->
       <n:MessageId>uuid:09233523-567b-2891-b623-9dke28yod7m9
         </n:MessageId>
       <n:ResponseTo>uuid:09233523-345b-4351-b623-5dsf35sgs5d6
         </n:ResponseTo>
     </n:MsgHeader>
   <s:Sequence xmlns:s="http://example.org/sequence">
     <s:SequenceNumber>1</s:SequenceNumber>
     <s:TotalInSequence>5</s:TotalInSequence>
   </s:Sequence>
   </env:Header>
   <env:Body>
      -----
   </env:Body>
</env:Envelope>

回页首

 

事件通知

 

在事件通知模式下，应用程序向一个事件源(event source)订阅了一些具有明确名称的事件(event)的事件通知。当被订阅的事件发生后，如果通知是被发送给最初的发出订阅请求的应用程序的话，那么称为单方订阅，如果通知是被发送给其他应用程序的话，那么称为第三方订阅。例如，一个应用程序可以向打印机驱动程序发出关于打印机状态变化(例如，缺纸、缺墨等)的事件订阅请求，而这些事件的通知可以发送给另一个系统管理程序。

Figure 3.?? 事件通知模式

本模式描述了一个使用订阅机制的事件通知。这个模式实现使用了在先前我们介绍过的请求/响应模式注册了一个订阅，同时可以使用面向多个接收者的"Fire-and-forget"模式所描述的机制来分发事件通知。图3展示了通过使用一个订阅请求处理器，是如何通过请求/相应消息模式来注册对一组事件的订阅的。具体的注册的过程是由订阅服务来完成的。订阅注册成功与否将被返回给请求订阅的应用程序，具体的，是通过订阅应答处理器来实现的，订阅应答处理器包含了一个提供给请求订阅的应用程序的订阅应答。

将事件通知传输给一组订阅者的过程可以通过使用面向多个接收者的"Fire-and-forget"模式来实现。订阅服务首先需要给出所有订阅了指定事件的有效应用程序的列表，该列表将可能被转换成一个组地址(group address)或是一个分发列表，以支持应用"Fire-and-forget"模式。

同时，一个订阅请求中可以包含一个事件的列表，以减少交互的次数，具体的，是使用SOAP Body来包含这个列表的。在下面的例子代码 7 70中，是实施了对股票价格通知服务的订阅注册。请求订阅的应用程序将能够接受到来自股票价格通知服务的关于BigCo公司的股票价格、成交量以及成交价大于100的时间。

 

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
  <env:Body>
    <s:StockNotificationSubscription
          xmlns:s="http://example.org/2001/06/subscribe">
      <s:Notify>PRICE</s:Notify>
      <s:Notify>VOLUME</s:Notfy>
      <s:Notify>TIMESTAMP</s:Notfy>
      <s:When>
        <s:Company>BigCo</s:Company>
        <s:Price range="GreaterThan">100</s:Price>
      </s:When>
    </s:StockNotificationSubscription>
  </env:Body>
</env:Envelope>

而相应的订阅应答包含了一个关于订阅的标识，具体可参见：

 

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
  <env:Body>
    <s:StockNotificationSubscriptionAck
        xmlns:s="http://example.org/2001/06/subscribe">
      <s:SubscriptionId> uuid:40195729-sj20-pso3-1092-p20dj28rk104
        </s:SubscriptionId>
    </s:StockNotificationSubscriptionAck>
  </env:Body>
</env:Envelope>

这个标识将在后继的作为订阅结构的事件通知中被使用。

 

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
  <env:Body>
    <n:StockNotification
         xmlns:n="http://example.org/2001/06/notification">
      <n:SubscriptionId> uuid:40195729-sj20-pso3-1092-p20dj28rk104
         </n:SubscriptionId>
      <n:Company>BigCo</n:Company>
      <n:Price>100.56</n:Price>
      <n:Volume>102345</n:Volume>
      <n:Timestamp>2001-03-09T12:22:30Z</n:Timestamp>
    </n:StockNotification>
  </env:Body>
</env:Envelope>

参考资料

• SOAP Version 1.2, W3C Working Draft 9 July 2001
  
  
• SOAP Version 1.2 中文版, W3C Working Draft 9 July 2001/UDDI-China Translation
  
  
• Apache SOAP, Apache XML Project
  

原文：http://www.ibm.com/developerworks/cn/xml/x-soapapp/part3/