在我之前的"SOAP Header: 扩展SOAP能力的途径"这篇文章中，按照SOAP规范的约定，给出了两个运用SOAP Header条目对SOAP的能力进行扩充的例子。一般认为，当具体的应用中运用了一些与应用本身关联不是太大而更面向底层控制的服务的时候应当采用SOAP Header来传输这些控制信息，理由是这些服务往往是平台的功能而非具体应用所要实现的功能。按照规范的约定，SOAP Body是专用于交换调用的具体信息，而控制信息的交互应当由SOAP Header来完成。

这样，从体系架构的观点来看，解析SOAP Header的就可以由平台模块来完成，通过插入不同的标准化的SOAP Header条目解析模块来完成不同目的的控制功能。而相应的，解析SOAP Body是由应用模块来完成。这样在开发和部署上将会非常地清晰。

随着SOAP Header扩展的普遍应用和标准的形成，将意味着SOAP技术的真正成熟。

而目前出现的四个新的Web Service规范，正是SOAP Header地扩展，这将有力地推动SOAP技术的成熟化。

这四个Web Service规范是：

1. WS-Security
2. WS-License
3. WS-Routing
4. WS-Referral

在之前的文章"SOAP Header扩展: WS-Security和WS-License"中，我已经介绍了WS-Security和WS-License，在这篇文章中我将继续介绍WS-Routing和WS-Referral。

WS-Routing

Web服务路由规范(WS-Routing)定义了路由SOAP消息的机制。SOAP是一个轻量级的有线传输协议，定义了一系列传输交换机制，用来传输在应用层协议上使用的方法调用。SOAP实际上没有定义从一点发送消息到另一点的机制，即使在它的规范中它引用了一个虚拟的消息路径机制。WS-Routing(以前被称作SOAP路由协议)是一个无状态协议，他扩展了SOAP协议，WS-Routing通过定义一个方法来说明一个预先设计好的路由或传输路径，这个路径将从消息源，经过若干中介，最后到达消息的最终接受者。

回页首

架构组成

通过使用SOAP扩展模型，这个基于SOAP的规范被设计用于和其他一些机制进行组合从而提供一个完善的消息环境。WS-Routing没有定义如何实施可靠的和安全的通讯的方法。不过可以期望其他的SOAP扩展规范来提供这些能力。同时，WS-Routing也不会尝试去超越SOAP，定义新的传输方式。

回页首

目标和非目标

WS-Routing的设计目标是尽量采用最小的额外代价，将一个消息路径封装在SOAP消息里，以使得这个消息包含了足够的信息，用于在Internet上使用诸如TCP和UDP这样的传输协议来实施消息传输。在WS-Routing中，要支持这样一些消息交换机制：

• SOAP message path model，SOAP消息路径模型
• Full-duplex, one-way message patterns，全双工单向的消息模式
• Full-duplex, request-response message patterns，全双工请求/响应消息模式
• Message correlation，消息相关

WS-Routing没有定义如何实施可靠的和安全的通讯的方法。不过可以期望其他的SOAP扩展规范来提供这些能力。同时，WS-Routing也不会尝试去超越SOAP，定义新的传输方式。

细节

WS-Routing定义了一个新的SOAP Header条目和相关的处理模式。为了举例说明这个，首先来考虑这样一个例子， SOAP处理器A希望发送一个SOAP消息给最终接受者D，其中需要通过SOAP中介B然后再通过SOAP中介C，这就像在图1中显示的那样。

为了表示这样的路由WS-Routing定义了一个新的SOAP Header条目，名为"path"以及：

• 代表消息源的"from"元素
• 代表消息最终接受者的"to"元素
• 包含正向消息路径的"fwd"元素
• 包含反向消息路径的"rev"元素

WS-Routing通过定义"rev"元素从而允许双向的消息交换。"fwd"和"rev"元素都包含"via"元素，"via"元素用于描述每一个消息中介(例如B和C)，而"fwd"和"rev"元素包含的其他元素则被用于定义消息的标识、相关性和目的。

下面的示例中描述了上图中SOAP结点A的SOAP处理器可以如何描述消息传输中使用的路径。需要注意的是，结点A没有必要预先知道整个路径，路径可以被动态的发现和修正。(具体细节可参见后面的WS-Referral)

<SOAP-ENV:Envelope
      xmlns:SOAP-ENV="http://www.w3.org/2001/06/soap-envelope">
   <SOAP-ENV:Header>
      <wsrp:path xmlns:wsrp="http://schemas.xmlsoap.org/rp/">
         <wsrp:action>http://www.im.org/chat</wsrp:action>
         <wsrp:to>soap://D.com/some/endpoint</wsrp:to>
         <wsrp:fwd>
            <wsrp:via>soap://B.com</wsrp:via>
            <wsrp:via>soap://C.com</wsrp:via>
         </wsrp:fwd>
         <wsrp:from>soap://A.com/some/endpoint</wsrp:from>
         <wsrp:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</wsrp:id>
      </wsrp:path>
   </SOAP-ENV:Header>
   <SOAP-ENV:Body>
      ...
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

当一个消息沿着传输路径被传输时，沿着传输方向的每一次迁移都会把相关的via元素从"fwd"路径中转移到"rev"路径中去，如此就能动态地建立一条返回发送者的传输路径。除了这个消息处理规则外，WS-Routing还需要处理一些其他的传输处理细节，比如网关、路由相关的SOAP Fault等等。

回页首

包含

由于WS-Routing的描述信息是整个包含在SOAP Header中的，而SOAP消息是自包含和自描述的，因此基于SOAP规范的WS-Routing即为传输独立的。在SOAP中介之间的传输协议和传输方式并没有在WS-Routing中定义；而传输信息的封装则是由传输协议的实现直接提供的(例如，TCP中的TCP包)。WS-Routing定义了对MIME、TCP、UDP和HTTP的绑定，但是，如果你使用SSL、TLS、SOCKs或者其他也是一样的。

WS-Routing支持单向的或请求/响应模式的消息交换。当和双向传输协议一起使用时(如TCP)，我们完全可以在两个方向上分别发送单向消息或请求/响应消息，这和由哪个SOAP处理器初始化底层传输级的连接是彼此独立的。

回页首

相关协议

WS-Routing可以和其他基于SOAP的协议一起使用，从而为安全可靠的消息环境提供完全的服务。特别的，WS-Routing定义的路径SOAP Header可以安全地和WS-Security所定义的SOAP Header组合在一起使用；后者可以涉及消息完整性和(/或)消息机密性的验证。同样的，WS-Routing并不定义任何关于传输可靠性和消息重发的策略。期望可以有其他基于SOAP消息传输可靠性的协议来实现消息传输的可靠性。

回页首

WS-Referral

Web服务指引规范(WS-Referral)是一个基于SOAP的协议，用来配置用于转发消息的SOAP节点(SOAP路由器)中关于消息路径(路由条目)的指令。WS-Referral是与Web服务路由协议(WS-Routing)相正交的协议，它提供了如何配置SOAP路由器以建立一个消息路径的方法，而WS-Routing则提供了描述消息实际路径的机制。

WS-Referral通过提供多种服务，来协助配置消息路径。SOAP路由器除了可以提供诸如高性能负载消息传输、集团防火墙服务等转发服务(relay service)外，还会提供诸如负载平衡、镜像、高速缓存以及客户端认证等Web服务。举例来说，一个Web服务可以将它的部分职能委派给第三方服务，而对于用户而言并不知道这些职能是由第三方负载的。

回页首

架构组成

通过使用SOAP扩展模型，这个基于SOAP的规范被设计用于和其他一些机制进行组合从而提供一个完善的消息环境。WS-Referral没有定义并提供消息安全、路径描述以及服务发现等机制。不过可以期望其他的SOAP扩展规范来提供这些能力。

回页首

目标和非目标

WS-Referral被设计以提供两个功能：第一个是用来管理准静态路由配置，第二个是支持动态路由构造。路由器能够在初始化后配置后得到修正，其中可能包括把消息转发给受委派的第三方服务。因为WS-Referral使用SOAP消息和SOAP Header来交换路由条目，因此它能按照时间量度来更新路由器，而不用考虑下层协议路由表的传播时间。

WS-Referral是可扩展的，他的所有的关键组件都能够通过附加的元素来增强功能。举例来说，我们可以扩展新的元素，当指定的路由条目将要被应用于消息的时候，可以使用新的元素来扩展处理的逻辑。

回页首

指引语句

WS-Referral的基本单位是指引语句，指引语句有5个元素：

1. for: 表示那些计划供指引使用的URI(每个URI称为一个SOAP角色)。
2. if: 描述了指引的接收者必须理解的一组条件，只有理解了这样一组条件，指引才能被使用。
3. go: 如果一个SOAP消息的消息头被标识为该消息是要发向一个SOAP角色的(这个SOAP角色是计划供该指引使用的)，而且那一组条件也被满足了，那么就通过在go元素中罗列的某一个SOAP路由器来发送该消息。
4. desc: 描述了一些附加的信息，这些信息对于使用指引接收者来说并不是一定需要了解的，但也许会被发现很有用。
5. refId: 指引的唯一标识符，依靠这个标识符可以识别一个指引的指定表现形式。

当为了便于描述而将如干指引聚成一组一起描述的时候，每一条指引语句可以被独立评估而无须考虑其他的指引语句。

通过将扩展元素分别归入"if"和"desc"元素可以使那些不理解新元素的SOAP路由器的行为被更细节地控制。举例来说，一个应用通过增加了一个新的"if"条件来扩展WS-Referral的使用，这个条件可能是"仅当这条消息是从bob@corp.com发过来的才使用这个指引"，这就确保了接受者除非能够理解条件，否则不会使用该指引。

WS-Referral只定义了两个强制的"if"条件。第一个是"invalidates"，这个能够用于取消先前的指引交换。第二个是"ttl"，用来设置指引有效性的时间限制。

"desc"元素能用来携带一些对于接收者来说是可选使用的信息。举例来说，对于列在"go"元素里的不同SOAP路由器WS-Referral没有定义固有的规则来区分。如果一个应用想要就如何选择获得一点提示性的线索，如"选择离发送者最近的"，那么他可以在"desc"部分增加一个条件，对于"desc"部分而言，如果接收者无法理解其中的条件，他仍然可以不受影响地只用这个指引。

回页首

消息

指引语句能够通过三种机制来实施交换：

1. 注册消息：这个SOAP消息指示接收者使用附加的指引语句。接收者应当明确地表示接受或拒绝注册。

2. 查询消息：一个SOAP路由器可以被这个SOAP消息来实施对指引的查询。这个消息可以被扩展以允许复杂的查询。

3. 指引头：任何SOAP消息可以扩展使用一个包括指引语句的指引SOAP Header条目。这一特性为SOAP消息交换提供了一种机制，用于将指引添加到现存的消息交换流中。

注册消息和查询消息，一般典型地被管理员用于在传输路径上配置一组SOAP路由器。注册消息提供了一个"push(推)"的方法来更新路由器中SOAP级别的路由表。而查询消息则提供了一个"pull拉"的方法使路由器可以用于了解消息路径的细节。

一个"指引"SOAP Header条目一般用在动态的环境，此时对消息路径的更新将被缓存。作为一个当前存在的消息交换地一部分，一个SOAP路由器将会包含一个"指引"SOAP Header条目以告知发送者一个到达期望的SOAP角色的更好的路径。

回页首

例子

下面通过一个在WS-Referral和WS-Routing之间的交互例子，提供了一个直截了当的方式来说明如何使用WS-Referral。下面的指引将导致一个绑定"soap://b.org"服务的WS-Routing消息的发送者来添加一个附加结点到向前路径中去，具体的，在向前路径的"via"元素中增加一个结点"soap://c.org"。

<r:ref xmlns:r="http://schemas.xmlsoap.org/ws/2001/10/referral">
  <r:for>
    <r:prefix>soap://b.org</r:prefix>
  </r:for>
  <r:if/>
  <r:go>
    <r:via>soap://c.org</r:via>
  </r:go>
  <r:refId>mid:1234@some.host.org</r:refId>
</r:ref>

上面代码中的"prefix"元素意味着任何以其包含的元素内容URI开头的URI都需要被考虑与指引进行匹配。而对于接收者而言是如何使用这个指引的可以参见下面的消息示例。被添加的元素以粗体显示。

<S:Envelope xmlns:S="http://www.w3.org/2001/09/soap-envelope">
  <S:Header>
    <m:path xmlns:m="http://schemas.xmlsoap.org/rp/">
      <m:action>http://www.notification.org/update</m:action>
      <m:to>soap://b.org/service/</m:to>
      <m:fwd>
        <m:via>soap://c.org</m:via>
      </m:fwd>
      <m:from>soap://a.org</m:from>
      <m:id>mid:1001@a.org</m:id>
    </m:path>
  </S:Header>
  <S:Body>
    ...
  </S:Body>
</S:Envelope>

回页首

小结

在本文中介绍了四个新涌现的Web服务规范中的后两个WS-Routing和WS-Referral。WS-Routing定义了路由SOAP消息的机制。而WS-Referral则用来配置用于转发消息的SOAP节点(SOAP路由器)中关于消息路径(路由条目)的指令。这两个基于SOAP的规范被设计用于和其他一些机制进行组合从而提供一个完善的消息环境。

参考资料

• Web Service 技术/评论网站
  • UDDI-China.ORG, 以UDDI为主的Web服务技术网站。
  • WebServices.ORG, Web服务的综合类技术网站。
  • IBM developerWorks/Web Service Zone, IBM的Web服务技术资源中心
  • MSDN Online Web Services Developer Resources, Microsoft的Web服务的开发者资源网站
  • ITPapers/Web Service, ITPapers的Web服务评论文章
  
  
  
• Web服务系列技术标准规范
  • WS-Routing规范, Microsoft, 2001
  • WS-Referral规范, Microsoft, 2001
  • WS-Security规范, Microsoft, 2001
  • WS-License规范, Microsoft, 2001
  • SOAP: Simple Object Access Protocol Specification 1.1, IBM, Microsoft, DevelopMentor, 2000
  • UDDI执行白皮书, UDDI-China.org, UDDI.org
  • UDDI技术白皮书, UDDI-China.org, UDDI.org
  • UDDI程序员API规范, UDDI-China.org, UDDI.org
  • UDDI数据结构参考, UDDI-China.org, UDDI.org
  • Web Service Description Language (WSDL) 1.0, IBM, 25 Sep 2000
  • XML Schema Part 0: Primer, W3C, 2 May 2001
  • Extensible Markup Language (XML) 1.0 (Second Edition), W3C, 6 Oct 2000
  
  
  

关于作者

柴晓路: 系统架构师, Web Service技术顾问, UDDI Advisory Group成员, UDDI规范中文版编辑。专长于Web Service架构、Web Service系列技术以及基于XML的系统集成和数据交换技术，同时对数据库、面向对象技术及CSCW等技术比较擅长。2001年加入 UDDI Advisory Group，参与了UDDI Specification V2的开发。目前作为 UDDI-China.org的主要核心成员参与UDDI-China.org的核心技术工作。2000年获复旦大学计算机科学硕士学位，曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XML Asia/Pacific'99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。

为本文评分

评论

回页首

内容

• WS-Routing
• 架构组成
• 目标和非目标
• 包含
• 相关协议
• WS-Referral
• 架构组成
• 目标和非目标
• 指引语句
• 消息
• 例子
• 小结
• 参考资料
• 关于作者
• 建议