中国移动网状网系统接口规范SOAP模块v203汇编.docx

中国移动网状网系统接口规范SOAP模块v203汇编.docx

《中国移动网状网系统接口规范SOAP模块v203汇编.docx》由会员分享，可在线阅读，更多相关《中国移动网状网系统接口规范SOAP模块v203汇编.docx（77页珍藏版）》请在冰豆网上搜索。

中国移动网状网系统接口规范SOAP模块v203汇编

中国移动通信企业标准

QB-J-XXX-2010

中国移动网状网规范总册

版本号：

2.0.3

文档变更记录

序号

变更内容说明

版本号

版本日期

执笔人

1

添加5.3.1.3消息头中MsgSender和MsgReceiver说明

7.1.10细化说明了加解密和SoapFault及业务失败时处理的问题

1.0.4

2013-8-29

王伟

2

细化5.4.1机构状态检测的规定和说明

1.0.5

2013-9-13

王伟

3

更新5.6.1.4管理类交易中密钥更新请求部分

1.0.6

2013-9-23

王伟

4

修正5.6.1.4管理类交易中密钥更新请求部分

1.0.7

2013-9-23

王伟

5

更新2.0版本，对应报文头version字段为0200的所有报文请求。

2.x版本和1.x版本的变更内容列表请参见5.4章节的接口规范变更。

2.0.0

2014-4-14

王伟

6

1.增加5.1对外接口；

2.原“接口规范变更”更名为“5.5.2.x版本与1.x版本差异”；

3.“接口描述”增加“同步模式和异步模式接口差异”，同时分为“交易模式”和“交易流程”；

4.调整“接口描述”下面的章节顺序；

5.“接口描述”增加“SOAPfault结构”、“系统错误报文样例”和“业务错误报文样例”；

6.增加“SOAP错误编码”；

7.去掉重复的“SN-S模块”内容。

2.0.1

2014-6-10

王伟

孙慧云

7

修正5.6.4“SOAPFault”的结构，使用Subcode以符合W3C规范标准。

2.0.2

2014-10-27

王伟

8

更新5.8.3部分节点加密的样例，更加清晰的反应了加密的部分；补充说明部分节点加密中，默认使用节点值加密方式。

2.0.3

2014-12-22

王伟

9

10

11

前言

本规范由中国移动通信有限公司业务支撑系统部提出并归口。

本规范起草单位：

中国移动通信有限公司业务支撑系统部。

本规范解释单位：

中国移动通信有限公司业务支撑系统部。

1.

适用范围

《中国移动通信网状网规范总册》（以下简称“总册”）描述了中国移动网状网系统（以下简称网状网）的体系结构、应用软件结构、系统边界和外部接口、系统功能等。

本规范是中国移动网状网系统一期目标规划和建设的基本依据；本规范适用于指导中国移动一级业务系统、各省（直辖市、自治区）移动公司（以下简称“省公司”）、各全网业务管理平台接入网状网系统的建设。

原有的《中国移动有限公司一级BOSS接口规范_总体架构和系统管理分册v1.4.5》将由本规范取代。

网状网规范适用于所有的省BOSS间业务和与省BOSS相关的全网数据业务。

2.引用标准

本规范引用如下标准以及中国移动通信制定的规范。

T模块引用标准：

[1]W3CHTTP1.1：

http:

//www.w3.org/Protocols/

D模块引用标准：

[1]省级业务运营支撑系统（BOSS）业务技术规范欠费风险控制分册（3.0版）

[2]IETFRFC3588－DiameterBasedProtocol

[3]IETFRFC4006－DiameterCredit-ControlApplication

[4]3GPPTS32.299Telecommunicationmanagement;Chargingmanagement;Diameterchargingapplications

S模块引用标准：

[1]W3CSOAP1.2：

http:

//www.w3.org/TR/SOAP/

3.

总体说明

中国移动网状网系统是基于计算机应用技术、用以支持中国移动全网数据业务运营的信息系统。

网状网负责连接总部系统、31个省BOSS系统和全网全网业务平台，实现BOSS与BOSS，BOSS与全网全网业务平台、全网全网业务平台与全网全网业务平台之间的交易通信、数据同步。

目标

中国移动网状网系统的建设目标是构建一个信息资源充分共享的一体化业务数据传输网络，通过传输基础层实现全网业务的承载，通过业务层实现全网产品的陈设、订购、开通、结算、业务的统一管理及流程支持，为未来的全网一体化运营支撑能力打下基础：

1.建设网状结构的业务交换网络，实现中国移动省级业务支撑系统、总部业务系统和全网业务平台间的互联互通。

2.建设统一的管理中心（MC），实现全网路由管理、数据发布、系统和业务监控等功能。

3.建设一级业务管理中心（BMC），实现业务数据采集、产品管理、业务的横向及纵向调度及业务结算支撑。

4.重构HTTP模块，实现基于HTTP+XML格式的联机交易。

包含系统大圈类交易，业务大圈类交易和通知类交易。

5.新建DCC模块，支撑实时计费类的DCC协议。

建设全业务的欠费控制网络。

6.重构FTP模块，实现文件类业务的FTP传输。

提高整个文件传输的安全性，时效性和管控。

7.新建SOAP模块，实现对SOAP协议的支撑。

方便接入实现SOAP协议的机构的交易。

编写原则

本次网状网规范总册的编写原则如下：

1、本规范明确中国移动全国网状网系统总体建设要求。

2、本规范就网状网系统体系架构、系统结构、系统边界等予以定位。

3、本规范不包含具体业务接口。

4、本规范描述网状网系统各模块的功能、运作流程、管理方式，不涉及网状网系统本身的技术实现。

3.1.设计原则

网状网系统的主要设计原则：

−业务与传输的分离：

通过分层设计降低系统复杂性和提高系统适应性是一个通用的设计原则。

网状网由接入层、传输服务层和业务管理层构成，接入层是网络层，传输服务层负责接口的数据交换和相关配置管理工作，业务管理层负责业务数据采集、业务调度、结算，报表等业务管理功能（由BMC模块实现）。

原有的一级BOSS枢纽系统功能高度集成在交换中心，只支持HTTP协议，没有清晰的层次概念，从整体框架上无法支撑多协议传输和未来的业务需求（例如全网产品管理、业务流程调度等）。

网状网分离业务和传输，使业务和传输的关系由紧耦合变为松耦合，可以任意调整各个层次的功能而不互相影响，弹性强，适应性好，大大地提升了整体支撑能力，即满足现有业务需求，也为未来打下基础；

−传输与控制的分离：

原有的一级BOSS枢纽系统是星形拓扑结构，传输服务和传输的控制管理是一体的，紧凑高效。

网状网为了消除交换中心一点故障即全网瘫痪的缺陷，提高整体稳定性和传输效率，将星形结构改为网状结构，变集中交换为分散交换，将原有的交换功能从交换枢纽分散到各交换节点，架构的改变必然导致系统管理模式的改变。

因此网状网将传输与传输控制分离。

传输服务层由传输子层和控制子层构成，传输子层由管理模块（M模块）和各协议交换模块（T、D、F、S）组成。

控制子层由MC模块构成，MC模块负责传输子层各协议模块的状态管控、配置数据发布，传输子层M模块上传协议模块的状态信息，接受控制子层发布的命令，实时变更配置数据。

此种设计不但轻便灵活，既满足分层设计的原则，又提高了各协议模块的吞吐能力；

−标准化:

使用基于标准构件和流程以简化IT资产的使用方式；

−模块化：

利用分布式技术将简单的模块组合，实现复杂的系统功能；

−集成化：

通过一致的系统间集成来方便地管理和修改环境；

另外，系统的设计还遵循以下原则：

−先进性

选用先进的应用系统架构模型，以及先进的硬、软件平台，以保证系统的先进性。

−可扩展性

系统架构支持未来系统的扩展需求，支持新业务快速上线。

−系统的安全性

采取数据保密和安全措施，进行权限与加密管理，以保证系统和数据的安全。

3.2.规范体系

网状网规范体系包括网状网规范总册、业务用词词典、网状网省间业务接口规范分册、网状网全网数据业务接口规范分册。

共同为网状网的建设提供统一的规范和标准。

网状网规范总册从总体上阐述了网状网的逻辑结构、技术架构、功能、基础概念、关键流程，所有接入网状网的机构必须遵循总册的要求方能达到接入的目的。

网状网规范总册最终将替代原有的《中国移动有限公司一级BOSS接口规范_总体架构和系统管理分册v1.4.5》。

网状网业务规范单行本针对特定业务，详细说明相关业务场景、系统接口、接入要求，直接指导业务关联系统间的对接建设。

今后按照网状网总册的接入要求修改原有的一级BOSS枢纽业务单行本。

4.

网状网系统总体架构

网状网从总体上分为3个层次，基础网络层（IP承载网）、传输服务层、业务管理层。

4.1.网状网逻辑架构

图表41网状网逻辑架构

整个系统逻辑上分为两层：

业务管理层和传输服务层。

通过这两层的划分，实现了传输与业务的分离。

另外传输服务层内部又分成两个子层：

控制子层和传输子层。

实现了传输和控制的分离。

SN在实现上包括管理模块（M）和T、D、F、S部分。

协议模块是核心部分。

4.2.接入基础层描述

图表42接入基础层

如上图所示，基础网络层使用IP承载网，实现各省接入网络设备的互联互通，各服务节点SN接入到本地的接入网络设备连接至IP承载网中，实现各省节点的可连通性。

IP承载网采用双平面设计，任何2个节点之间有多个冗余路由，实现网路的接入安全。

4.3.业务管理层

4.3.1.BMC（BusinessManagementCenter）

业务管理中心。

物理上部署在总部。

作为网状网的管理中心，业务管理平台负责产品管理、业务的跨省（平台）调度、平台日终处理、业务对账、结算管理等。

并且对未来的全网一体化运营提供技术支撑。

业务管理层与传输服务层通过各种协议交互。

4.4.传输服务层

在传输服务层（TSN）通过对管理中心（MC）子层与传输子层（SN）的划分，实现了传输与控制的分离，管理中心与传输子层通过各种协议交互。

如下图所示，传输服务层由各省（总部）的交换节点SN和管理中心MC组成。

各省服务节点面向各省业务系统，实现业务的接入及业务传输，总部服务节点面向总部的业务平台，实现总部业务平台的接入以及业务的传输。

整个传输服务层基于底层IP承载网提供可靠的点对点传输服务，具备路由选择、流量控制、压缩加密、鉴权管理、业务传输、数据采集等功能。

管理中心完成TSN的管理控制功能，包括路由管理、局数据管理、数据采集、数据发布、作业调度、服务管理、SLA管理等。

图表43传输服务层

4.4.1.控制子层MC（ManagementCenter）

管理中心。

物理上部署在总部。

作为一个系统的中枢，负责整个系统的配置管理，规则定义，系统和业务监控，对外系统接口，和任务分派等。

逻辑上只有一个MC，可以通过在南北中心各建一个达到容灾的能力。

4.4.2.传输子层

4.4.2.1.M（Management）模块

管理模块。

物理上该模块部署在交换节点SN上。

每一个SN部署一个M模块。

作为MC定义规则的执行者，MC下发配置，规则数据和相应的指令。

M模块负责协调自己管辖的T，F，D，S模块按照规则来进行交易。

4.4.2.2.T（Transaction）模块

HTTP交易管理模块。

物理上部署在SN节点，可以有一个或多个点，而且能够实现平滑的水平扩展。

主要负责实时报文交易的传输。

包含大圈和通知等交易类型。

具有交易路由，完整性校验，消息可靠性传输，加解密，报文格式校验，交易冲正等功能。

4.4.2.3.F（File）模块

文件传输的管理模块。

物理上部署在SN节点，可以有一个或者多个，能够实现平滑扩展。

主要负责文件类业务的传输。

包含文件路由，压缩，加解密，完整性校验等功能。

4.4.2.4.D（DCC）模块

DCC协议管理模块。

物理上部署在SN节点，可以有一个或者多个，可以平滑扩展。

主要负责DCC协议交易的路由，报文校验和转发功能。

4.4.2.5.S（SOAP）模块

SOAP协议管理模块。

物理上部署在SN节点，可以有一个或者多个，可以平滑扩展。

主要负责SOAP协议交易的路由，加解密，报文校验和转发功能。

5.

SN－S模块

5.1.对外接口

S模块主要和发起方机构（省BOSS或全网业务平台），M模块，MC模块有接口，如下图所示：

图表51S模块对外接口示意图

5.2.适用范围

随着SOA和WebService标准的推广，SOAP协议越来越成为一种数据业务平台对外的标准协议，考虑到未来枢纽支撑协议的多样性，网状网本次新部署了一个SOAP模块，专门处理SOAP协议的转发。

图表52SOAP模块示意图

S模块为网状网支持SOAP协议的模块，是网状网系统的关键模块之一，负责所有基于SOAP的交易的管控。

它继承并拓展了T模块的联机交易功能，适用于基于SOAP协议的服务的接入和服务的提供。

5.3.基础概念

5.3.1.交易参与方

5.3.1.1.SN（ServiceNode）节点

每个省的SN都部署一个SOAP模块，作为SOAP协议的中继。

负责机构间交易报文的转发，并且进行报文格式转换、校验、加解密、传输控制、交易冲正和必要的协议转换工作。

机构在接入网状网时需要明确自己要接入的交换节点，在整个交换系统内每个交换节点具有自己的唯一标识（称为DUNS）。

5.3.1.2.机构（SP（ServieProvider））

真正的服务提供方，每个机构都有自己唯一的ID，作为路由标识，同时机构接入网状网必须要实现心跳，签到/签退，加解密等管理接口。

5.3.1.3.SC（ServiceConsumer）

服务使用者是调用服务的一方。

调用方也都有自己的唯一ID，作为路由标识，同时作为身份的鉴别标志。

5.3.2.服务编码规则

为了更好的管理服务，每个服务都要遵循一定的编码规则：

服务编码组成格式为：

SVC_【DOMAIN】【DUNS】_【FUNCTION】

包含四个部分：

1、固定头“SVC”表示服务（Service）；

2、4位【DOMAIN】表示SP的域编码，比如BOSS标识省BOSS,MUSC标识音乐基地；

3、4位【DUNS】表示SN的编码，比如2800标识四川省SN；

3、4位【FUNCTION】表示业务功能,比如鉴权用AUTH；

例如，四川音乐平台的鉴权服务的编码为：

SVC_MUSC2800_AUTH

5.3.3.服务描述文件WSDL文件的取得

服务注册之后，服务调用方可以通过以下的方式取得WSDL文件，查看服务，或者调用服务，

调用服务地址为:

http:

//sn的s模块IP地址:

端口/services/服务编码

形如:

http:

//localhost:

8080/SoapServices/services/Math

查看wsdl链接为：

http:

//sn的s模块IP地址:

端口/services/服务编码?

wsdl

形如:

http:

//localhost:

8080/SoapServices/services/Math?

wsdl

5.3.4.交易模式

5.3.4.1.模式说明

按照不同的交易模式，SOAP的交易可以分为三种。

同步模式（IN-OUT）：

服务调用方必须要等到服务提供方返回响应消息才认为服务调用完成。

否则认为超时。

该模式类似于T模块的大圈类交易。

异步模式（IN-ONLY）:

服务调用方只管发送请求，不需要服务提供方的返回。

该模式类似T模块的通知类交易。

订购-发布模式（SUB-PUB）:

服务调用方注册服务，服务有结果时进行广播。

类似于T模块的中心落地大圈。

5.3.4.2.同步模式和异步模式接口差异

同步模式和异步模式的发起请求报文规则完全相同；但是对于发起请求报文后收到的应答报文，这两种模式不相同，差异如下：

对于同步模式，发起一个请求报文后，会一直等到收到应答报文，此应答报文详见5.4章节的接口协议中应答报文说明。

对于异步模式，发起一个请求报文后，会立即收到网状网系统返回的应答报文。

应答报文分两种：

1.正常应答报文：

网状网收到请求报文后，存储报文并立即返回应答报文，网状网后续将该请求转发给落地方。

应答报文样例参见5.6.6正常应答报文样例中“2.异步模式交易应答报文样例”。

2.异常应答报文：

请求报文格式错误或其他类型错误（例如：

无权限、路由不正确、落地方已经注销等错误）时，网状网系统会立即返回给发起方一个应答报文，该应答报文的SoapBody中只包含SoapFault节点，SoapFault节点中描述了错误的原因和详细信息。

网状网系统依然会尝试存储该异常请求报文但不会转发此报文。

应答报文样例参见5.6.7系统错误报文样例。

5.3.5.交易流程

5.3.5.1.同步模式

5.3.5.1.1.适用范围

各种和用户体验相关的业务场景，具有小数据量、低时延等特点。

5.3.5.1.2.流程

系统类大圈指的是发起方与OSN以及落地方与HSN间采用同步类通信机制（采用连接堵塞等待应答消息、SN负责超时控制），OSN与HSN之间以异步通信实现业务的交易模式。

系统大圈的正常流程如下：

图表52系统类大圈流程示意图

本类交易可以冲正。

在传递本类交易的请求时，OSN必须进行超时控制（超时时限在交易属性中描述）。

若OSN发现一笔系统大圈类交易超时（HSN不参与交易控制，只负责转发），则向上游节点返回交易超时失败（OSN已发起冲正，若需要冲正）的应答，同时向下游节点发起冲正（若需要冲正的话）；若发起端机构发现一笔本类交易超时（若需要冲正的话），则向OSN发送冲正请求。

以下各图为处理过程中的异常流程，分别是：

1、发起方机构向OSN发送交易请求失败：

向用户发送受理失败信息。

2、OSN发现发起方机构发送的交易请求有错：

告知发起方机构出错信息，发起方机构向用户发送受理失败信息。

3、OSN向落地方机构转发请求信息失败：

告知发起方机构出错信息，由发起方机构向用户发送受理失败信息。

4、OSN等待落地方机构应答超时：

告知发起方机构出错信息，发起方机构告知用户受理失败信息；如果此交易具有“需要冲正”属性，则OSN向落地方机构发送冲正业务，直到收到落地方机构的确认应答为止；落地方机构在收到冲正请求后给予OSN以确认应答并回退已完成的交易。

此时如果OSN在向业务平台发送完出错信息后又收到了落地方的迟到应答，则丢弃。

5、发起方机构等待OSN的应答超时：

发起方机构向用户发送受理失败信息；如果此交易具有“需要冲正”属性，则发起方机构向OSN发送冲正请求，直到收到OSN的确认应答为止；OSN在收到冲正业务请求后，给与发起方机构确认应答，并向HSN转发冲正请求，直到收到HSN确认应答为止；HSN转发冲正请求，直到收到落地方机构确认应答为止；落地方机构在收到冲正请求后给予HSN以确认应答并回退已完成的需要被冲正的交易；如果发起方机构在产生冲正请求后又收到了OSN的迟到应答，则丢弃。

经发起方机构受理的业务异常流程1：

发起方机构向OSN发送交易请求信息失败

经发起方机构受理的业务异常流程2：

发起方机构向一级BOSS枢纽发送的消息有错

经发起方机构受理的业务异常流程3：

OSN向落地方机构转发信息失败

经发起方机构受理的业务异常流程4：

OSN等待落地方机构应答超时

经发起方机构受理的业务异常流程5：

发起方机构等待OSN应答超时

5.3.5.2.异步模式

由于参与交易各方之间为广域网联接，而且各参与方系统是独立管理，交易是否可以正常送达有一定的不可预见性。

为了保证请求消息能够到达，我们采用存储转发方式。

存储转发是指当下游节点不可及或者未正常应答时，上游节点将消息报文存储起来，定时发送，直到下游节点返回确认应答的机制。

因此，作为上游节点的发起方机构或SN都要实现存储转发功能。

存储转发类流程包括通知和冲正流程两类。

发起方机构和发起方SN都会向下游节点发起通知或冲正交易，具体流程参见流程图。

SN收到发起方的通知或冲正请求后，将标记当前逻辑交易日。

在逻辑交易日日切之后，SN将不再发送前一逻辑交易日的存储转发交易，对于未能转发的交易，可以通过对帐和核对流水等机制保证各参与方的一致性。

对于冲正交易，要求不能冲前一逻辑交易日的交易。

图表55通知类交易流程图

1）机构发起交易请求，OSN得到请求后进行格式校验。

然后立即返回响应。

机构认为交易发送完毕。

2）OSN得到请求后，首先得到路由信息后，立即转发。

如果发送成功，则在内存中保留log记录和报文体记录。

如果转发不成功，则先将交易报文头保存到数据库，报文体保存到文件中，然后等待重发程序进行重发。

如果重发依然不成功，则将下次重发时间增加，等待继续重发。

如果多次发送不成功，则置为失败（每个交易的重发次数不一定）。

3）HSN得到请求后，也是得到路由信息后，立即转发。

如果发送成功，则在内存中保留log记录和报文体记录。

如果转发不成功，则先将交易报文头保存到数据库，报文体保存到文件中，然后等待重发程序进行重发。

如果重发依然不成功，则将下次重发时间增加，等待继续重发。

如果多次发送不成功，则置为失败（每个交易的重发次数不一定）。

4）落地方得到交易请求后，解析报文体，进行业务处理。

不用返回业务响应。

5.3.6.SOAP错误（SOAPFault）

SOAPFault是SOAP标准的错误信息节点，是位于SOAPBody的根节点的可选子节点。

在网状网S模块中，SOAPFault节点用于描述交易处理的错误信息，主要两类异常：

报文传输失败时的异常信息（系统错误）和落地方业务处理失败时的异常信息（业务错误）。

系统错误：

SN节点或者落地方节点应按照下面的SOAPFault规范组织SOAPFault节点返回给发起方。

此时返回报文的SOAPBody应当只有SOAPFault这一个子节点。

业务错误：

SN节点或落地方节点也应该组织SOAPFault返回给发起方。

此时返回报文的SOAPBody除了包含必需的SOAPFault节点外，还可以（非强制）根据业务需求选择是否包含响应子节点，如果包含响应子节点则此时业务响应子节点和SOAPFault节点都是SOAPBody节点的子节点。

网状网S模块的SOAPFault错误编码规则采用SOAP1.2的编码规则，错误代码为命名空间http:

//cmcc.trans下的5位数字组成，第一位数字以1或者2开头：

1开头的为系统错误代码，2开头的为业务失败错误代码，详细参见6.1.9SOAP错误编码。

注意：

对于加密业务，SOAPFault节点本身不应做任何加密处理，而其余节点可按照业务需求选择加密或者不加密。

5.4.接口协议

S模块遵循SOAP1.2的规范，具体见http:

//www.w3.org/TR/soap12/。

WSDL遵循WSDL2.0规范，具体见http:

//www.w3.org/TR/wsdl20/。

5.5.2.x版本与1.x版本差异

SOAP模块接口规范2.0版本相比于1.x版本有较大的变化。

相关信息如下：

5.5.1.1.变更原因

随着业务的发展，沿用网状网Trans模块的SOAP模块1.x的规范无法满足新增业务的要求（例如多加密，统一错误代码等），同时为了更好的对业务报文规范化并使之更符合SOAP规范，故更新SOAP模块2.0规范。

5.5.1.2.变更内容说明

SOAP模块2.