GB/T 32416-2015 信息技术 Web服务可靠传输消息

　　ICS 35. 100. 05 L 79

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 32416—2015

　　信息技术 Web服务可靠传输消息

　　Information technology—Reliablemessaging ofWeb service

　　2015-12-31发布 2017-01-01实施

　　中华人民共和国国家质量监督检验检疫总局中 国 国 家 标 准 化 管 理 委 员 会

　　发

　　布

　　GB/T 32416—2015

　　前 言

　　本标准按照 GB/T 1. 1—2009给出的规则起草 。

　　本标准由全国信息技术标准化技术委员会(SAC/TC28)提出并归 口 。

　　请注意本文件的某些内容可能涉及专利 。本文件的发布机构不承担识别这些专利的责任 。

　　本标准起草单位 : 中国电子技术标准化研究院 、北京航空航天大学 、复旦大学 、深圳市金蝶中间件有限公司 、用友软件股份有限公司 、国防科技大学 、北京东方通科技发展有限公司 、山东浪潮齐鲁软件产业股份有限公司 、工信部电子第五研究所 、太极计算机股份有限公司 、北京有生博大软件技术有限公司 、北京锐易特软件技术有限公司 。

　　本标准主要起草人 :赵永望 、王潮阳 、吕智慧 、滕腾 、廖荣淮 、史殿习 、刘川 、贾德星 、刘璐 、董晶 、赵斌 、李轶强 、袁媛 、董建 、李海波 、程操红 、田忠 、贺一丁 。

　　引 言

　　进行 Web 服务开发时 ,一个常见的需求是即使软件构件 、系统或网络出现故障时 ,两个 Web 服务还能可靠地传输消息 。本标准的主要目标是制定一套消息发送方和接收方都信赖的传输机制 。本标准定义了一套能够在消息发送方和消息接收方之间识别 、跟踪及管理可靠地传输消息的协议 ,还定义了用于互操作的 SOAP绑定 ,也可以额外定义其他绑定 。

　　为了把更多的功能(例 如 安 全) 集 成 进 来 , 本 标 准 所 规 定 机 制 是 可 扩 展 的 。本 标 准 集 成 并 补 充 了WS-Security、WS-Policy以及其他 Web 服务规范 ,从整体上为可靠地传输消息提供了广泛 、可靠 、安全的选择 。

　　信息技术 Web服务可靠传输消息

　　1 范围

　　本标准旨在建立一种模块化 、可扩展 、可信赖地传输消息的机制 。

　　本标准适用于标识 、跟踪 、管理消息源和目的地间传输的消息 。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的 。凡是注 日期的引用文件 ,仅注 日期的版本适用于本文件 。凡是不注日期的引用文件 ,其最新版本(包括所有的修改单)适用于本文件 。

　　GB/T 5271. 14 信息技术 词汇 第 14部分 :可靠性 、可维护性与可用性

　　GB/T 18793—2002 信息技术 可扩展置标语言(XML)1. 0

　　GB/T 29262—2012 信息技术 面向服务的体系结构(SOA)术语

　　3 术语、定义和缩略语

　　3. 1 术语和定义

　　GB/T 5271. 14和 GB/T 29262—2012界定的以及下列术语和定义适用于本文件 。

　　3. 1. 1

　　接受 accept

　　可靠消息目的地证明一条消息合格的动作 ,这样这条消息就可以被交付和确认 。

　　3. 1.2

　　确认 acknowledgement

　　从可靠消息目的地到可靠消息源的通信 ,表明该消息已被成功接收 。

　　3. 1.3

　　确认消息 acknowledgementmessage

　　一条含有 SequenceAcknowledgement头块的消息 ,确认消息可以包含也可以不包含 SOAP体 。 3. 1.4

　　确认请求 acknowledgementrequest

　　一条含有 AckRequested 头块的消息 。确认请求可以包含也可以不包含 SOAP体 。 3. 1.5

　　应用程序目的地 application destination

　　消息投递到的端点 。

　　3. 1.6

　　应用程序源 application source

　　发送消息的端点 。

　　3. 1.7

　　返回通道 back-channel

　　当底层传输提供了一种传输协议指定的响应 ,能携带 SOAP体 ,却并不需要初始化一个新连接 ,本

　　文件把这种机制称为返回通道 。

　　3. 1. 8

　　交付 deliver

　　负责把消息从可靠消息目的地送到应用程序目的地的动作 。

　　3. 1.9

　　端点 endpoint

　　一个 Web服务端点就是一个可被寻址到的实体(可引用的) 、处理器或者一个能处理 Web 服务消息的资源 。多个端点引用(EPRs)把需要处理的消息传送给一个 Web 服务端点 。

　　3. 1. 10

　　接收 receive

　　从网络连接中读一条消息并且接受它的动作 。

　　3. 1. 11

　　可靠消息目的地 RM destination

　　接收从可靠消息源发送过来的可靠消息的端点 。

　　3. 1. 12

　　可靠消息协议头块 RM protocolheaderblock

　　是如下三者之一 :Sequence、SequenceAcknowledgement或 AckRequested。

　　3. 1. 13

　　可靠消息源 RM source

　　能够把可靠消息发送给可靠消息目的地的端点 。

　　3. 1. 14

　　发送 send

　　为了可靠传送消息 ,消息从应用程序源发送到可靠消息源的动作 。

　　3. 1. 15

　　序列生存周期消息 sequencelifecyclemessage

　　一条包含 CreateSequence、CreateSequenceResponse、CloseSequence,CloseSequenceResponse、Ter- minateSequence、TerminateSequenceResponse之一作为 SOAP体子元素的消息 。

　　3. 1. 16

　　序列运输消息 sequence trafficmessage

　　一条包含 Sequence头块的消息 。

　　3. 1. 17

　　传送 transmit

　　把消息写到网络连接中的动作 。

　　3.2 缩略语

　　下列缩略语适用于本文件 。

　　4 相关约定

　　本标准使用下面的语法定义消息的规范 :

　　— 语法以 XML实例的形式展现 ,应符合 GB/T 18793—2002的规定 ,斜体形式表示的是数据类型而不是值 ;

　　— 附加到元素和属性后面的字符表示数量 :

　　● “?”(0或者 1)

　　● “* ”(0或更多)

　　● “+ ”(1或更多)

　　— 字符“|”用于表示在不同可选项之间选择一个 ;

　　— 被 “[”和 “] ”包含的项表示数值或者选项的集合 ;

　　— 省略号(如 “… … ”)表示一个扩展点 ,该扩展点允许添加本标准中规定的子元素或属性 。子元素和/或属性可以被添加到某个指定扩展点 ,但它们不应与父元素和/或所有者的语义发生冲突 。如果不能验证某个扩展点是否存在冲突 ,宜把该扩展点忽略 。

　　—XML命名空间前缀(见第 5 章)用于表示已定义元素的命名空间 。

　　本标准定义的元素和属性是指在本标准中使用了 XPath 1. 0 表达式的文本 。扩展点是指使用了下面语法的扩展版本 :

　　— 元素扩展点使用{any}代替元素名 。这表明除 wsrm:命名空间以外的任何命名空间的元素名都能使用 。

　　— 属性扩展点使用 @ {any}代替属性名 。这表明除 wsrm:命名空间以外的任何命名空间的属性名都能被使用 。

　　5 命名空间

　　实现本标准使用的 XML命名空间 URI应是 :

　　http://docs.oasis-open. org/ws-rx/wsrm/200702

　　对上述 URI解引用将产生描述此命名空间的资源描述语言文档 。

　　表 1列出了本标准中使用的 XML命名空间 。这些命名空间前缀的选择是任意的 ,并没有特别的语义 。

　　表 1 本标准中使用的 XML命名空间

　　本标准的规范模式可从上述 URI的命名空间文档中获得 。

　　6 符合性声明

　　声称符合本标准的实现应满足所有 “应 ”陈述的条款 。一个 SOAP节点只有声明符合本标准 ,才能使用第 5 章中规定的命名空间标识符 。

　　本标准使用的模式可见附录 A。

　　7 可靠消息传输模型

　　7. 1 概述

　　多种错误都会打断系统间的通信 ,导致消息丢失 、重复或者重新请求 ,进而造成主机系统失效 。

　　本标准定义了一套可互操作的协议 ,使得可靠消息源能够精确判断传送给可靠消息 目 的地的每条消息的处理情况 ,进而使其能处理任何传送消息的可疑状态相关的收据 。另外 ,使得可靠消息目的有效地判断出在它接收到的消息中哪些消息是之前就已接收的 , 以及从重新发送的消息中过滤重复的消息 。还使得可靠消息目的地即使不是按顺序接收消息 ,它也会按照应用程序发送源发送消息的顺序整理好交付给应用程序目的地的消息顺序 。 注意本标准并没有对可靠消息源或可靠消息 目 的地进行任何约束 。例如 ,二者都能经过多个 WSDL端口或端点 ,WSDL 的模式可见附录 B。

　　本标准规定的可靠特性应用范围广泛 ,包括顺序投递 、重复消除和确保接收 。本标准规定的健壮特性的应用范围也很广 ,包括从在一个单线程生存周期中都存留在内存 ,到所有最极端环境中频繁地恢复存储 。 只需要使用本协议的应用程序端点 , 以正确的操作实现必需的可靠要求特性 。

　　图 1说明了在一个简单的可靠消息交换场景中的实体和事件 。首先 ,应用程序源发送一组需要可靠传输的消息序列 。可靠消息源接受完该消息序列后 ,把它分一次或多次发送出去 。 可靠消息 目 的地每接受一条消息 ,都会向可靠消息源确认该消息 。接收完毕后 ,可靠消息目的地把完整消息序列移交给应用程序目的地 。

　　图 1 可靠消息传输模型

　　7.2 标准的先决条件

　　本标准的正确操作需要许多先决条件 ,应在处理初始化消息序列之前建立这些先决条件 。

　　— 对于任何一次消息交换 ,可靠消息源都应有单一的 、能够唯一识别可靠消息目的地端点的端点

　　引用 。

　　— 可靠消息源应成功地创建了发往可靠消息目的地的序列 。

　　— 可靠消息源应能够按照可靠消息目的地的策略来格式化消息 。

　　— 如果需要进行安全的消息交换 ,则可靠消息源和可靠消息目的地应有安全环境 。

　　7.3 标准的不变量

　　在一个序列的生存周期中 ,为确保正确性 ,对不变量要求如下 :

　　— 可靠消息源应为一个序列中的每条消息指派一个消息编号 ,对于每个消息序列中的消息 ,消息编号都是从 1 开始并且依次递增 1。

　　— 在可靠消息目的地产生的每个确认消息中 ,应包括一个或多个 AcknowledgementRange子元素 ,这些子元素包含了由可靠消息 目 的地接受的每个消息编号 。 在 AcknowledgementRange元素中 ,可靠消息目的地应排除任何它未接受的消息的编号 。如果可靠消息 目 的地没有接收到消息 ,则应返回 None消息代替 AcknowledgementRange。可靠消息目的地可以为一个或多个特定消息传送一条 Nack 消息代替 AcknowledgementRange。

　　— 当没有关闭或终止序列时 ,可靠消息源宜重新发送未经确认的消息 。

　　7.4 传送保证

　　本条定义了可靠消息源和可靠消息目的地所支持的传送保证断言 。这些断言符合 WS-Policy框架规范 。具体细节请查看 WSRM Policy specification。

　　最少一次

　　至少将每条消息传送一次 ,否则可靠消息源和/或可靠消息目的地应产生一个错误 。

　　对可靠消息源的要求是 :宜重新传输应用程序源发送过来的每条消息 ,直到从可靠消息目的地接收到确认消息 。

　　对可靠消息目的地的要求是 :宜重新把从可靠消息源接受的消息投递给应用程序目的地 ,直到该条消息移送成功 。对可靠消息目的地是否过滤重复消息没有要求 。

　　最多一次

　　最多将每条消息传送一次 。可靠消息源可重新传送未确认的消息 ,但这不是强制要求 。对可靠消息目的地的要求是它应过滤掉重复消息 , 比如 ,它不应传送一条它已经传送过的消息 。

　　正好一次

　　正好将每条消息传送一次 。如果哪条消息不能被交付 ,可靠消息源和/或可靠消息目的地应产生一个错误 。

　　对可靠消息源的要求是 :宜重新传送从应用程序源发送过来的消息 ,直到它接收到来自可靠消息目的地的确认消息 。

　　对可靠消息目的地的要求是 :宜重新把从可靠消息源接受的消息投递给应用程序目的地 ,直到该消息被成功传送 , 同时它不应继续传送已经传送过的消息 。

　　按次序

　　将序列中要传送的消息按照它们从应用程序源发送过来的顺序排列 。

　　对可靠消息源的要求是 :应确保序列中每条消息的顺序(标识为消息编号) 与该消息从应用程序源发送时的顺序保持一致 。

　　对可靠消息目的地的要求是 :应按照消息编号交付接收到的消息 。

　　这种传送保证能结合 “最少一次”“最多一次 ”或者 “正好一次 ”断言 ,应满足这些断言的要求 。若应用了 “最少一次 ”或者 “正好一次 ”断言 ,而可靠消息目的地又探测到在消息序列中消息编号缺失 ,那么可靠消息目的地不应投递该序列中的任何子序列消息 ,除非接收到缺失的消息或者该序列被关闭 。

　　7.5 消息交换示例

　　图 2展示了两个可靠消息端点 A 和端点 B之间可能的消息交换 。

　　图 2 消息交换示例图

　　交换过程如下 :

　　a) 建立协议先决条件 ,包括策略交换 、端点解析以及信任 ;

　　b) 可靠消息源请求创建一个新序列 ;

　　c) 可靠消息目的地创建新序列 ,并返回该序列的唯一的标识符 Identifier;

　　d) 可靠消息源开始使用该序列标识符传送消息 ,从 MessageNumber 1 开始 。 在上图中 , 可靠消息源发送了 3条消息 ;

　　e) 序列中的第 2条消息在传输中丢失 ;

　　f) 第 3条消息是序列中最后一条消息 , 因此可靠消息源置入一个 AckRequested字段来通知可靠消息目的地发回一个 SequenceAcknowledgement;

　　g) 可靠消息目的 地 确 认 接 收 了 编 号 为 1 和 3 的 消 息 , 以 此 作 为 对 RM 源 AckRequested 头 的结果 ;

　　h) 可靠消息源使用第 2 条消息重新传输未确认的消息 。从底层传输的角度来看这是一个新消息 ,但是它有同样的序列标识符和消息编号 ,所以可靠消息目的地能辨别出它是之前消息的 一个副本 , 以防止原来的消息和重新传送的消息都被接收的情况 。 可靠消息源在被传送的消息中置入一个 AckRequested 字段 ,这样可靠消息 目 的地能够马上返回 SequenceAcknowledge- ment;

　　i) 可靠消息目的地接收到了带有 MessageNumber2 的第 2条消息传输 ,并且确认了编号为 1、2、 3 的消息 ;

　　j) 可靠消息源接收到 了 此 确 认 消 息 并 且 发 送 了 一 个 TerminateSequence 消 息 给 可 靠 消 息 目 的地 ,用来表明该序列已结束 。TerminateSequence消息指出消息号为 3 的消息是序列的最后一条消息 。然后可靠消息目的地就可以回收与该序列相关的资源了 ;

　　k) RM可靠消息目的地接收到了 TerminateSequence 消息 ,该消息表明可靠消息源不再发送任何消息 。可靠消息目的地发送 TerminateSequenceResponse消息给可靠消息源并且回收该序列相关的资源 。

　　在第 8章描述的消息交换过程中 ,可靠消息源等待从可靠消息 目 的地接收到确认消息 。如果没有及时接收到确认消息 ,可靠消息源应重新传输消息 , 因为该消息或者其确认消息可能已经丢失 。一般情况下 , 由于底层传输和传输中介的特性和动态特征都是未知的 ,重新传输的时机也不能确定 。另外 ,有证据表明过于主动的重新传输将导致传输或中介发生堵塞 ,这和消息可靠交换的意图是相悖的 。 因此 ,鼓励实现者采 用 自 适 应 机 制 来 动 态 调 整 重 传 时 间 和 回 退 间 隔 , 使 其 适 应 传 输 和 中 介 的 特 性 。 对 于TCP/IP传输的情况 ,可以考虑采用类似于 RFC 1323中描述的 RTTM机制 。

　　8 可靠消息协议元素

　　8. 1 概述

　　本章定义了 9种可靠消息协议元素 ,并规定这些元素在一致性实现中的使用方式 。 可靠消息源和可靠消息目的地的状态转换可见附录 C,每种使用方式的示例可见附录 D。

　　8.2 使用扩展点的考虑

　　以下元素在不同地方定义了扩展点 。实现本文件时可以在指定的扩展点添加子元素和/或属性 ,但不应违背父节点和/或本节点的语义 。如果接收方不能识别某个扩展点 ,宜忽略该扩展点 。

　　8.3 考虑使用“piggy-backing”

　　消息中加入可 靠 消 息 协 议 头 块 , 而 且 接 收 消 息 的 端 点 和 这 些 头 块 的 目 标 端 点 相 同 , 就 形 成 了“Piggy-Backing”模式 ,这种模式可以节省额外的消息交换 。在判定两个端点引用是否指向同一个端点时 ,应考虑采用参考参数 。是否采用 、以及何时在头块中采用 Piggy-Backing由发送头块的实体(可靠消息源或可靠消息目的地)决定 。为了确保能最优地 、成功地处理可靠消息序列 ,接收到可靠消息相关消息的端点宜事先准备好处理包含任何信息的可靠消息协议头块 。见定义可靠消息协议头块的章节以了解哪个实体可以考虑采用 piggy-backing。

　　8.4 结合 WS-Addressing协议

　　当本标准结合 WS-Addressing规范一起使用时 ,对 wsa:Action元素的值的约束如下 :

　　a) 当端点生成携带本标准元素的消息时 ,SOAP信封中的端点应包含一个 wsa:Action的 SOAP头块 ,其值是一个和 WS-RM命名空间 URI相关的 IRI,后面接上 “/”字符 ,然后接上 SOAP体中子元素本地名 。例如 ,对于在 8. 5 描述的序列创建请求消息 wsa:Action IRI的值将会是 :

　　http://docs.oasis-open. org/ws-rx/wsrm/200702/CreateSequence;

　　b) 当端点生成在 SOAP体中没有元素内容的确认消息时 ,wsa:Action IRI的值应是 :

　　http://docs.oasis-open. org/ws-rx/wsrm/200702/SequenceAcknowledgement;

　　c) 当端点生成在 SOAP体中没有元素内容的确认请求时 ,wsa:Action IRI的值应是 :

　　http://docs.oasis-open. org/ws-rx/wsrm/200702/AckRequested;

　　d) 当端点生成一个如第 9章定义的可靠消息故障时 ,wsa:Action IRI的值应遵循该定义 。

　　8.5 创建序列

　　可靠消息源应通过向可靠消息目的地发送包含 CreateSequence元素的消息请求创建出站序列 ,可靠消息目的地相 应 地 返 回 含 有 CreateSequenceResponse元 素 , 或 者 是 CreateSequenceRefused 故 障 的消息 。可靠消息源可用包含 CreateSequence元素的消息请求创建入站序列 。 通过可靠消息 目 的地返回的 CreateSequenceResponse元素可知该请求或者被接受或者被拒绝 。

　　CreateSequence消息序列的所有子消息宜采用相同版本号的 SOAP协议 ,无论这些子消息是来自可靠消息源还是可靠消息目的地 。

　　下面范例定义 CreateSequence语法 :

　　wsa:EndpointReferenceType

　　xs: duration ?

　　xs:anyURI

　　wsa:EndpointReferenceType

　　xs:duration ?

　　wsrm:IncompleteSequenceBehaviorType

　　?

　　...

　　?

　　...

　　CreateSequence元素的各部分内容描述如下 :

　　/wsrm:CreateSequence

　　该元素请求在可靠消息源和可靠消息目的地之间创建一个新序列 。可靠消息源不应把该元素作为一个头块来发送 。可靠消息 目 的地应返回 CreateSequenceResponse响应消息或者 CreateSequenceRe- fused故障 。

　　/wsrm:CreateSequence/wsrm:AcksTo

　　在任 何 可 靠 消 息 源 发 送 的 CreateSequence 消 息 中 , 都 应 包 含 本 元 素 。 本 元 素 属于 wsa: End- pointReferenceType类型(在 WS-Addressing中指定) 。 除非在本标准中另有说明(见 8. 6) ,否则本元素将指定包含 SequenceAcknowledgement头块消息 , 以及与创建序列相关的故障目的地的端点引用 。

　　实现本标准时 ,不应在 AcksTo元素中使用端点引用 , 因为 AcksTo元素会阻止确认序列发送回可靠消息源 。

　　示例:使用 WS-Addressing“http://www. w3. org/2005/08/addressing/none”IRI将 可 能 会 使 可 靠 消 息 目 的 地 无 法发送确认序列 。

　　/wsrm:CreateSequence/wsrm:Expires

　　该元素为可选元素 ,属于 xs:duration类型 ,它指定了序列中可靠消息源的持续时间 。 可靠消息 目的地可以接受该持续时间 ,或者指定一个更短的值 。“PTOS”值表明该序列永不过期 。该元素未出现则表示隐含了“PTOS”值 。

　　/wsrm:CreateSequence/wsrm:Expires/@{any}

　　这是一个可基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:CreateSequence/wsrm:Offer

　　该元素为可选元素 ,能够使可靠消息源为从可靠消息目的地传输到可靠消息源的消息进行可靠交换提供一个相应的序列 。

　　/wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier

　　可靠消息源应设置该元素的值为一个绝对 URI(以 RFC3986格式) ,用以唯一标识所提供的序列 。 /wsrm:CreateSequence/wsrm:Offer/wsrm:Identifier/@{any}

　　这是一个可基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint

　　可靠消息源应包含该元素 ,该元素属于 wsa:EndpointReferenceType类型(在 WS-Addressing中指定) 。该元素指定了序列生存周期消息 、确认请求以及和序列相关的故障消息要发送到的端点引用 。

　　实现本标准时 ,不应在端点元素使用端点引用 ,端点元素将会阻止序列生存周期消息的发送 。

　　示例:使用 WS-Addressing“http://www. w3. org/2005/08/addressing/none”IRI将 可 能 会 使 可 靠 消 息 目 的 地 永 远不会为该序列发送序列生存周期消息(如 TerminateSequence)到可靠消息源 。

　　端点包含“http://www. w3. org/2005/08/addressing/anonymous”IRI作 为 其 地 址 的 请 求 是 有 问题的 , 因为可靠消息源无法连接该地址,进而导致重复发送未经确认的消息(见 7. 3) 。 注意本标准并未定义任何机制来提供这个担保 。在没有扩展机制解决这个问题的情况下 ,可靠消息目的地不应接受(通过下面定义的/wsrm: CreateSequenceResponse/wsrm: Accept元素) 包 含“http://www. w3. org/2005/ 08/addressing/anonymous”IRI作为其地址的请求 。

　　/wsrm:CreateSequence/wsrm:Offer/wsrm:Expires

　　该元素为可选元素 ,属于 xs:duration类型 , 它指定了请求序列的持续时间 。“PTOS”值表明该请求序列永不过期 。该元素不出现则表示一个隐含的“PTOS”值 。

　　/wsrm:CreateSequence/wsrm:Offer/wsrm:Expires/@{any}

　　这是一种可基于模式进行扩展的机制 ,这种机制允许元素中加入额外的属性 。

　　/wsrm:CreateSequence/wsrm:Offer/wsrm:IncompleteSequenceBehavior

　　该元素为可选元素 ,表示目的地将展示关闭或终止一个不完整序列的行为 。为了定义使用值 ,术语“discard”是指应用程序目的地决不会处理某个特定消息的行为 。

　　当元素的值为“DiscardEntireSequence”时表明 , 当最终 SequenceAcknowledgement有一个或多个子序列缺失时 ,如果序列被关闭或者被终止 ,整个序列应被丢弃 。

　　当元素的值 为 “DiscardFollowingFirstGap”时 表 明 , 当 最 终 SequenceAcknowledgement有 一 个 或多个子序列缺失时 ,应丢弃序列中第一个缺失子序列之后的消息序列 。

　　元素的缺省值为“NoDiscard”,表明序列中未经确认的消息将被丢弃 。

　　/wsrm:CreateSequence/wsrm:Offer/{any}

　　这是一种基于模式进行扩展的机制 ,允许不同类型(可扩展)的信息可以被传递 。

　　/wsrm:CreateSequence/wsrm:Offer/@{any}

　　这是一个基于模式进行扩展的机制 ,其允许元素中加入额外的属性 。

　　/wsrm:CreateSequence/{any}

　　这是一种基于模式进行扩展的机制 ,允许不同类型(可扩展)的信息可以被传递 。

　　/wsrm:CreateSequence/@{any}

　　这是一种基于模式进行扩展的机制 ,其允许元素中加入额外的属性 。

　　在响应 CreateSequence请求消息时 ,可靠消息目的地在响应消息体中把 CreateSequenceResponse发送出去 。它携 带 创 建 序 列 的 Identifier, 并 表 示 可 靠 消 息 源 能 开 始 就 在 标 识 序 列 的 环 境 中 发 送 消

　　息了 。

　　下面范例定义 CreateSequenceResponse语法 :

　　xs:anyURI

　　xs:duration ?

　　wsrm: IncompleteSequenceBehaviorType

　　?

　　wsa : EndpointReferenceType

　　...

　　?

　　...

　　CreateSequenceResponse元素的各部分内容描述如下 :

　　/wsrm:CreateSequenceResponse

　　在响应 CreateSequence请求消息时 ,发送这个嵌在响应消息体中的元素 。该元素表明可靠消息 目的地接收到可靠消息 源 的 请 求 , 并 已 经 创 建 了 一 个 新 序 列 。 可 靠 消 息 目 的 地 不 应 把 该 元 素 作 为 头 块发送 。

　　/wsrm:CreateSequenceResponse/wsrm:Identifier

　　可靠消息目的地应在它发送的每个 CreateSequenceResponse消息中都包含该元素 。 可 靠 消 息 目的地应设置该元素的 值 为 绝 对 URI(以 RFC3986格 式) , 该 URI唯 一 标 识 了 可 靠 消 息 目 的 地 创 建 的序列 。

　　/wsrm:CreateSequenceResponse/wsrm:Identifier/@{any}

　　这是一种可基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:CreateSequenceResponse/wsrm:Expires

　　该元素为可选元素 ,属于 xs:duration类型 ,接受或可提取出来自可靠消息源的请求序列的持续时间 。它指定一个时间量 ,过了这个时间量之后 ,序列宜被回收从而静默地终止 。在可靠消息 目 的地 ,这个时间量由最接近序列创建点衡量 ;而在可靠消息源 ,这个时间量由最接近成功处理 CreateSequenceR- esponse的时间点衡量 。“PTOS”值表明该序列永不过期 。该元素未出现则表示隐含了“PTOS”值 。 可靠消息目的地应设置该元素的值小于或等于可靠消息源在相应的 CreateSequence消息中请求的值 。

　　/wsrm:CreateSequenceResponse/wsrm:Expires/@{any}

　　这是一个可基于模式进行扩展的机制 ,其允许元素中加入额外的属性 。

　　/wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior

　　该元素为可选元素 ,表明 目的地将展示关闭或结束一个不完整序列的行为 。为了定义可用值 ,术语“discard”表明应用程序目的地从来没有处理过特别消息 。

　　当元素的值为“DiscardEntireSequence”时表明 , 当最终 SequenceAcknowledgement有一个或多个子序列缺失时 ,如果序列被关闭或被终止 ,整个序列应被丢弃 。

　　元素的值为 “DiscardFollowingFirstGap”时 表 明 , 当 最 后 一 个 SequenceAcknowledgement中 有 一个或多个子序列缺失时 ,应丢弃序列中第一个缺失的子序列之后的消息 。

　　元素的缺省值为“NoDiscard”,序列中未经确认的消息将会被丢弃 。

　　/wsrm:CreateSequenceResponse/wsrm:Accept

　　该元素为可选元素 ,使可靠消息目的地接受从可靠消息源传送到可靠消息 目 的地进行可靠交换的

　　相关序列 。

　　注 : 作为对包含了一个 子 元 素 Offer 的 CreateSequence元 素 的 响 应 , 如 果 返 回 的 是 一 个 未 包 含 子 元 素 Accept的CreateSequenceResponse元素 ,那么可靠消息源可以立即回收所有和未使用序列相关的资源 。

　　/wsrm:CreateSequenceResponse/wsrm:Accept/wsrm:AcksTo

　　可靠消息目的地应包含该元素 。该元素属于 wsa:EndpointReferenceType类型(见 WS-Addressing中描述) 。除非本标准另有说明(如见 8. 6) ,用本元素指定包含 SequenceAcknowledgement的头块以及与创建序列相关的故障将要发送到的端点引用 。

　　实现本标准时 ,不应在 AcksTo元素中使用端点引用 ,否则会阻止序列确认消息发回可靠消息源 。

　　示例:使用 WS-Addressing的 IRI“http://www. w3. org/2005/08/addressing/none”IRI将 使 可 靠 消 息 目 的 地 不 能 把序列确认消息发送给可靠消息源 。

　　/wsrm:CreateSequenceResponse/wsrm:Accept/{any}

　　这是一种基于模式进行扩展的机制 ,允许不同(可扩展的)类型的信息能被传送 。

　　/wsrm:CreateSequenceResponse/wsrm:Accept/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:CreateSequenceResponse/{any}

　　这是一种基于模式进行扩展的机制 ,允许不同(可扩展的)类型的信息能被传送 。

　　/wsrm:CreateSequenceResponse/@{any}

　　这是一种可基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　8.6 关闭序列

　　有时候在使用可靠消息序列过程中 , 可靠消息源和可靠消息 目 的地希望不再继续使用某个序列 。简单的终止序列 ,而丢弃由可靠消息目的地管理的状态 ,这样可靠消息源无法知道最终成功传送到可靠消息目的地的消息范围 。为了确保序列结束时能够了解到该序列的最终状态 ,可靠消息源或可靠消息目的地可以选择在终止序列之前先关闭它 。

　　如果可靠消息源希望关闭序列 ,那么它发送一条包含 CloseSequence元素的消息到可靠消息 目 的地 。该消息表明可靠消息目的地不应再接受任何该序列的新消息 , 不包括那些在 CloseSequence元素由可靠消息目的地解释之前就已经接受的消息 。在收到该消息后 ,或者继可靠消息 目 的地关闭该序列之后 ,可靠消息 目 的 地 应 在 每 个 发 往 可 靠 消 息 源 并 且 跟 本 序 列 相 关 的 消 息 中 包 含 一 个 最 终 的 Se- quenceAcknowledgement头块(在 可 靠 消 息 目 的 地 中 应 包 含 Final 元 素) , 这 些 消 息 包 括 CloseSe- quenceResponse元素或者任何传送到可靠消息源的序列故障 。

　　为了使可靠消息目的地能够判断其是否已经接收到序列中的全部消息 ,可靠消息源宜在其发送的任何 CloseSequence消息中都包含 LastMsgNumber元素 。可靠消息目的地能使用该信息 ,实现由/ws- rm:CreateSequenceResponse/wsrm: IncompleteSequenceBehavior指定的行为 。 在所有的关闭序列的CloseSequence消息中 ,LastMsgNumber元素的值应相同 。

　　如果可靠消息目的地决定关闭一个序列 , 它可以通过给该序列中 AcksTo元素的端点引用发送 一个消息体中包含 CloseSequence元素的消息来通知发送序列的可靠消息源 。 可靠消息 目 的地应在发往可靠消息源的消息 以 及 任 何 与 该 序 列 相 关 的 后 续 消 息 的 消 息 头 块 中 , 包 括 一 个 最 终 的 SequenceAc- knowledgement元素(在该元素中 ,可靠消息目的地应包括 Final元素) 。

　　当可靠消息目的地不准许接受任何来自特定序列的新消息时 ,它应一直处理序列生存周期消息以及确认请求 。例如 ,它应响应 AckRequested、TerminateSequence及 CloseSequence消息 。

　　注 : 后续的 CloseSequence消息对序列状态没有影响 。

　　在可靠消 息 目 的 地 希 望 中 断 使 用 序 列 的 情 况 下 , 推 荐 其 关 闭 该 序 列 。 可 参 阅 Final 和 Se- quenceClosed故障 。 只要有可能 , SequenceClosed 故障宜 代 替 SequenceTerminated 故 障 , 以 允 许 可 靠

　　消息源继续接收确认消息 。

　　下面范例定义 CloseSequence语法 :

　　xs:anyURI

　　wsrm:MessageNumberType ?

　　...

　　CloseSequence元素的各部分内容描述如下 :

　　/wsrm:CloseSequence

　　本元素可以由可靠消息源发送 ,表示可靠消息目的地不准许接受该序列的任何新消息 。本元素也可以由可靠消息目的地发送 ,表示其将不会接受该序列的任何新消息 。

　　/wsrm:CloseSequence/wsrm:Identifier

　　可靠消息源或可靠消息目的地应在它们发送的任何 CloseSequence消息中包含本元素 。 可靠消息源或可靠消息目的地应把本元素的值设定为正在关闭序列的绝对 URI(符合 RFC3986格式) 。

　　/wsrm:CloseSequence/wsrm:LastMsgNumber

　　可靠消息源宜在其发送的任何 CloseSequence消息中包含本元素 。 LastMsgNumber元素 指 定 了在关闭序列的所有序列运输消息中最大的消息编号 。

　　/wsrm:CloseSequence/wsrm:Identifier/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:CloseSequence/{any}

　　这是一种基于模式进行扩展的机制 ,允许不同(可扩展)类型的信息能被传送 。

　　/wsrm:CloseSequence/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　作为对 CloseSequence请求消息的回应 ,发送的消息体中会包含 CloseSequenceResponse元素 。 它表明响应者已经关闭了该序列 。

　　下面范例定义 CloseSequenceResponse语法 :

　　xs:anyURI

　　...

　　CloseSequenceResponse元素的各部分内容描述如下 :

　　/wsrm:CloseSequenceResponse

　　本元素包含在作为对 CloseSequence请求消息的回应消息体中发送 ,表明响应者已经关闭了序列 。 /wsrm:CloseSequenceResponse/wsrm:Identifier

　　响应者(可靠消息源或可靠消息目的地)应在它们发送的任何 CloseSequenceResponse消息中包含本元素 。 响应者应把本元素的值设定为正在关闭序列的绝对 URI(符合 RFC3986格式) 。

　　/wsrm:CloseSequenceResponse/wsrm:Identifier/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:CloseSequenceResponse/{any}

　　这是一种基于模式进行扩展的机制 ,允许不同(可扩展)类型的信息能被传送 。

　　/wsrm:CloseSequenceResponse/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　8.7 序列终止

　　当使用完序列后 ,可靠消息源往可靠消息目的地发送一条包含 TerminateSequence元素的消息体 ,表示该序列已完整 ,可靠消息源不会再发送与该序列相关的消息 。接收到 TerminateSequence消息后 ,可靠消息目的地能安全地收回任何与该消息相关的资源 。正常使用情况下 , 当序列中的所有消息都已确认后 ,可靠消息源将结束序列的使用 。可靠消息源可以在不考虑消息确认状态的情况下 , 随时自由终止或关闭某个序列 。

　　为了使可靠消息目的地能够判断其是否已经接收到了序列中的所有消息 ,可靠消息宜在其发送的任何 TerminateSequence消息中包含 LastMsgNumber元素 。可靠消息 目 的地能使用该信息来实现 一些行为 。例如 ,来 实 现/wsrm: CreateSequenceResponse/wsrm: IncompleteSequenceBehavior表 示 的 行为 。TerminateSequence消息中的 LastMsgNumber值应等于可靠消息源在同一序列其他消息中设置的 LastMsgNumber元素值 。

　　如果可靠消息目的地自行决定终止某个序列 , 它可以通过向序列 AcksTo元素中的端点引用发送包含 TerminateSequence元素的消息体来通知该事件的可靠消息源 。可靠消息目的地应在该消息中包含一个最终的 SequenceAcknowledgement(在该元素中可靠消息目的地应包含 al元素)头块 。

　　下面范例定义 TerminateSequence的语法 :

　　xs:anyURI

　　wsrm:MessageNumberType ?

　　...

　　TerminateSequence的各部分内容描述如下 :

　　/wsrm:TerminateSequence

　　本元素可以由可靠消息源发送 ,表明其完全使用了该序列 ,也表明可靠消息目的地能够安全回收任何与被标识序列相关的资源 。可靠消息源决不能把本元素作为头块来发送 。可靠消息源可以重发本元素 。一旦本元素被发送 ,除了本元素 ,可靠消息源不应再向可靠消息目的地发送任何引用本序列的额外消息 。

　　本元素也可以由可靠消息目的地发送 ,表明其已经单方面终止了某序列 。此消息一经发出 ,可靠消息目的地就不应再接受该序列的任何额外消息(除相应的 TerminateSequenceResponse之外) 。一旦接收到 TerminateSequence,可靠消息源就决不能 再 发 送 此 序 列 相 关 的 任 何 其 他 消 息(除 相 应 的 Termi- nateSequenceResponse之外) 。

　　/wsrm:TerminateSequence/wsrm:Identifier

　　可靠消息源或可靠消息目的地应在其发送的所有 TerminateSequence消息中包含本元素 。 可靠消息源或可靠消息目的地应设置本元素的值为正在终止的序列的绝对 URI(符合 RFC3986格式) 。

　　/wsrm:TerminateSequence/wsrm:LastMsgNumber

　　可靠消息源宜在其发送的所有 TerminateSequence消息中包括本元素 。 LastMsgNumber元素指定了在关闭序列的所有序列运输消息中最大的消息编号 。

　　/wsrm:TerminateSequence/wsrm:Identifier/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:TerminateSequence/{any}

　　这是一种基于模式进行扩展的机制 ,允许不同(可扩展)类型的信息能被传送 。

　　/wsrm:TerminateSequence/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　作为对接收到的 TerminateSequence请求消息的响应 , 包 含 TerminateSequenceResponse元 素 的消息体将会被发送 ,表明响应者已经终止了该序列 。

　　下面范例定义 TerminateSequenceResponse的语法 :

　　xs:anyURI

　　...

　　TerminateSequence的各部分内容描述如下 :

　　/wsrm:TerminateSequenceResponse

　　作为对接收到的 TerminateSequence请求消息的响应 ,把本元素包含进消息体中的消息将会被发送 ,表明响应者已经终止了该序列 。 响应者不应把本元素作为头块来发送 。

　　/wsrm:TerminateSequenceResponse/wsrm:Identifier

　　响应者(可靠消息源或可靠消息目的地)应在其发送的任何 TerminateSequenceResponse消息中包含本元素 。 响应者应把本元素的值设置为正在终止的序列的绝对 URI(符合 RFC3986格式) 。

　　/wsrm:TerminateSequenceResponse/wsrm:Identifier/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:TerminateSequenceResponse/{any}

　　这是一种基于模式进行扩展的机制 ,允许不同(可扩展)类型的信息能被传送 。

　　/wsrm:TerminateSequenceResponse/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　接收到 TerminateSequence消息后 , 接 收 者(可 靠 消 息 源 或 可 靠 消 息 目 的 地) 应 相 应 地 回 复 一 条TerminateSequenceResponse消息 ;如果该序列未知 ,则生成 UnknownSequenceFault错误 。

　　8. 8 序列

　　本标准使用 Sequence头块跟踪并管理消息的可靠传送 。 可靠消息源应在所有要求可靠传输的消息中包含一个 Sequence头块 。可靠消息源应适用唯 一 Identifier元素标识序列 ,并且可靠消息源应为序列中每个消息指定一个 MessageNumber元素 ,该元素从初始值 1 依次递增 。 这些值包含在此序列上下文传送消息的 Sequence头块中 。

　　可靠消息源不应在任何消息中包含超过一个 Sequence头块 。

　　下面范例定义它的语法 :

　　xs:anyURI

　　wsrm:MessageNumberType

　　...

　　Sequence头块的各部分内容描述如下 :

　　/wsrm:Sequence

　　本标准元素和先前建立的可靠消息序列包含的消息相关 。 它包含序列唯 一 Identifier以及消息在该序列中的顺序位置 。可靠消息目的地应理解 Sequence头块 。可靠消息源应给 Sequence头块元素的mustUnderstand属性 指 定 值 为 1 或 者 true(取 决 于 相 应 的 SOAP 版 本 的 命 名 空 间 到 Sequence 的SOAP头块) 。

　　/wsrm:Sequence/wsrm:Identifier

　　在 SOAP信封中包含 Sequence头块的可靠消息源 ,应在该头块中包含本元素 。可靠消息源应设置

　　本元素的值为唯一标识该序列的绝对 URI(符合 RFC3986格式) 。

　　/wsrm:Sequence/wsrm:Identifier/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:Sequence/wsrm:MessageNumber

　　可靠消息源应在其创建的任何 Sequence头块中包含本元素 。本元素属于 MessageNumberType类型 。本元素代表序列中消息的顺序位置 。在整个序列中 ,序列消息编号从 1 开始并且以 1 递增 。关于消息编号翻转故障见 9. 5。

　　/wsrm:Sequence/{any}

　　这是一种基于模式进行扩展的机制 ,允许不同(可扩展)类型的信息能被传送 。

　　/wsrm:Sequence/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　示例 :Sequence头块例子如下 :

　　http://example.com/abc

　　10

　　8.9 请求确认

　　AckRequested头块的目的是通知可靠消息目的地 ,可靠消息源正在请求可靠消息 目 的地发送 Se- quenceAcknowledgement。

　　可靠消息源可以在任何时候通过独立地向可靠消息目的地传送 AckRequested头块请求一个确认消息(例如 ,发送一条 SOAP消息 ,该 SOAP消息信封头块包含 AckRequested,而 SOAP消息体为空) 。或者采用另外一种方式 ,可靠消息源可以在任何发向可靠消息 目 的地的消息中包含 AckRequested 头块 。可靠消息目的地宜处理其接收到的任何消息中包含的 AckRequested头块 。如果在处理以“piggy- backed”方式传输过来的 AckRequested头块时产生 non-mustUnderstand故障 ,则应生成一个故障 ,但不应影响对原来消息的处理 。

　　可靠消息目的地接收到一条包含 AckRequested头块的消息 ,则应向已知序列的 AcksTo端点引用发送一条包含 SequenceAcknowledgement头块的消息(见 8. 5) , 或产生一个 UnknownSequence故障 。建议可靠消息目的地返回 AcknowledgementRange或 None元素而不是 Nack元素(见 8. 10) 。

　　下面范例定义它的语法 :

　　xs:anyURI

　　...

　　AckRequested头块的各部分内容描述如下 :

　　/wsrm:AckRequested

　　本元素为被标识序列请求确认消息 。

　　/wsrm:AckRequested/wsrm:Identifier

　　在 SOAP信封头中包含 AckRequested 的可靠消息源应在该头块中包含本元素 。 可靠消息源应把该元素的值设置为绝对 URI(符合 RFC3986格式) ,该 URI唯一标识请求的序列 。

　　/wsrm:AckRequested/wsrm:Identifier/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:AckRequested/{any}

　　这是一种基于模式进行扩展的机制 ,允许不同(可扩展)类型的信息能被传送 。

　　/wsrm:AckRequested/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　8. 10 序列确认

　　可靠消息目的地使用 SequenceAcknowledgement头块通知可靠消息源接收成功 。 确认消息能通过用 AckRequested指令来显示地请求(见 8. 9) 。

　　可靠消息 目 的地可以独立传送 SequenceAcknowledgement头块(例如 , 发送一条 SOAP 消息 , 该SOAP消息信封头块包含 SequenceAcknowledgement,而 SOAP消息体为空) 。

　　或者采用另外一种方式 ,可靠消息目的地可以在任何发往端点引用(端点引用由 AcksTo确定) 的SOAP信封中包含 SequenceAcknowledgement头块 。可靠消息源宜处理其接收到的任何消息中的 Se- quenceAcknowledgement头块 。如果在处理以“piggy-backed”方式传输过来的 SequenceAcknowledge- ment头块时产生 non-mustUnderstand故障 ,则应生成一个故障 ,但不应影响对原来消息的处理 。

　　在序列的创建过程中 ,可靠消息源可以指定 WS-Addressing匿名 IRI作为该序列中 AcksTo端点引用的 address。 当可靠消息源指定 WS-Addressing匿名 IRI作为 AcksTo端点引用的 address时 ,可靠消息目的地应在 SOAP信封中为创建的序列传送一个 SequenceAcknowledgement头块 。该 SOAP信封在特定绑定协议的反向信道中传输 。该信道由接收到的包含一个 SOAP信封(该 SOAP信封为相同的序列 Identifier包含 Sequence头块和/或 AckRequested 头块) 的消息上下文提供 。 当可靠消息 目的地接收到 AckRequested头块 , 同时该序列的端点引用是 WS-Addressing匿名 IRI,则可靠消息 目 的地宜在特定绑定协议的反向信道上响应 ,该通道由包含 AckRequested头块的接收到的消息提供 。

　　下面范例定义了它的语法 :

　　xs:anyURI

　　[ [ [

　　| +

　　? ]

　　| wsrm:MessageNumberType + ]

　　...

　　SequenceAcknowledgement头块的各部分内容描述如下 :

　　/wsrm:SequenceAcknowledgement

　　该元素包含序列确认信息 。

　　/wsrm:SequenceAcknowledgement/wsrm:Identifier

　　在 SOAP信封中包含 SequenceAcknowledgement头块的可靠消息 目 的 地 , 应 在 那 个 SOAP 头 块中包含本元素 。可靠消息目的地应设置本元素的值为能够唯一标识该序列的绝对 URI(符合 RFC3986格式) 。可靠消息目的地包含的 SequenceAcknowledgement头块中 ,不应有相同的 Identifier值 。

　　/wsrm:SequenceAcknowledgement/wsrm:Identifier/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange

　　在 SequenceAcknowledgement头块中 ,可靠消息目的地可以包含一个或多个本元素的实例 。本元

　　素包含被可靠消息目的地成功接受的序列消息编号范围 。该范围不应重叠 。如果一个兄弟元素 Nack或 None作为 SequenceAcknowledgement的子元素出现 ,那么可靠消息目的地就不应包含本元素 。

　　/wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange/@Upper

　　可靠消息目的地应 把 本 属 性 的 值 设 置 为 被 可 靠 消 息 目 的 地 接 受 的 序 列 中 最 大 的 连 续 消 息 的 消息号 。

　　/wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange/@Lower

　　可靠消息目的地应 把 本 属 性 的 值 设 置 为 被 可 靠 消 息 目 的 地 接 受 的 序 列 中 最 小 的 连 续 消 息 的 消息号 。

　　/wsrm:SequenceAcknowledgement/wsrm:AcknowledgementRange/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　/wsrm:SequenceAcknowledgement/wsrm:None

　　如果可靠消息目的地尚未接受特定序列的任何消息 ,那么可靠消息 目 的地应在 SequenceAcknowl- edgement头块中包含本元素 。如果一个兄弟元素 AcknowledgementRange或 Nack作为 SequenceAc- knowledgement的子元素出现 ,那么可靠消息目的地就不应再包含本元素 。

　　/wsrm:SequenceAcknowledgement/wsrm:Final

　　可靠消息目的地可以在 SequenceAcknowledgement头块中包含本元素 。本元素表明可靠消息 目的地没有收到特定序列的新元素 。可靠消息源能够保证 ,SequenceAcknowledgement头块确认的消息范围将来不会改变 。 当序列关闭时 ,可靠消息目的地应包含本元素 。 当发送一个 Nack 时 ,可靠消息 目的地不应包含本元素 ,它只能在发送 AcknowledgementRange元素或 None时使用 。

　　/wsrm:SequenceAcknowledgement/wsrm:Nack

　　可靠消息目的地可以在 SequenceAcknowledgement头中包含本元素 。如果使用该元素 ,则可靠消息目的地应把本元素的值设置为 MessageNumberType,以代表序列中未接收消息的 MessageNumber。如果一个兄弟 AcknowledgementRange或 None元 素 也 作 为 SequenceAcknowledgement的 子 元 素 出现 ,可靠消息目的地就不应再包括 Nack元素 。一旦接收到一个 Nack,可靠消息源宜重新传输该 Nack标识的消息 。如果 Nack指定的消息已经在先前的 AcknowledgementRange中确认 ,那么可靠消息 目的地不应再处 理 包 含 此 Nack 的 SequenceAcknowledgement。 如 果 Nack 指 定 的 消 息 已 经 在 先 前 的AcknowledgementRange中被确认 ,可靠消息源宜忽略包含此 Nack 的 SequenceAcknowledgement。

　　/wsrm:SequenceAcknowledgement/{any}

　　这是一种基于模式进行扩展的机制 ,允许不同(可扩展)类型的信息能被传送 。

　　/wsrm:SequenceAcknowledgement/@{any}

　　这是一种基于模式进行扩展的机制 ,允许元素中加入额外的属性 。

　　示例 :SequenceAcknowledgement元素示例 :

　　序列中消息编号为 1…10的消息已经由可靠消息目的地接受 。

　　http://example.com/abc

　　序列中消息编号为 1、2、4、6 和 8 的消息已经由可靠消息目的地接受 ,消息 3 和消息 7 尚未接受 。

　　wsrm:SequenceAcknowledgement>

　　http://example.com/abc

　　序列中消息编号为 3 的消息尚未由可靠消息目的地所接受 。

　　http://example.com/abc

　　3

　　9 故障

　　9. 1 概述

　　CreateSequence消息交换故障如 WS-Addressing中 定 义 的 那 样 进 行 处 理 。 创 建 消 息 被 拒 绝 的 故障可能是对此操作的答复 。 当携带可靠消息头块的消息未能由 目标识别或序列已终止时 ,端点就会产生未知序列故障 。如果要求使用本标准的可靠消息目的地接收到未使用本标准的消息 ,那么可靠消息目的地就会产生 WSRMRequired故障 。本章节所有其他故障都和已知序列相关 。 产生和已知序列相关故障的目的地 ,宜传送那些故障 。 如果传送那些故障 ,应把故障传送到与 Acknowledgement元素相同的 目的地 。

　　产生本标准规定的故障的实体应包含下面定义的默认故障行为 IRI作为[action]属性 。 以下值可供参考 :

　　http://docs.oasis-open.org/ws-rx/wsrm/200702/fault

　　如果满足序言中阐述的条件 ,本章所定义的故障就会产生 。故障处理规则在 WS-Addressing第 6章 SOAP Binding中定义 。

　　[Code]故障代码元素 。

　　[Subcode]故障子码元素 。

　　[Reason]用英语描述的故障原因元素 。

　　[Detail]详细原因元素 。如果未出现 ,则表示没有为该故障定义本元素 。 如果定义了多于一个的本元素 ,实现本标准时应按照这些元素定义时的顺序包含全部详细原因 。

　　产生 WS-ReliableMessaging故障的实体应设置[Code]属性为“Sender”或者“Receiver”。这些属性被序列化成 XML 的文本 ,如表 2所示 :

　　表 2 [code]属性

　　上述属性绑定在 SOAP1. 2规范上时 ,故障格式如下 :

　　http://docs.oasis-open.org/ws-rx/wsrm/200702/fault

　　< ! --Headers elided forbrevity.-->

　　[Code]

　　[Subcode]

　　[Reason]

　　[Detail]

　　...

　　当故障是在处理可靠消息头块时触发的 ,并且属性绑定在 SOAP1.1规范上时 ,故障格式如下 :

　　wsrm:FaultCodes

　　[Detail]

　　...

　　< ! --Headers elided forbrevity. -->

　　[Code]

　　[Reason]

　　当故障是在处理 CreateSequence请求消息时产生的 ,并且属性绑定在 SOAP1.1 规范上时 ,故障格式如下 :

　　[Subcode]

　　[Reason]

　　9.2 SequenceFault元素

　　SequenceFualt元素是一种容器元素 。SequenceFault元素的目的是携带某种特定细节的故障 ,这种故障是本标准中处理属于序列的消息时产生的 。实现本标准的节点应只有在结合 SOAP1. 1 规范的故障机制的情况下使用 SequenceFault容器 ,而不应在结合 SOAP1.2规范的绑定时使用 SequenceFault容器 。

　　下列范例定义了它的语法 :

　　wsrm:FaultCode

　　... ?

　　...

　　SequenceFault元素的各部分内容描述如下 :

　　/wsrm:SequenceFault

　　本元素包含实现本标准的结点的序列故障信息 。

　　/wsrm:SequenceFault/wsrm:FaultCode

　　产生 SequenceFault的结点应把本元素的值设置为由故障集合[Subcodes]限定的值 。

　　/wsrm:SequenceFault/wsrm:Detail

　　该元素为可选元素 ,携带与该故障描述相关的应用程序特定的错误信息 。

　　/wsrm:SequenceFault/wsrm:Detail/{any}

　　与故障描述相关的应用程序特定的错误信息 。

　　/wsrm:SequenceFault/wsrm:Detail/@{any}

　　与故障描述相关的应用程序特定的错误信息 。

　　/wsrm:SequenceFault/{any}

　　这是一种基于模式的扩展机制 ,允许不同(可扩展)类型的信息能被传送 。

　　/wsrm:SequenceFault/@{any}

　　这是一种基于模式的扩展机制 ,允许元素中加入额外的属性 。

　　9.3 序列终止故障

　　产生本故障的端点宜合理地把终止序列的决定通知给相应的端点 。

　　属性 :

　　[Code] Sender orReceiver

　　[Subcode] wsrm:SequenceTerminated

　　[Reason] The Sequence has been terminateddue to anunrecoverable error.

　　[Detail]

　　xs:anyURI

　　序列终止故障相关汇总见表 3。

　　表 3 序列终止故障相关汇总表

　　9.4 未知序列故障

　　属性 :

　　[Code] Sender

　　[Subcode] wsrm:UnknownSequence

　　[Reason] The value of wsrm:Identifier isnot a known Sequence identifier. [Detail]

　　xs:anyURI

　　未知序列故障相关汇总见表 4。

　　表 4 未知序列故障相关汇总表

　　9.5 无效确认故障

　　当可靠消息源接收到一条包含 SequenceAcknowledgement元素的消息覆盖了从未发送过的消息时 ,产生本故障 。

　　[Code] Sender

　　[Subcode] wsrm:InvalidAcknowledgement

　　[Reason] The SequenceAcknowledgement violates the cumulativeAcknowledgement invariant. [Detail]

　　...

　　无效确认故障相关汇总表见表 5。

　　表 5 无效确认故障相关汇总表

　　9.6 消息编号翻转故障

　　当满足下表中所列条件时 ,可靠消息目的地应产生本故障 。

　　属性 :

　　[Code] Sender

　　[Subcode] wsrm:MessageNumberRollover

　　[Reason] The maximum value for wsrm:MessageNumber has been exceeded.

　　[Detail]

　　xs:anyURI

　　wsrm:MessageNumberType消息编号翻转故障相关汇总表见表 6。

　　表 6 消息编号翻转故障相关汇总表

　　9.7 拒绝创建序列故障

　　属性 :

　　[Code] Sender orReceiver

　　[Subcode] wsrm:CreateSequenceRefused

　　[Reason] The Create Sequence request has been refusedbytheRM Destination. [Detail]

　　xs:any

　　拒绝创建序列故障相关汇总表见表 7。

　　表 7 拒绝创建序列故障相关汇总表

　　9. 8 序列关闭故障

　　由可靠消息目的地产生的这个故障表明指定的序列已经关闭 。 当要求可靠消息目的地接受一个已关闭序列的消息时 ,应产生本故障 。

　　属性 :

　　[Code] Sender

　　[Subcode] wsrm:SequenceClosed

　　[Reason] The Sequence is closed and cannot acceptnew messages.

　　[Detail]

　　xs:anyURI

　　序列关闭故障相关汇总表见表 8。

　　表 8 序列关闭故障相关汇总表

　　9.9 要求 WSRM 故障

　　如果可靠消息目的地要求使用本标准 , 当其接收到的消息未使用本标准时 ,这个故障就会产生 。

　　属性 :

　　[Code] Sender

　　[Subcode] wsrm:WSRMRequired

　　[Reason] TheRM Destinationrequires the use ofWSRM.

　　[Detail]

　　xs:any

　　10 安全威胁及对策

　　10. 1 概述

　　本标准考虑了两类安全要求 ,包括使用本标准的应用程序和本标准 。

　　关于使用本标准的应用程序的安全要求 ,本标准不做任何假设 。然而 ,一旦在给定业务环境中满足那些安全要求 ,针对此操作环境的本标准的增加部分不宜破坏安全要求的实施 ;本标准的使用不宜在另外的安全系统上创建额外的攻击媒介 。

　　在实现或使用本标准时 ,有许多其他的安全问题需要考虑 。 下面的材料不宜看作是 “检查列表 ”。本标准的实现者和 使 用 者 需 尽 快 做 安 全 分 析 来 确 定 他 们 各 自 特 定 的 威 胁 概 要 和 对 这 些 威 胁 的 适 当反应 。

　　如果本标准的实现者不进行妥善处理的话 ,在安全性和可靠消息传递之间有一个核心矛盾可能会产生问题 ;安全性的一个方面就是防止消息重发 ,但是本协议侧重点之一就是重发消息直到它们被确认 。 因此 ,如果安全子系统处理某个消息 ,但是在可靠消息子系统接收到该消息前发生了故障 ,那么有可能(并很可能)安全子系统将把后续副本作为重复的消息并且丢弃 。 同时 ,可靠消息子系统将继续等待并请求那些丢失的消息 。宜小心避免并防止这种情况出现 。

　　10.2 威胁及对策

　　10.2. 1 概述

　　本标准的主要安全要求是保护标准语义和标准的不变量 , 以应对各种威胁 。下面章条描述了几种对本协议完整性和操作性的威胁 ,并提供了对这些威胁的一般性对策概述 。本协议的实现者和使用者宜记住 ,所有的威胁并不适用于所有的业务环境 。

　　10.2.2 完整性威胁

　　10.2.2. 1 概述

　　一般而言 ,把以下机制定义为对本标准的威胁 :允许攻击者修改序列通信消息 、序列生存周期消息 、确认消息 、确认请求 、序列相关故障 ,或者允许攻击者修改相关的可靠消息头块 。

　　例如 ,如果攻击者能够交换在可靠消息源和可靠消息 目 的地之间传输的消息的 Sequence头块 ,那么它们已经破坏了标准实现保证第一不变量(见 7. 3)的能力 。造成的结果就是无法保证应用程序 目 的地能以相同的顺序接收来自应用程序源发送的消息 。

　　10.2.2.2 完整性威胁的对策

　　通常可以通过使用某些通信协议栈级别的数字签名来应对完整性威胁 。请注意 , 为了应对头块交

　　换攻击 ,签名宜包括 SOAP体和任何有关的 SOAP头块(如 Sequence头块) 。 由于某些头块(AckRe- quested,SequenceAcknowledgement)独 立 于 SOAP 消 息 体 , 标 准 的 实 现 应 允 许 被 这 些 头 块 覆 盖 的签名 。

　　10.2.3 资源消耗威胁

　　10.2.3. 1 概述

　　创建可靠消息目的地的序列 ,会消耗可靠消息目的地系统的各种资源 。这些资源可能包括网络连接 、数据库表 、消息队列等 。这种行为能用作进行对可靠消息 目 的地的拒绝服务攻击 。例如 ,一种简单的攻击就是反复向可靠消息目的地发送 CreateSequence消息 。 另一种攻击是为 “要求顺序传送消息 ”的服务创建一个序列 ,然后使用这个序列向该服务发送一个庞大的消息流 ,造成消息流中消息编号为 “1”的消息被忽略 。

　　10.2.3.2 资源消耗威胁的对策

　　有很多措施可以用来应对资源消耗威胁 。本标准在技术上提倡可靠消息 目 的地限制特定实体/主体组的能力 。这减少了潜在攻击者的数量 ,并在某些情况下 ,允许确定任何攻击者的身份 。

　　反回来 , 限制序列创建能力依赖于可靠消息 目 的地辨别和验证发起 CreateSequence消息的可靠消息源的能力 。

　　10.2.4 序列欺骗威胁

　　10.2.4. 1 概述

　　序列欺骗威胁是这么一类威胁 :攻击者使用对特定序列的 Identifier的了解来伪造序