使命必达: 深入剖析WCF的可靠会话[原理揭秘篇](下)

长平狐 发布于 2012/09/04 11:22
阅读 118
收藏 0

上面一部分我们站在信道层的角度剖析了WCF为了实现可靠会话在信道层进行的一系列消息交换,或者说客户端和服务端的RS信道为了实现可靠消息传输所进行一轮又一轮的握手。这一切都是基于这样一个假设:两个RS信道均可以在适当的时机向对方发送消息,或者说两个RS信道之间是一个双工的通道

如果我们站在传输层看待这个问题,该假设对于TCP传输是成立的,但是对于HTTP来说就有点问题了。HTTP本身就是一个基于请求|回复消息交换模式的应用层网络协议,并不能对双工通信提供支持。而WCF通过WSDualHttpBinding实现的双工通信机制和NetTcpBinding支持的双工通信具有本质的区别。NetTcpBinding创建的传输通道就是一个双工的TCP连接,而WSDualHttpBinding创建的所谓的双工通道实际上是两个方向相反的HTTP连接。接下来我们主要讨论当我们采用基于HTTP绑定——WSHttpBinding(或者是WS2007HttpBinding)和WSDualHttpBinding)时,实现可靠会话所进行的通信方式。

一、WSHttpBinding V.S. WSDualHttpBinding

如果采用WSHttpBinding,最终创建的是一条从客户端到服务端的HTTP通道。在这种情况下,客户端RS信道和服务RS信道之间的多轮握手(CreateSequence/ CreateSequenceResponse、Sequence/ SequenceAcknowledgement、CloseSequence/CloseSequence和TerminateSequence/TerminateSequenceResponse)均是采用这样的消息交换方式:客户端将相应的消息通过HTTP请求的形式发送到服务端,相应的回复或者确认通过HTTP回复返回图1揭示了上述的几次握手在传输层上的实现,其中实线部分代表HTTP请求,虚线部分代表HTTP回复。

clip_image002

图1 可靠会话基于通过WSHttpBinding创建的单通道的消息交换

图1中我们可以和清晰地看到,CreateSequence/ CreateSequenceResponse、CloseSequence/CloseSequence和TerminateSequence/TerminateSequenceResponse完全是按照HTTP请求/HTTP回复的形式实现的在进行服务调用的时候,即使采用的单向消息交换模式,发送应用消息的请求依然会接收到一个包含SOAP消息的HTTP回复。服务端通过将确认消息方法每一个HTTP回复之中

之所以采用如上的方式的根本目的在于,WSHttpBinding创建的传输层通道是从客户端到服务端的一条HTTP连接。HTTP连接是一条单工通道,客户端和服务端总是扮演者请求者和回复者的角色,服务端不能主动联系客户端,此外无论是对RM序列创建、关闭和中指的回复,还是消息确认只能放在HTTP回复中。

但是,如果我们采用WSDualHttpBinding作为终结点绑定,情况就大不一样了。由于WSDualHttpBinding会创建两条HTTP连接构成一个所谓的双工通道,服务端可以随时联系到客户端,不需要将相应的回馈通过HTTP回复随带捎回去。借助于WSDualHttpBinding创建的双工通道,可靠会话的上述握手采用如下的消息交换方式:客户端通过HTTP请求将RM序列创建、终止请求以及携带Sequence报头的应用消息发送给服务端,并得到一个状态为202的空HTTP回复。而真正的回复和消息确认都通过另一个HTTP连接的HTTP请求返回给客户端的,而这些HTTP请求通过会得到一个状态为202的空HTTP回复

图2是对可靠会话消息交换在传输层的反映。可能你会觉得这和我们上面介绍的WS-RM消息交换模式不一致,没有了CloseSequence/CloseSequence握手,对于TerminateSequence请求也没有相应的TerminateSequenceResponse回复,这是因为WSDualHttpBinding支持的WS-RM版本是1.0,而不是我们上面介绍的1.1。除了上述的两点不同之前,还有一个不一样的地方:客户端在发送RM序列终止请求之前会发送一个携带Sequence报头的空消息,而对于包含在该空消息中的Sequence报头,除了包含消息序号之外,还具有一个额外的LastMessage元素表明这是RM序列终止前的最后一个消息。关于WS-RM 1.0,限于篇幅的因素,在本书中不可能再进行深入的介绍,有兴趣的读者可以参阅OASIS官方文档。

clip_image004

图2 可靠会话基于通过WSDualHttpBinding创建的双通道的消息交换

我们也可以从另外一种视角来看WSHttpBinding和WSDualHttpBinding对可靠会话的不同实现方式。对于WSHttpBinding创建的单向信道来说,客户端对于服务端是一个不可寻址(Non-Addressable)的终结点。也就是说,客户端不能主动向客户端发起请求,只能在客户端对自己发起请求时,被动地将相应的信息通过HTTP回复的形式返回到客户端。但是,对于WSDualHttpBinding创建的双工信道,情况就不一样了。双工通道是客户端和服务端成为了对等终结点,无论是服务端还是客户端,对于对方来说都是可寻址的(Addressable)。服务端可以在任何时候向客户端发起请求,将相应的信息通过HTTP请求的方式发送给客户端。

双工通道成就了可靠会话的“批量确认”机制。为了尽可能地降低网络流量,接收端RS信道接收到消息之后,并不会立即为该消息进行单独确认,而是会等待一定的时间(通过ReliableSessionBindingElement的AcknowledgementInterval属性设置),对之前接收到的消息进行批量确认。由于接收端RS信道接收到消息和发送确认有一定的延迟,我们也称这种机制为“延迟确认”。

二、单向模式(One-Way)V.S.请求|回复(Request|Reply)和双工(Duplex)模式

决定实现WCF可靠会话真正采用的消息交换还具有另外一个因素:消息交换模式。单向模式和请求|回复以及双工模式下,可靠会话采用的消息交换方式具有很大的不同。如果终结点服务契约中的所有操作均是单向的(通过OperationContractAttribute特性的IsOneway属性设置),对于可靠会话来说仅仅存在一个从客户端到服务端的RM序列。反映在序列的创建上就意味着在客户端RS生成的CreateSequence消息中并不存在Offer结点

从应用层次讲,单向操作意味着客户端向服务端发送消息而不会接收到任何回复。由于服务端不会有任何的应用消息从服务端返回到客户端,服务端的RS信道只能创建一个空的SequenceAcknowledgement消息对接收的消息进行确认。

如果终结点服务契约中的所有操作中具有一个以上的非单向操作,WCF可靠会话不仅仅需要保障消息从客户端到服务端的可靠性,也需要对服务端到客户端的消息传输提供保障,所以WCF可靠会话需要建立两个方向相反的RM序列。具体来说,可靠会话采用“序列提供”机制创建了双向的RM序列。在客户端RS信道生成CreateSequence之前现在本地创建一个RM序列,然后将该序列封装到CreateSequence消息的Offer元素中“提供”给服务端。服务端RS信道接收到CreateSequence消息之后,处理创建客户端请求的RM序列之外,还会接受(或者拒绝)提供的序列。

不同于单向模式下采用单独的SequenceAcknowledgement消息进行消息确认,在请求|回复模式下,为了尽量降低网络流量,可靠消息采用“背负(piggy-back)”机制实现消息确认。具体来说,客户端RS信道将SequenceAcknowledgement报头放到请求消息中,实现对接收到的回复消息的确认;服务端RS信道则将SequenceAcknowledgement报头放到回复消息中,实现对已经接收到的请求消息的确认。

而双工(Duplex)是由两个简单消息交换模式(单向或者请求|回复模式)组合而成,具体消息交换方式你应该可以上面接受推导出来,在这里就不再赘言讲述了。

作者: Artech
出处: http://artech.cnblogs.com
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

原文链接:http://www.cnblogs.com/artech/archive/2010/05/05/1728384.html
加载中
返回顶部
顶部