复杂网络环境下数据传输的保证：揭秘WS-RM协议

复杂网络环境下数据传输的保证：揭秘WS-RM协议

2010-3-16

蒋彪 于南京

【为什么需要WS-RM协议】

网络有时候会出现故障，这是 Web 用户必须忍受的，无法更改的事实。不得不点击浏览器上的 Reload 按钮是您必须忍受的烦恼之事，因为您会返回一些不明确的 Internal Server 或者 Server not found 错误。并且对于大多数情况，点击 F5 也是可以的 -- 可能不在 Buy It 页面上，因为您并不知道是否该系统会将您的信用卡刷两次，但是大多数情况下它都工作得非常好。然而，当计算机之间互相对话的时候，它们要执行非常特殊的任务和详细的数据块以实现共享。这些消息丢失任何一个都可能导致严重的后果。例如银行，已经花费了大量的金钱（和时间）来确保他们不同的计算机系统之间的事务/消息从来不会丢失。换句话说，他们想要确保他们的数据可靠地传输到恰当的目的地。因为 Web 服务/简单对象访问协议 (SOAP) 延续了它在整个行业中的扩展使用，以互操作的方式来保证传输的需求对它的成功非常重要。

解决这个问题的一种方法是向服务器发送一个消息并且等候响应。如果在一定的时间以后您并没有收到服务器的响应，再重新发送消息。这种方法中仍然存在问题。首先，如果该消息发送是没有遵照请求-响应消息模式（例如，它们是单向 (one-way) 消息），接收返回的 HTTP 200 或者 202 响应代码并不一定保证服务器收到了消息。在定义中，202 意味着该消息仅仅在 HTTP 层上是 Accepted，但是并不一定被 SOAP 处理器处理。同样，客户端堆栈可能会通过不同的方式来解释单向消息。例如，它可能仅仅打开了连接并且发送了消息，并没有关心发送的成功或者失败（启动并忽略）。

然后，当然，也有一些情况下，客户端注意到错误的相应代码；您不能简单的重试。获取一个并非 HTTP 200 的响应并不能保证服务器没有成功的传递消息。例如，可能服务器获取了该消息并且正确地进行了处理，但是在试图处理响应消息的时候发生了一些错误。由于收到 HTTP 500 响应代码而重新发送消息，服务器将对该消息处理两次，这样可能会产生非常严重的负面影响。

另一种方法需要所有的应用程序消息都具有某种响应消息。这样即使响应消息为空，也将使您能够收到一个消息的确认或者收到信息。请注意这种方法有助于您获得传递的确认（在成功的情况下），但是它并不能帮助解决同样消息发送两次的问题（正如我在上一段中讨论的那样。为了解决这个问题，应用程序必须具备一些逻辑来避免重复消息）。不是不可能但是非常麻烦。在理想情况下，任何解决方案的开发应该在比应用程序低的级别上发生，不去管它而集中于实际的工作中。为保证消息的传递和以前的传递，需要客户端和服务器端进行一些握手。因为 SOAP 的主要的目标之一是在各种 SOAP 堆栈之间的互操作性，这个握手需要行业标准，并且因此，这意味着还需要另一个 WS-* 规范。Web 服务社区有两个规范来解决这个问题：WS-ReliableMessaging (WS-RM) 和 WS-Reliability (WS-R)。

WS-RM的官方资料如下：

http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01-e1.pdf

常见的网络异常问题如下：

1) 如何保证A节点发出的数据会被B接受到

2) 如何保证A节点发出的数据不被恶意篡改

3) 如何保证A节点的数据会完整的被B节点接受，而不会丢失数据包

【WS-RM的技术架构】

如上图所示，首先，ApplicationSource发送一条消息用于建立连接。RM Source接受了该消息并且发送其一次或者多此。经过接受了该消息之后，RM Destination承认它。最后，RM Destination发送消息给Application Destination。

通过以上的信息我们可以发现，WS-RM的做法是把消息的发送和接受交由RM底层来实现，对上级应用程序而言屏蔽掉了传输细节。

下面，我们来看看WS-RM的具体实现细节：

【WS-RM的实现细节】

下面，我们结合上图来看看，具体的WS-RM的消息传传输过程：

1. WS-RM协议，初始化协议链接。包括，建立通信，交互基本信息，建立信任链接。

2. RM Source请求建立一个新的sequence()

3. RM Destination创建了一个新的sequence，并且返回它的标志符，Identifer

4. RM Source在sequence中开始传输消息，并且通过MessageNumber来定义消息的编号

5. RM Source发出的第二条消息在传输中丢失了

6. RM Source发出的第三条消息里面包括了一个”AckRequested”的header，这样就能要求RM Destination确定它是否已经成功接受了所有的信息

7. 作为接收到”AckRequested”的header的反应，RM Destination发送了一个

SequenceAcknowledgement给RM Source，通知它自己只接受到了1,3的消息

8. 作为反响，RM Source再次发送了第二条消息，并且由于该消息的Identifer和前面两个一样，所以RM Destination就会把它编入自己的之前收到的两条信息中。同时，该消息中又包括了”AckRequested”的header

9. RM Destination收到了再次发送的第二条信息，于是发出确认信息给RM Source，告知它已经完全接受到了1,2,3信息

10. RM Source收到确认信息之后，发出”TerminateSequence”，通知RM Destination本次消息发送已经结束。

11. RM Destination收到”TerminateSequence”之后，发送” TerminateSequenceResponse”给RM Source，并且回收本次通信的所有资源

【WS-RM协议的具体元素】

WS-RM中所有的动作都是依靠SOAP消息来驱动的，下面就介绍常用的SOAP元素。

1. 创建sequence()

2. 关闭sequence()

3. 中止sequence(Sequence Termination)

4. sequence

5. Request Ackownledgement

6. Sequence Ackownledgement

【结论】

WS-RM是一种屏蔽网络传输细节，解决网络传输异常的好方法。它由IBM,MS等大公司提出，经过论证成为标准协议。它的技术实现主要通过多次握手协议来完成。国外主要的研究团队集中在Sun,IBM,MS。国内的目前除了富士通还不多。

下面提供一些WS-RM的资料：

1) WS-RM的演示工具

http://www.alphaworks.ibm.com/tech/ettk

2) Sun公司的WS-RM协议实现源代码

https://metro.dev.java.net/2.0/metro-2_0.zip

另外提一下，Sun公司主要实现WS-RM协议的科学家和我有经常的联系，也希望国内对此新技术感兴趣的同仁多和我交流。

#以上#

以下WebService研究相关文章，欢迎大家访问

========================================================

《Web Service技术内幕 》
http://blog.csdn.net/nanjingjiangbiao/archive/2010/02/25/5325361.aspx
《深入浅出JAX-WS 2.0》
http://blog.csdn.net/nanjingjiangbiao/archive/2010/02/11/5306034.aspx
《SOA技术研究之 图解JAX-WS技术》
http://blog.csdn.net/nanjingjiangbiao/archive/2010/02/10/5305049.aspx
《手把手教你在Interstage上部署WebService》
http://blog.csdn.net/nanjingjiangbiao/archive/2010/02/22/5317356.aspx

========================================================