WCF协议篇.docx

《WCF协议篇.docx》由会员分享，可在线阅读，更多相关《WCF协议篇.docx（13页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、【协议篇-上】在 WS-*大家庭中，WS-RM 为牢靠消息传输供给了一个一个标准，使互操作成为可能。在协议篇中， 我们侧重对 WS-RM 的介绍。WS- RM，为 WS-Reliable Messaging 的简称，是 WS-*大家庭的一个重要成员。和前面介绍的 WS-Coordination 和 WS-AT 一样，WS-RM 的制定者是构造化信息标准促进组织OASIS。制定WS-RM 的一个主要目的就是创立一个模块化的实现牢靠具体传输Reliable Mess aging的机制。WS-RM 定义了一种消息传输协议Messaging Protocol，以实现在牢靠消息传输过程中对消息的识别、追

2、踪和治理。并在此根底上，定义了 SOAP 绑定实现了互操作。到目前为止，WS-R M 先后出了两个官方版本，即 WS-RM 1.0 和 WS-RM 1.1在实例篇中，我通过牢靠会话实现了对图片的牢靠、有序的传输；在概念篇中，我们对牢靠消息涉及到的牢靠消息传输RM的相关概念进展了表达。在WS-*大家庭中，WS-RM 为牢靠消息传输供给了一个一个标准，使互操作成为可能。在协议篇中，我们侧重对 WS-RM 的介绍。WS-RM，为 WS-Reliable Messaging 的简称，是 WS-*大家庭的一个重要成员。和前面介绍的 WS-C oordination 和 WS-AT 一样，WS-RM 的制

3、定者是构造化信息标准促进组织OASIS：Organization f or the Advancement of Structured Information Standards。制定 WS-RM 的一个主要目的就是创立一个模块化的实现牢靠具体传输Reliable Messaging的机制。WS-RM 定义了一种消息传输协议Messaging Protocol，以实现在牢靠消息传输过程中对消息的识别、追踪和治理。并在此根底上，定义了 SOAP 绑定实现了互操作。到目前为止，WS-RM 先后出了两个官方版本，即 WS-RM 1.0 和 WS-RM 1.1。接下来对 WS-RM 的介绍完全基于 W

4、S-RM 1.1 版本。WS-RM 1.1 的命名空间为 :/docs.oasis-open.org/ws-rx/wsrm/200702，你也可以直接通过命名空间表示的 URL 查看 WS-RM 官方文档。一、 牢靠消息传输模型在本节刚刚开头的时候，我们就简洁争论了牢靠消息传输需要解决的问题，或者说通过牢靠消息传输可以实现的目标。概括性的说，牢靠具体传输可以来实现一下三个牢靠性述求：接收保障、重复筛选和有序交付。接收保障确保从消息源发送的消息能够成功地抵达目的地；重复筛选意味着消息的接收端能够识别每 一个接收到的消息，自动丢弃重复的消息；而有序交付要求消息的接收端能够完全依据消息发送的挨次上

5、对消息进展交付。具体来说，我们可以通过如图 1 所示的牢靠消息传输模型来说明。整个牢靠消息传输体系最终是为应用效劳的。假设我们将发送消息的称为应用源Application Source，将接收消息的应用称为应用目的地Application Destination，那么牢靠消息传输题是为了确保应用源和应用目的地之前消息传输的牢靠性而存在。图 1 所示的牢靠消息传输模型向读者展现了一个简洁的消息牢靠传输的流程。在消息发送端，应用源将消息发送给本地的牢靠消息传输体系，即牢靠消息传输源源RM Source，以下简称 RM 源；RM 源将 消息发送到目的地；牢靠消息传输目的地RM Destination

6、，以下简称 RM 目的地接收到消息之后， 会像 RM 源发送确认ACK消息，说明消息已经被成功接收；假设消息准确无误这里主要指消息序号是否和上次交付的消息相邻，则将消息交付给应用目的地。图 1 牢靠消息传输模型和 TCP 实现对报文段的牢靠传输一样，在这照旧承受消息缓存、消息确认和超时重传的机制供给对牢靠消息传输的三个目标的实现。首先，当消息从应用源发送到 RM 源之后，会被赐予一个消息序号，该序号在该牢靠消息传输上下文中是唯一的。RM 源和目的地具有各自的消息缓冲区，或者说消息窗口对消息，用户缓存消息之用。RM 源用该消息窗口存放已经发送但是尚未接收到确认的消息，我们可以将这样的消息成为状态

7、未决消息In-Doubt Message；RM 目的地则利用消息窗口存放成功接收但是尚未向应用目的地交付的消息。对于某个已经发送的消息，假设在设定的超时时限内没有成功接收到相应确实认，RM 源会认为该消息发送失败。此时，它会从自己的消息窗口中选择对应的消息进展重发送。只有在成功接收到确认消息的状况下，RM 源才会将消息从消息窗口中移除。当 RM 目的地成功接收到消息后，假设消息的序号和上次交付消息的序号相邻，它会将消息交付给应用目的地。否则，说明之前发送出来的消息尚未抵达，此时 RM 目的地会将该消息放到自己的消息窗口中。只有等到之前全部的消息全部成功接收后，RM 目的地承受依据消息的序号对消

8、息实施交付，从而保证了对消息的有序交付。假设，接收到的消息序号小于已经交付的消息序号，或者等于消息窗口的某个消息的序号，RM 目的地将其视为重复消息予以丢弃。WS-RM 仅仅是对消息窗口所应供给的功能进展规定，并没有对消息缓存的具体实现做出任何的限制。也就是说，我们可以承受基于内存的方式将消息缓存在当前进程的内存之中，这样可以带来更好的性能提升； 我们也可以承受长久化的存储方式，将序列化后的消息存储于物理存储介质中，这样可以实现跨进展的数据共享已及程序中断后的数据恢复。前者被 WCF 中的牢靠会话所承受。二、从消息交换来看牢靠消息传输的处理流程上面我们通过对 WS-RM 承受的牢靠消息传输模型

9、进展了介绍,信任大家对根本的实现机制有了一个大致的了解。接下来，我们将目光聚焦到具体的消息交换层面，看看 WS-RM 承受怎样的消息交换方式供给对消息确认、超时重传的实现。不过，在这之前我们必需先介绍一个格外重要的概念：序列Sequence。牢靠消息传输致力于对在两种终结点之间供给对接收保障、重复筛选和有序交付的实现，但是牢靠消息传输具有一个执行范围。或者说，牢靠消息传输的实现是基于某个上下文环境中，这相对于是一种会话Se ssion的概念，这个会话在 WS-RM 的词汇中被称为序列。两个终结点之前能够实现牢靠消息传输之前，需要先在它们之间创立一个序列，该序列为牢靠消息传输供给一个执行上下文。

10、我们同样用 TCP 对报文段的牢靠传输作为类比。TCP 是一个完全基于连接的协议，在利用 TCP 进展报文传输的之前，两个 TCP 端点之间需要通过 3 次“握手”建立连接。也就是说，TCP 对报文段的牢靠传输是在一个确立的连接中进展的，TCP 连接担当执行上下文的作用。所以，TCP 连接至于 TCP 报文的牢靠传输， 就相当于序列对 WSRM 牢靠消息传输。通过前面的介绍，我们知道牢靠消息传输机制的核心应当是“消息窗口”和“消息识别”。为了让 RM 源和目的地能够有效地识别每一个消息，每一个消息会被赐予一个消息序号Message Number。该消息序号从 1 开头，并在牢靠消息序列这个上下

11、文中是唯一的。对 WS-RM 下的序列有了一个大致的了解之后，我们结合图 5-2 所示的序列图Sequence Diagram 争论一下 WS-RM 下的消息确认机制和超时重传是如何实现的。如图 2 所示，基于 WS-RM 消息交换的两个终端是 Endpoint A 和 Endpoint B，它们分别是消息的最初发送者和最终承受者。整个过程由 10 个步骤完成，接下来我们来介绍一下每一个步骤具体完成怎样的工作：步骤 12 ：Endpoint A 向 Endpoint B 发送一个创立 CreateSequence 的恳求，Endpoint B 创立一个全的序列，并将序列的唯一标识 :/ art

12、ech /abc以 CreateSequenceReponse 的形式返回给 Endpoint A；步骤 35 ：Endpoint A 连续向 Endpoint B 发送 3 个消息，这 3 个消息均具有 WS-RM 相关的报头，主要包括序列的唯一标识和消息序列消息序号分别文 1、2 和 3。为了避开频繁的网络传输，WS-RM 的消息会确认机制承受一种批量确认的机制。也就是说，RM 目的地对它所接收的消息并不是逐个确认的， 而是将之前接收到的消息序号方式一个确认范围Acknowledgement Range中，一并发送给 RM 源进展批量确认。反映在 RM 源上，假设它期望在某次消息发送后期望

13、接收到对方确实认，就需要在该消息中插入一个 AckRequested 报头。步骤 5 中发送的第三个消息就是包含了这么一个消息报头；步骤 6：假设 Endpoint B 先后接收到序号为 1 和 3 个两个消息，其次个消息在传输过程中被丢弃。当接收到包含有 AckRequested 报头的消息之后，会向 Endpoint A 发送确认消息。在确认消息中确实认范围中，包括 1 和 3；步骤 7：Endpoint A 接收到确认消息后，分析确认范围中的消息序号，觉察并不存在 2，直到序号为 2 的消息发送失败。于是会从发送窗口中提取序号为 2 的消息，进展重传，该消息同样具有 AckRequest

14、e d 报头，由于它期望准时接收到对重传消息确实认；步骤 8：Endpoint B 成功接收到重传的序号为 2 的消息后，发送确认消息进展确认，需要留意的是确认范围中不仅仅包含 2，还包括之前成功接收的消息序号 1 和 3；步骤 910 ：Endpoint A 接收到确认。假设此时不需要进展后续的消息交换工作，可以发送 Terminate Sequence 消息恳求终止序列，Endpoint B 对序列实施终止，并返回 TerminateSequence 消息进展终止确认。图 2 WS-RM 消息交换在上篇中，我们生疏了从序列创立到终止过程中消息交换的大致流程。接下来，我们进一步将关注点聚焦到

15、单个小消息上，看看在整个基于序列的上下文中，不同类型的消息具有怎样的构造。首先从序列的创立开头。一、CreateSequence 和 CreateSequenceReponse基于 WS-RM 的牢靠消息传输从序列的创立开头。为了创立序列，RM 源RM Source向 RM 目的地R M Destination发送一个主体包含 CreateSequence 元素的 SOAP 消息。CreateSequence 元素携带序列相关的属性，比方确认消息被发送的目的终结点引用，序列过期时限以及序列相关的其它信息。成功接收到序列创立恳求后，RM 目的地成功创立序列，并将序列相关信息封装到 CreateS

16、equenceRepons e 元素中，并最终通过 SOAP 消息返回。对于参与消息传输的某个结点来说，消息传输是具有方向的。通过上面的方式创立的序列为从 RM 源到目的地的消息牢靠传输供给了一个执行上下文，对于源来说，这是出栈牢靠消息传输Outbound RM， 创立出来的序列被称为出栈序列Outbound Sequence。但是，在非单向One-way消息交换模式下，我们同样需要保障消息传输目的地到消息传输源之间消息传输的牢靠性，即入栈牢靠消息传输。在这种状况下，消息传输源会在本地创立入栈序列Inbound Sequence，并将序列的内容嵌入到序列创立恳求的 CreateSequence

17、 元素中。RM 目的地会接收到包含有入栈序列针对于 RM 源来说的序列创立恳求消息后，会选择承受或者拒绝源供给的序列。1: 2: wsa:EndpointReferenceType 3: xs:duration ?4: 5: xs:anyURI 6: wsa:EndpointReferenceType 7: xs:duration ?8:9:wsrm:IncompleteSequenceBehaviorType10: ?11:.12: ?13:.14: 上面的 XML 片断展现了 CreateSequence 元素的构造。其中是必需的，它表示牢靠消息目的地发送确认消息的目的终结点引用。而表示恳

18、求创立的牢靠消息传输序列的过期时限。假设该值为 PT0S，则说明牢靠消息传输序列永不过期。假设没有显式指定，该值为 PT0S。WS-RM 中某个 RM 序列只能保证单向的消息传输的牢靠性，也就是说，确保从终结点A 到 B 的牢靠消息传输的 RM 序列不能供给从终结点 B 到 A 的牢靠消息传输保障。要想解决这种双向Two-Way牢靠消息传输，需要借助于两个 RM 序列。所以，对于非单向One-Way消息交换模式，恳求|回复模式和双工模式下的牢靠消息传输需要双 RM 序列的支持。WS-RM 通过序列供给Sequence Offering机制对此供给支持。假设两个终结点之间存在恳求|回复或者双工消

19、息交换模式，RM 源会在本地创立 RM 序列， 并将创立的序列封装到 CreateSequence/Offer 元素中，供给应 RM 目的地。限于篇幅的局限，Create Sequence/Offer 结点中每一个元素的含义在这里就不单独介绍了，对此有兴趣的读者可以参考 WS-RM1.1 的官方文档。下面是一个典型的包含 CreateSequence 元素的 WS-RM 序列创立恳求消息。1: 2: 3: :/docs.oasis-open.org/ws-rx/wsrm/200702/ CreateSequence4:urn:uuid:949cca61-8813-42ff-ab33-18d9e

20、3fa82fa5:6: :/ artech /client7:8: :/ artech /service9: 10: 11:12:13: :/ artech /client14:15:urn:uuid:066b4730-fc82-458a-a5c1-210be4f b4e4e16:17: :/ artech /client18:DiscardFollowingFi rstGap19:20:21: 22: RM 目的地接收到序列创立恳求的 CreateSequence 消息后，会创立序列，并将序列的相关信息封装到回复消息中。当 RM 源接收到了回复之后，意味这它可以在指定的序列通过序列的标识上下

21、文中发送消息了。牢靠消息传输回复消息的主体局部包含一个 CreateSequenceResponse 元素，该元素具有如下的构造。1: 2: xs:anyURI 3: xs:duration ?4: 5:wsrm:IncompleteSequenceBehaviorType6: ?7: 8: wsa:EndpointReferenceType 9:.10: ?11:.12: 其中中的 URI 为创立序列的唯一标识。为序列过期时间，一般来说，本创立的序列过期时间小于或者等于 CreateSequence 恳求中指定的 RM 源所期望的过期时间。假设该值为 PT0S，意味着序列永不过期。当该元素缺

22、省时，默认值为 PT0S。元素封装的局部作为对 CreateSequence 恳求中供给的序列的承受。下面的XML 片断展现一个典型的包含 Creat eSequenceResponse 元素的 SOAP 消息。1: 2: 3: :/docs.oasis-open.org/ws-rx/wsrm/200702/ CreateSequenceResponse4:urn:uuid:949cca61-8813-42ff-ab33-18d9e3fa82fa5: :/ artech /client6: 7: 8:9:urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed27

23、10:DiscardFollowingFirstGap11:12:13: :/ artech /service14:15:16:17: 18: 二、CloseSequence 和 CloseSeqenceResponse需要留意的是，这里讲的序列的关闭Close，并不是指上面消息交换流程中的序列的终止Terminat e，这是一个上面没有提及的概念。在牢靠消息传输序列被使用过程中，RM 源和 RM 目的地都有可以希望停顿使用该序列。而对序列的终止会使 RM 源和目的地失去其现有的状态，所以为了确保牢靠消息序列能够以一种可知的最终状态完毕，RM 源和 RM 目的地均可以在最终终止序列之前选择将其

24、关闭。假设一方RM 源或者 RM 目的地期望关闭现有的序列，它会像另一个方法送序列关闭恳求消息。该消息主体局部包含一个 CloseSequence 元素，该元素构造如下。1: 2: xs:anyURI 3: wsrm:MessageNumberType ? 4: .5: 的值为序列的唯一标识。是最终发送的消息序号，也是在该序列上下文中发送的最终一个消息的序号。下面是一个典型的包含有 CloseSequence 元素的 SOAP 消息。1: 2: 3: :/docs.oasis-open.org/ws-rx/wsrm/200702/ CloseSequence4:urn:uuid:6ce1d4c

25、3-e1c1-474f-a8c9-4210e37f78775:6: :/ artech /client7:8: :/ artech /service9: 10: 11:12:urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed2713:3014:15: 16: 当 CloseSequence 恳求消息被另一方接收之后，它不运行再接收该序列范围内的其它消息。作为回复，它会创立一个主体局部包含有 CloseSequenceResponse 元素的 SOAP 消息。CloseSequenceRespon se 元素的构造如下。1: 2: xs:anyURI 3: .

26、4: 在 CloseSequenceResponse 元素中，只有包含有序列标识的是必需的。除了主体局部包含 CloseSeqenceResponse 元素之外，序列关闭回复消息还必需包含 SequenceAcknowledge ment 确认报头，并且该报头具有 Final 子元素。下面是一个典型包含 CloseSequenceResponse 元素的SOAP 消息。1: 2: 3:4:urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed275: 6:7:88:9: :/docs.oasis-open.org/ws-rx/wsrm/200702/ Close

27、SequenceResponse10:urn:uuid:6ce1d4c3-e1c1-474f-a8c9-4210e37f787711: :/ artech /client12: 13: 14:15:urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed2716:17: 18: 三、TerminateSequence 和 TerminateSequenceReponse当 RM 源完成全部消息传输工作之后，不再需要当前的序列，它可以向 RM 目的地发送一个主体局部包含TerminateSequence 元素的消息，通知对方当前序列已经完成，并且不会连续发送基于该序

28、列的消息。成功承受到序列终止恳求消息后，RM 目的地可以进展许当前序列相关的资源回收工作。在正常的状况下，RM 源会在接收到全部消息确实认后才会向 RM 目的地发送序列终止的恳求，但是，WS-RM 对此并没有严格的限制。也就是说，无论全部消息确实认是否成功接收，RM 源都可以强行终止对应的序列。此外， 除了 RM 源，RM 目的地也可以主动终止当前序列。为了帮助 RM 目的地确定它是否成功接收到马上被终止的序列关联的全部消息，RM 源会将自己在在序列上下文中发送的最终一个消息的序号发送给它。所以 TerminateSequence 元素除了包含封装有序列标识的子元素之外，还具有必需包含最终消息

29、序号的元素。下面是 TerminateSequence 的构造。1: 2: xs:anyURI 3: wsrm:MessageNumberType ? 4: .5: 对于通过表示的消息序号，还有一点需要特别说明的，那就是该消息序号必需和序列关闭恳求消息中 CloseSequence 元素下的同名元素具有一样的值。下面的 XML 片断展现了一个包含有 TerminateSequence 元素的 SOAP 消息。1: 2: 3: :/docs.oasis-open.org/ws-rx/wsrm/200702/ TerminateSequence4:urn:uuid:3597a398-4f3c-40

30、f4-9335-8f1515572fdf5:6: :/ artech /client7:8: :/ artech /service9: 10: 11:12:urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed2713:3014:15: 16: 当序列终止恳求被接收方RM 源或者 RM 目的地后，它会回复一个主体局部包含 TerminateSequen ceReponse 元素的消息，TerminateSequenceReponse 的构造如下：1: 2: xs:anyURI 3: .4: TerminateSequenceReponse 元素构造格外简洁，仅仅

31、包含一个表示序列标识的 Identifier 元素。下面的 XML 片断展现了一个包含有 TerminateSequenceReponse 元素的 SOAP 消息。1: 2: 3:4:urn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed275: 6:7:88:9: :/docs.oasis-open.org/ws-rx/wsrm/200702/ TerminateSequenceResponse10:urn:uuid:3597a398-4f3c-40f4-9335-8f1515572fdf11: :/ artech /client12: 13: 14:15:u

32、rn:uuid:656652b8-9af2-4e94-9d07-2dc21c05ed2716:17: 18: 四、Sequence、AckRequested 和 SequenceAcknowledge ment上面的内容都在单纯地争论 RM 序列的问题，接下来我们主要争论另外两个主题：如何将在 RM 序列上下文中传输的消息与序列进展关联，以及如何实现消息确认。我们已经知道了，基于 WS-RM 的消息交换是在实现创立的 RM 序列上下文中进展的。为了让 RM 目的地清楚地知道它所接收的消息具体属于哪一个 RM 序列中，需要 RM 源在发送之前向消息的报头集合中添加相应的序列关联信息。此外，与序列

33、关联信息一并添加的，还有消息的序号。WS-RM 将这两组信息封装在一个 Sequence 报头中，该报头的 XML 构造如下。其中 Identifier 元素的值为 RM 序列的唯一标识，而 MessageNumber 即为消息在当前序列上下文中的序号。1: 2: xs:anyURI 3: wsrm:MessageNumberType 4: .5: 假设 RM 源期望在 RM 目的地在接收到某个消息之后对所接收的全部消息进展确认，它会在该消息的报头集合中添加一个 AckRequested 报头。AckRequested 的 XML 构造如下所示，其中仅仅包含一个必需的表示 RM 序列标识的 Identifier 元素。1: 2: xs:anyURI 3: .4: /