政务信息资源交换体系第2部分：分布式系统间信息交换技术要求.pdf

1、SE0S “TFq qI| EGS N302-2 2005 M 12 15 S5 o8“ 2 ss TW/ 1 pp o8“pTF = K1 o8“ 2 ss TW/ 1 pp I pin : 120 0S98F ) “ Y g u v 1| 010 84029792 . 010 84029792 m 13301018890 0q 国家标准政务信息资源交换体系 第 2 部分：分布式应用间信息交换技术要求（征求意见稿） 编制说明 一、 任务来源 该标准是根据国家标准化管理委员会制修订国家标准专项国家电子政务标准体系建设项目一期工程政务信息资源交换体系制定的。本部分是该系列标准的第 2 部分：分布

2、式系统间信息交换技术要求，由北京航空航天大学、易达迅网络科技有限公司、黎明网络有限公司、万达信息股份有限公司、大唐电信科技产业集团、中国电子技术标准化研究所、浙江建达科技有限公司负责起草。 二、 编制原则 1） 积极采用国家标准和国外先进标准的技术，并贯彻国家有关政策与法规； 2） 标准编制要具有一定的先进性、科学性；配合政务信息资源交换的推进，使标准具有实用性和可操作性； 3） 标准编制要保证标准具有良好扩展性。对于直接采用的国际和国家标准要及时跟踪和评估最新变化，如有必要及时进行标准修订。 4） 标准内容要符合中国国情，广泛征求用户，企业、专家和管理部门的意见，并做好意见的正确处理； 5）

3、 面向市场，参编自愿；标准编制工作与意见处理，应坚持公平、公正，切实支持产业发展； 6） 合理利用国内已有标准科技成果，处理好标准与知识产权的关系； 7） 充分利用国内已有的电子政务各类重点项目、示范项目的建设经验，处理好标准的先进性和实用性间的关系； 8） 标准结构和编写规则，按照GB/T1.1-2000执行。 三、 工作过程 任务下达后， 2004 年 11 月 17 日由国家标准化管理委员会和国务院信息化工作办公室组织 18 家单位成立政务信息资源目录体系与交换体系标准编写组，召开联合会议及时安排了该项目的制定工作。 由起草单位负责该部分标准的编写工作。 从 2004年底启动该标准的制定

4、以来， 课题组先后召开了 20余次标准讨论会，其中大型封闭修改 4 次。 在多次听取国家电子政务总体专家组以及标准化领域专家对标准的修订意见和建议后，经起草组认真的研究和讨论，对这些意见进行了合理化处理，最终在 2005 年 9 月初形成了标准的征求意见稿。 四、 主要内容说明 本部分给出了分布式系统间交换机制的交换体系在互连互通时所涉及的技术要求，主要是交换协议。交换协议的内容包括：网络传输、消息框架、消息安全、消息可靠性、服务描述、流程协同。 本部分标准的概要内容说明如下： 1. 交换协议 交换协议描述了交换中不同层次对消息格式的要求。交换协议栈的内容包括：消息传送、消息框架、消息寻址协议

5、、可靠消息、安全消息、业务表示、流程协 议。 (1)传送协议 传送层交换主要面临的问题是协议的多样性，常用的传送协议有 http 协议、smtp 协议、 jms 协议， ftp 协议等。如果在建设政务信息资源交换系统中没有规范的、统一的传送协议规定，那么系统间就难以方便地实现数据交换。 本部分标准在传输层明确了各交换节点间所必需支持的网络传输协议，即：http/https，从网络传输的角度统一了互联技术。对于其它的传输协议可以选择性的支持，例如： smtp， jms 等。 (2) 消息框架 消息传递如同信件的邮递，为了便于交换必须规定一个包容信息资源的“信封” ，消息框架就是消息传递所用的“信

6、封” 。 在消息框架中主要分为消息头和消息体， 消息头主要包含交换过程中协助交换处理节点进行统一处理所需的信息， 例如： 发送的目的地址、 发送的来源地址、消息标识符、可靠性要求、安全要求、消息体数据的处理指令等。 消息体一般存放业务相关的数据，例如：企业基本信息、企业税务信息等。另外，消息体还存放一些差错信息，差错信息就是交换处理节点接到一个消息进行处理时对无法正常处理的情况进行的说明性信息， 这一点也类似邮局退回一个无法找到接收人的信件。 在信息交换中考虑到实际所交换的信息在类型、容量方面的复杂性，通常要求消息框架支持附件，用户根据需要可以在消息中携带任意数量、任意类型的附件文件。 为了支

7、持异构的交换系统在消息框架上的互通，必须为消息框架的结构和XML 编码方案进行明确的规定。本部分采用了 SOAP1.2 作为消息的框架，这主要是考虑到 SOAP 的简洁性、可扩展性和应用的普遍性。 (3)消息寻址协议 在消息的发送过程中，地址信息的表达是非常基础的。这种基础性是因为交换自身的目的所决定的。例如，在我国的邮政信封中左上角标明信件送达目的地邮编，接下来是具体地址，收件人在信封中央，发件人信息在右下角这些规定。 在信息资源交换的领域中消息寻址所表达的含义和我们经常能够看到的邮政信封、邮件系统中所表达的地址信息略有不同。在邮件系统或者邮政系统中寻址信息通常只要表达发送方地址、接收方地址

8、即可。但在信息资源交换系统中寻址必须表达清楚对于消息中携带信息的处理地址。 这种区别主要是因为信息资源交换系统中通常消息是面向系统自动化处理的，因此必须标明对消息的处理指令。 对于消息寻址我们首先需要确定寻址信息的内容，例如：常见的消息来源、消息目的地、服务名称等。其次，需要明 确这些消息寻址的内容如何与 SOAP消息框框架进行邦定。 为了保证异构的交换系统以消息机制进行交换时在消息的寻址方面能够互通，必须对消息寻址从语义和 XML 语法方面进行相应的规定。本部分标准，采用国际标准 ws-addressing 作为消息寻址协议。 （ 4）可靠性协议 在政务信息资源交换中绝大多数的交换都需要有可

9、靠性的支持。 常见的可靠性要求包括： 9 至少一次消息成功送达的语义； 9 最多一次消息成功送达的语义； 9 一次并且仅一次消息成功送达的语义 9 一组消息必须按照一定的顺序成功送达的语义。 如果在两个异构的交换系统间实现消息的可靠互通， 没有一个统一的消息可靠的描述语义和 XML 表达语法是不可能的。本部分标准采用国际标准ws-reliability 作为可靠消息的协议。 (5) 业务表示 信息交换中必须支撑上层的业务目标。 业务目标通常由具体的业务表示来描述。在信息交换过程中如果对于业务表示没有统一的规范，互联互通只能停留在数据的层面。这种情况下，各个系统无法理解彼此交换的业务数据和业务操

10、作，各个异构的系统间难以有效的实现政务信息资源的交换。 业务表示规范的确立可以保证异构的系统间对于业务信息有一个一致的统一的理解，是实现政务信息资源交换的重要内容之一。业务表示规范从业务数据和业务服务两个方面规定了业务信息的表示规则。 业务数据 业务数据的表示首先从完整性的角度考虑表示的范围。 完整性的需要考虑的一个非常重要的检验准则是否能满足异构应用间对数据达成统一理解的需要。 元数据在业务表示中扮演了非常重要的角色，因为元数据是描述其他数据的数据，它可以协助应用系统自动理解数据的含义。 另外，完整性还要考虑的一个方面是对于结构化、半结构化和非结构化数据的表示。政务信息资源交换通常是这三种类

11、型的数据的混合。 本部分采用 XML 作为数据表示的语法，制定了一套业务数据的表示方法。 业务服务 信息交换的发展正从单纯的消息交换向面向服务的交换方向发展， 面向服务交换的最大好处就是交换节点间具有了语义松耦合的特点。 实现消息操作语义松耦合的一种方法就是建立服务描述规范， 服务描述规范主要是对消息体内容的一种规范方法，描述了抽象的服务模型和服务的邦定接口。如果没有对消息体进行规范，则无法真正实现政务信息资源交换，因为系统无法理解信息资源交换中的主要对象，即政务信息资源及其操作指令。服务描述采用了国际标准 wsdl2.0。 (6) 流程协议 政务信息资源交换特别是跨部门的信息资源交换是一个非

12、常复杂的过程。 很多交换并不是在两个交换节点间一次交互就可以完成。例如：新增企业开业的业务， 如果企业是餐饮类型的企业， 那么开业申请涉及的政府主管部门包括工商局、税务局、质监局、卫生局等。 对于跨多个政府部门的信息资源交换系统， 如果没有一种统一的服务接口和协议控制， 那么在参与交换的交换节点间难以协作完成跨多个政府部门的信息资源交换。即使能够完成，在性能、管理维护方面都会存在很大的问题。 因此，我们必须制定统一的协调控制协议，各交换节可以通过该协议协同完成跨多个政府部门的复杂的政务信息资源交换。这方面国际上有相关的标准，即OASIS Web Services Business Proces

13、s Execution Language，目前，主流厂商的产品都支持这个标准，在本部标准流程协议采用 Web Services Business Process Execution Language Version 2.0 作为描述语言。 流程的协议标准离不开消息的事务性要求， 在信息资源交换中事务的类型主要有常事务和短事务两种类型。关于消息的事务性，国际上比较有代表性的标准是 IBM 的 ws-trasaction、 ws-conversition 和 oasis 组织的 Business Transaction Protocol，考虑到版权的问题，本部分标准采用了 oasis 组织的 BT

14、P。 五、 与其他标准之间的关系 本部分是总标题政务信息资源交换体系下的第 2 部分，本部分与政务信息资源交换体系第 1 部分 总体框架保持了紧密的联系和高度的一致性。 本部分与政务信息资源目录体系第 2 部分 核心元数据有一定的联系。服务核心元数据中的服务模型描述文档地址将会指向本标准中服务描述的文档地址。 本部分与政务信息资源目录体系 第 2 部分 技术要求有一定的联系。在实施该标准的系统中，无论是发送消息还是接收消息时，如果没有服务提供方的服务描述信息， 则需要采用目录体系的技术要求中定义的接口查询服务提供方提供的服务描述信息。 标准起草组 205年9月GB/T XXXX.2-XXXX政

15、务信息资源交换体系 第 2 部分：分布式应用间信息交换 技术要求 Government information resource interchange systemPart 2: Distributed application interchange technical requirements （征求意见稿） 中华人民共和国国家标准 ICS 35.240.60 L 67 XXXX-XX-XX 发布 XXXX-XX-XX 实施中华人民共和国 国家质量技术监督检验检疫总局 发布GB/T .2 I 目 次 前言 . II 1 范围 . 1 2 规范性引用文件 . 1 3 术语、定义和缩略语 .

16、1 4 概述 . 2 5 消息传送 . 3 6 消息处理 . 3 6.1 概述. . 3 6.2 SOAP 消息框架 . . 3 6.3 消息寻址协议. . 3 6.4 可靠性协议 5 6.5 安全性协议 8 6.6 扩展. 13 6.7 差错处理. 14 7 业务表示 . . 14 7.1 业务数据表示. 14 7.2 业务服务描述. 19 8 流程管理 . . 21 8.1 业务流程描述协议 . 21 8.2 业务流程中的事务 . 23 9 系统监控 . . 24 9.1 概述. 24 9.2 交换节点的状态接口 . 24 9.3 服务状态. 24 9.4 日志查询接口. 24 9.5 消

17、息监视. 25 附录 A（规范性附录） 资源交换协议 XML Schema. 26 附录 B（规范性附录） 系统监控接口 WS DL. 93 附录 C（规范性附录） 消息交换模式. 103 附录 D（资料性附录） 可靠性协议示例 . 110 参考文献 . . 112 GB/T .2 II 前 言 GB/T XXXX政务信息资源交换体系分为以下 4 个部分： 第 1 部分：总体框架； 第 2 部分：分布式系统间信息交换技术要求； 第 3 部分：异构数据库接口规范； 第 4 部分：技术管理要求。 本部分为 GB/T XXXX 的第 2 部分。 本部分的附录 A、附录B、附录 C 为规范性附录，附录

18、 D 为资料性附录。 本部分由国务院信息化工作办公室提出。 本部分由国家电子政务标准化总体组归口。 本部分由中华人民共和国信息产业部提出。 本部分由国家电子政务标准化总体组归口。 本部分的起草单位：北京航空航天大学、易达迅网络科技有限公司、黎明网络有限公司、万达信息股份有限公司、大唐电信科技产业集团、中国电子技术标准化研究所、浙江建达科技有限公司 本部分主要起草人：马殿富、逯鹏、王华飞、孙其民、龚智辉、张峰昌、顾晓毅、邓洁霖、吴志刚、吴焱、王路源、王煜坤、朱岩、刘建、崔毅、徐俊杰、肖菁GB/T .2 1 政务信息资源交换体系 第 2 部分：分布式系统间信息交换技术要求 1 范围 GB/T XX

19、XX的本部分规范了政务信息资源在分布式系统间实现交换的技消息传送、消息处理、业务表示、流程协同等方面的技术要求。 本部分中主要规定了通过基于HTTP/HTTPS传送协议的WEB服务和消息方式进行交换所要求的规范，其他交换方式不在此做技术上的要求。 本部分适用于政务信息资源交换体系的开发者、建设者和其他与交换体系建设相关的人员使用，作为进行电子政务信息资源交换体系设计与建设的技术依据。 2 规范性引用文件 下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文

20、件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。 GB/T XXXX.1 政务信息资源交换体系 第1部分：总体框架 GB/T 7408-1994 (EQV ISO 8601:1988) 数据元和交换格式信息交换日期和时间表示法 GB/T 19488.1-2004 电子政务数据元素 第1部分：设计和管理规范 RFC2616-1999 超文本传输协议标准 RFC2396-1998 统一资源标识符： 通用句法 3 术语、定义和缩略语 3.1 术语和定义 GB/T XXXX.1 及GB/T 19488. 1-2004确立的以及下列术语和定义适用于GB/T XXXX的本部分。 3.1.1

21、信息资源提供者 informatio n resources provider 为信息资源交换提供信息资源的机构。 3.1.2 信息资源使用者 informatio n resources consumer 通过信息资源交换使用信息资源的机构。 3.1.3 端点 endpoint 能够对携带信息资源的消息进行处理的设备、软件系统。 3.1.4 端点引用 endpoint reference 对消息端点的引用描述。 3.2 缩略语 SOAP 简单对象访问协议 （ Simple Object Access Protocol） WSDL Web 服务描述语言 (Web Service Descrip

22、tion Language) NCName 无冒号的（ XML “non-colonized“ Names） QName 限定名称 （ Qualified Names） GB/T .2 2 URI 统一资源标识符（ Uniform Resource Identifier） UUID 全局唯一标识符（ Universally Unique Identifier） 4 概述 政务信息资源在分布式系统间实现交换的技术要求，内容主要包括消息传送、消息处理、业务表示、流程协同等方面的技术要求。其中，消息传送是基础，消息处理是核心，业务表示是应用，流程协同是应用联动。本部分采用的命名空间见表1。 4.1

23、消息传送 完成交换节点间的底层数据传送。通过遵循统一的消息传送协议（HTTP/HTTPS、 SMTP、RMI、FTP等），实现各交换节点间的数据互通。HTTP/HTTPS是必须支持的底层传送协议。 4.2 消息处理 在统一的消息框架下支持消息寻址、消息可靠性处理、消息安全性处理等功能。消息框架和消息寻址是必须支持的协议，消息可靠处理和消息安全处理是可以选择支持的协议。 4.3 业务表示 规定了业务数据表示和业务服务描述。业务表示是必须支持的协议。 4.4 流程管理 通过流程协议将现有不同应用系统和（或）新的应用系统的流程协同起来，提供一种灵活的、可变的、适应性强的业务流程调整和管理的技术手段。

24、流程协议是可选择支持的协议。 4.5 系统监控 通过监控接口对交换域内各交换结点的运行状态进行的监视，是交换体系可管理和可维护的运行支撑手段。监控接口是可选支持的。 表 1 政务信息资源交换体系命名空间 前缀 命名空间 备注 soap http:/www.w3.org/2003/05/soap-envelope S11 http:/schemas.xmlsoap.org/soap/envelope soapenc http:/schemas.xmlsoap.org/soap/encoding/ xs http:/www.w3.org/2001/XMLSchema cneg http:/ 中国电

25、子政务资源交换寻址协议消息扩展命名空间 wsa http:/www.w3.org/2005/02/addressing wsrm http:/docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd ds http:/www.w3.org/2000/09/xmldsig# xenc http:/www.w3.org/2001/04/xmlenc# wsse http:/docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd wsdl http:/w

26、ww.w3.org/2004/08/wsdl de http:/ 中国电子政务数据元命名空间 common http:/ 中国电子政务元数据通用类型命名空间 resmeta http:/ 中国电子政务信息资源元模型命名空间 bdata http:/ 中国电子政务信息资源业务数据表示命名空间 GB/T .2 3 5 消息传送 5.1 概述 消息传送规定了交换体系中需遵循的底层消息传送所采用的网络协议，此规范中传送协议规定了http/https是必须支持的传送协议, 可以采用 JMS，SMTP，FTP等作为传送协议。 5.2 HTTP/HTTPS 消息头格式 在HTTP/HTTPS协议的头部的Co

27、n tent-Type字段必须使用appli cation/soap+xml。 请求的 HTTP/HTTPS 格式，Method 字段必须取值为 POST。 响应的HTTP/HTTPS格式，Status line 字段取值必须是200或者其它标准的状态号。 5.3 HTTP/HTTPS 消息体 HTTP/HTTPS消息体应采用SOAP消息格式。 6 消息处理 6.1 概述 消息处理完成统一的消息封装和解析、消息寻址、消息可靠性处理、消息安全性处理等功能。主要由SOAP消息框架、消息寻址协议、可靠性协议、安全性协议、差错处理以及可扩展部分组成。 寻址协议保证交换节点间能够正确定位web服务和消息

28、处理服务的地址。 可靠性协议保证WEB服务和消息可靠完整的进行传输。 安去性协议保证WEB服务和消息通过统一的结构进行相同的处理。 差错处理在SOAP协议规范的标准之上进行扩展，以符合不同层次的差错处理。 扩展保证了整个协议的灵活性和可扩展性，能够使在有需要的情况下进行必要的扩展保证一定的需求。 6.2 消息框架 消息框架是政务信息资源交换中系统间传送的消息的格式规范。政务信息资源的交换必须采用SOAP1.2作为消息的封装格式。消息框架包含的内容如图1所示。 消息头中包括消息寻址、消息可靠性协议、安全性协议。消息可靠性协议在需要可靠消息传输时是必须遵循的协议规范，详细内容见6.3。安全性协议只

29、规定了消息在需要安全时所遵循的格式和处理方式，并不规定安全的算法等内容，具体的安全算法按照国家的其他相关标准，详细内容参见6.4。 消息体中包含业务数据及其业务操，业务数据和业务操作的描述应使用WEB服务描述语言。具体内容请参见第7章。 图 1 SOAP 消息框架 6.3 消息寻址协议 GB/T .2 4 6.3.1 概述 消息寻址规定了定位web服务地址的所需要处理的属性和操作行为。 寻址扩展元素仅适用于采用消息中间件技术实现服务调用时所遵循的规范。 6.3.2 寻址元素描述 a） 端点引用 XML元素名称：Endpo intReference 说明：用于描述对一个SOAP消息处理或者发送的

30、端点的引用信息。WEB服务寻址使用。 b） 地址 XML元素名称：Address 说明：用于标识端点的一个URI，它可以是一个网络地址或者一个逻辑地址。WEB服务寻址和消息在表示消息来源时所使用。 c） 引用特性 XML元素名称：Referen ceProperties 说明：引用属性可以包含传递的资源所需的许 多属性，这些属性可以协助把消息正确的传递到消息的端点。这些属性的解释依赖于和端点进行交互的协议邦定和数据编码。引用标识属性是用QName命名的元素信息项。WEB服务寻址使用。 d） 引用参数 XML元素名称：Referen ceParameters 说明：在端点的引用中使用参数可以协助

31、一个特定的交互。引用的参数是通过元素条目来表示的，这些元素条目的名称都是QName类型。引用参数的使用依赖选定的传输协议和参与交互的端点的数据编码。WEB服务寻址使用。 e） 接口名称 XML元素名称：InterfaceName 说明：是标识抽象的消息集和操作集的完整名称。WEB服务寻址使用。 f） 服务名称 XML元素名称：ServiceName 说明：是QName和NCName对，通过 QName和NCName对可以标识服务端点集合的完整描述。QName标识了web 服务发布的端点的集合，NCName标识了一个特定的端点。采用web服务中间件实现时该元素是可选元素；采用消息中间件方式实现时

32、消息 中服务名称代表了消息承载的服务的名称，可以指定特定的服务及队列或主题名称，在消息中必须指定。 g） 策略 XML元素名称：Policies 说明：是一个指向描述端点的行为、需求、能 力的策略集合的引用。策略定义可以协助消息的处理应用进行消息处理。WEB服务寻址使用。 h） 来源 XML元素名称：From 说明：是消息来源的节点描述。WEB服务寻址以端点引用的类型表示来源端点的属性，该元素是可选元素。 i） 目的地 XML元素名称：To 说明：是当前消息的目标接收节点的地址。该元素是必须元素。 j） 应答目的地 XML元素名称：ReplyTo GB/T .2 5 说明：一条用于标识消息应答

33、的端点引用。如 果消息希望有应答，那么该消息必须包含回复端点引用。在构建一条规范的应答消息时，发送者 应该使用要应答的消息中的应答端点引用中的内容来构建应答消息。如果应答节点中包含了策略，则策略必须是针对那个节点的完整策略。WEB服务寻址使用。 k） 出错目的地 XML元素名称：FaultTo 说明：用于标识消息相关错误的目标接收者的 端点引用。在构建一条规范的出错消息时，发送者应该使用出错属性的内容来构建规范的出错消息，如果没有出错属性，则采用回复节点中的内容构建规范的出错消息。WEB服务寻址使用。 l） 行为 XML元素名称：Action 说明：行为是一个用于唯一标识消息所需的语 义的标识

34、。通常行为节点的值是作为与抽象的服务描述构件相对应的URI。该元素是必选元素。采用web服务中间件时，服务采用关系属性的值表示消息的方向，通过消息方向可以明确行为是请求还是应答。采用消息中间件实现时Action的取值参考参照附录C。 m） 消息标识符 XML元素名称：MessageID 说明：MessageId元素用来唯一标识一条消息，其值为一个UUID值。 n） 关联消息 XML元素名称：RelatesTo 说明：是一对表达当前消息如何与其它消息关联的值。关系属性的类型使用xs:QName来表示，与哪条消息相关使用与相关消息的消息标识符属性相对应的URI来表示。 6.3.3 寻址扩展元素 a

35、） 时间戳 XML元素名称：Timestamp 说明：消息发送的时间戳，使用格式见GB/T 7408。消息使用并可以为空。 b） 优先级 XML元素名称：Priority 说明：元素Priority用来描述消息的优先级，消息系统可以根据设置的优先级来处理消息，即优先级高的先处理，优先级低的后处理，如果不 指定优先级，在消息中将作为普通级别的消息进行处理。消息优先级分为3级：High代表高优先级级别；Normal代表普通级别；Low代表低级级别。 c） 会话标识符 XML元素名称：SessionId 说明：表示消息的同一次会话的ID，在同一次会话中可以 有多个消息进行一些列的操作，如果不设置，则

36、表示此消息在一个会话中。消息使用。 6.4 可靠性协议 6.4.1 概述 可靠性协议实现了一些对于Web服务的应用至关重要的可靠消息通讯需求，它的基本目标是在应用程序产生异常、系统发生崩溃、网络出现故障时，能够实现下面的两种情况之一：如果不发生崩溃，并且故障或异常是间断出现的，需要确保发送方产生的所有消息均被传递到接收方，接收方可以将收到的所有消息的确认发送回发送方；如果故障或异常是持续出现的，或者发生崩溃，需要在异常消除、崩溃恢复、故障排除之后，确保这些情况发生之前的所有即将发送的消息，都可以被传递到接收方，接收方可以将收到的所有消息的确认发送回发送方。具体内容参考OASIS WEB服务可靠

37、性 1.1 (委员会草案 1.086)。 GB/T .2 6 协议所规定的基本目标需要采用消息确认和消息选择性重发机制来实现。可靠性协议制定了可靠性特征和消息确认的模式，以规范下述两种机制的实现的方式。 a） 消息确认机制指对于发送方发送的每一个请求消息，接收方接收到消息后，都要向发送方发送相应的响应消息，用于向发送方确认所发的消息已经到达； b） 消息选择重发机制指发送方结合系统和网络状况、以及来自接收方返回的确认消息，选择是否重新发送已经发送的消息。 6.4.2 可靠性特征 可靠性特征包括两个方面：时间特征和接收特征；其中时间特征是指消息从发送方发送到接收方，接收方接收到消息后返回给发送方

38、相应的确认消息的整个时间间隔；接收特征是指接收方需要确保向上递交其所接收到发送方发送的同一条消息的数目（由于故障存在，确认消息可能丢失，发送方对于没有收到确认的消息需要重新传递，这就存在接收方可能接收到发送方多次相同的消息），具体分为以下四种情况： c） 情况 A（至少一次递交）：发送方发送的消息，接收方至少递交一次； d） 情况 B（至多一次递交）：发送方发送的消息，接收方至多递交一次； e） 情况 C（有且仅有一次递交）：发送方发送的消息，接收方递交且仅递交一次，它是情况 A 和 B的交集； f） 情况 D（按照次序递交消息）：在情况 C（收到且仅收到一次）的基础上，收到的消息要按照 ID

39、序号递增（ID1，ID2，IDK，）的方式，在接收方排序后，再递交给所需交付的应用程序。 可靠性特征通过协议定义的XML元素及其属性来表示。时间特征用XML元素“ExpiryTime”，“groupExpiryTime”和“groupMaxIdl eDuration”来表示。接收特征用XML元素“AckReque sted”表示情况A，“DuplicateElimination”表示情况B和“MessageOrder”表示情况D，而如果同时出现XML元素“AckRequested”和“ DuplicateElimination”，就等于满足了情况C。 一个可靠消息是属于一个组的，一个组可以有一

40、个或多个消息：当一个组中只有一个消息时，属性“groupID”是全局唯一的组标识符，可以单独作为消息标识符，这个时候不需要X ML元素“SequenceNum”；当一个组中有多个消息时，消息通过“groupID”和XML元素“S equenceNum”共同定义。 一个组中的所有消息具有相同的接收特征、“groupExpiryTime”和“gro upMaxIdleDuration”。 6.4.3 消息确认的三种模式 本协议支持三种消息确认模式分为是：同步响应、异步回调和轮询三种模式，其中轮询模式又可细分为同步轮询和异步轮询两种模式。这三种消息确认模式，通过协议定义的XML元素“ReplyPat

41、tern”的子元素“Value”的元素值来表示，该元素的三种取值“Response”，“Callback”和“Poll”分别对应于同步响应、异步回调、轮询在此基础上，进一步区分是同步轮询还是异步轮询模式，则通过XML元素“PollRequest”中是否含有子XML元素“BareURI”来确定，如果没有则是同步轮询模式，含有则是异步轮询模式。 6.4.3.1 同步响应模式 在发送方发送一个消息给接收方的同一个连接上，返回接收方对该消息的确认消息。 6.4.3.2 异步回调模式 发送方新建一个连接来发送一个消息给接收方，接收方在收到消息后，再新建一个连接，返回接收方对该消息的确认消息。 6.4.3

42、.3 轮询模式 细分为同步轮询模式和异步轮询模式： a） 同步轮询模式 发送方在向接收方发送一定数目的消息后，对其发送的所有消息提出一个确认请求消息（该消息不是附带接收方应用程序所需信息的消息，只是一个用于判断先前发送的所有消息是否到达的确认请求，消息中包含所有需要确认的消息的ID值），接收方接收到这个确认请求后，轮询自己已经收到的消息，查找其GB/T .2 7 中是否有满足确认请求消息中包括的ID值的消息，并在这个确认请求消息所在的连接上，返回查询的确认结果。 b） 异步轮询模式 发送方在向接收方发送一定数目的消息后，对其发送的所有消息提出一个确认请求消息，接收方接收到这个确认请求后，轮询自

43、己已经收到的消息，查找其中是否满足有满足确认请求消息中包括的ID值的消息，新建一个连接，将查询的结果发送给发送方。 6.4.4 元素描述 元素的Schema见A.4，元素的名称及含义描述如下： a） 请求 XML元素名称：Request 说明：Soap Header的直接子元素，表示可靠消息的确认请求。 b） 消息标识符 XML元素名称：MessageId 说明：每个消息带有的唯一标识符。 属性名称：groupId 说明：组标识符，全局唯一，用于区分消息所在的组。 c） 序列号 XML元素名称：SequenceNum 说明：用于表示消息标识符的次序。 属性名称：groupExpiryTime

44、说明：组期满时间，用于一个组的生命周期管理。 属性名称：groupMaxIdleDuration 说明：组最大等待时间，表示一个组的最大空闲时间。 属性名称：number 说明：表示一个消息在组中的序号，用于消息的排序。 属性名称：last 说明：表示这是一个组的最后一条消息。 d） 消息过期时间 XML元素名称：ExpiryTime 说明：用于判断一个消息的终止时间。 e） 消息确认模式 XML元素名称：ReplyPattern 说明：用于判断消息的确认模式，其子元素“Value”的值用于表示消息确认的模式“Response”，“Callback”和“ Poll”，如果值为“Callback

45、”，则必须把XML元素“ReplyTo”必须作为它的子元素，其它模式不用添加“ ReplyTo”元素，“ReplyTo”元素中的属 性“reference-scheme”和子XML元素“BareURI”都规定了R eplyTo的子元素使用的Schema，二者不可同时出现。 f） 请求确认 XML元素名称：AckRequested 说明：指明消息的接收特征是“至少一次递交”。 g） 重复消除 XML元素名称：Duplica teElimination 说明：指明消息的接收特征是“至多一次递交”。 h） 消息次序 XML元素名称：MessageOrder GB/T .2 8 说明：指明消息的接收特

46、征是“按照次序递交”。 i） 轮询请求 XML元素名称：PollRequest 说明：Soap Header的直接子元素，表示可靠消息的轮询确认请求，如果是异步轮询，则必须把XML元素“ReplyTo”必须作为它的子元素，同步轮询则不用添加“ReplyTo”元素，“ReplyTo”元素中的属性“reference-sche me”和子XML元素“BareURI” 都规定了ReplyTo的子元素使用的Schema，二者不可同时出现。 j） 引用消息范围 XML元素名称：RefToMessageIds 说明：表示需要轮询确认的消息的序号范围。 属性名称：groupId 说明：组标识符，全局唯一，用

47、于区分消息所在的组。 k） 序列号范围 XML元素名称：Seque nceNumRange 说明：表示需要轮询确认的消息的序号范围。 属性名称：from 说明：序号范围的下限。 属性名称：to 说明：序号范围的上限。 l） 响应 XML元素名称：Response 说明：Soap Header的直接子元素，表示可靠消息的确认响应。 m） 非序列响应 XML元素名称：NonSe quenceReply 说明：对于请求中不带有XML元素“SequenceNum”的消息确认响应。 属性名称：groupId 说明：组标识符，全局唯一，用于区分消息所在的组。 属性名称：fault 说明：表示消息的“错误”类型确认响应。 n） 序列响应 XML元素名称：SequenceReplies 说明：对于请求不带有XML元素“SequenceNum”的消息确认响应。 属性名称：groupId 说明：组标识符，全局唯一，用于区分消息所在的组。 o） 应答范围 XML元素名称：ReplyRange 说明：需要提供确认响应的消息范围。 属性名称：from 说明：序号范围的下限。 属性名称：to 说明：序号范围的上限。 属性名称：fault 说明：表示消息的“错误”类型确认响应。 6.5 安全性协议 GB/T .2 9 6.