YDT 2145-2010 基于Web Service技术的网络管理接口定义指南

1、I C S 3 3 . 0 4 0 . 0 1 M 1 1 I i 中华人民共和国通信行业标准 丫D 汀 21 4 5 - 2 01 0 基于We b S e r v ic e 技术的 网络管理接口定义指南 G u id a n c e f o r d e f i n in g We b s e r v ic e t e c h n o lo g y - b a s e d n e t w o r k m a n a g e m e n t i n t e r f a c e 2 0 1 0 - 1 2 - 2 9 发布 中华人 民共 和 国工业 和信 息化 部 2 0 1 1 - 0 1 -

2、 0 1 实施 发 布 Y D / T 2 1 4 5 - 2 0 1 0 目次 前言 11 I 范围 1 2 规范性引用文件 1 3 缩略语 1 4 基于We b s e r v i c e 技术的网络管理接口位置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I 5 基于We b s e r v i c e 技术的网络管理接口的层次结构 . . . . .

3、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 6 基本技术要求 . . . . . 2 7 信息模型层技术要求 。 。 。 。 。 。 。 一 3 8 ME P 层技术要求 3 9 传输层的技术要求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1 0 安全要求 7 附录 A （ 资料性附录） 使用 J MS作为传输协议的技术要求 8 附录 B（ 资料性附录） 使用 R E S T技术实现网络管理接口 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0 参考文献 ， 一

5、 1 1 YD汀 21 4 5 - 2 0 1 0 月 li舀 本标准在编制过程中，主要参考了国际电 信联盟一 电 信标准部（ I T U - T ）标准M.3 0 1 0 、电信管理论坛 ( T M F ） 标准T M F 8 5 4 、 高级信息化结构标准组织 （ O A S I S ） 标准WS 系列标准， 并结合我国的具体情况编 制而成。 其中，对相关主要标准的引用或参考情况如下： I T U - T M . 3 0 1 0 ：本标准参考了该标准关于T M N功能架构中 参考点的定义内 容。 T MF 8 5 4 ： 参考了该标准使用We b s e r v i c e 技术作为网 络

6、管理接口的 基本技术框架、 交互模式和 定义方法等内容。 - O A S I S WS 系列标准：本标准参考了 该系列标准中关于 We b s e r v i c e 通知、安全、迭代、可靠传 输等方面的内容。 本标准与上述国际规范间的关系为非等效。 本标准的附录A 和附录B 为资料性附录。 本标准由中国通信标准化协会提出并归口。 本标准起草单位：华为技术有限公司、中国移动通信集团公司。 本标准主要起草人：张天虎、李晖。 w w w . b z f x w . c o m YD厅 2 1 4 5 - 2 0 1 0 基于We b s e r v ic e 技术的网络管理接口定义指南 范围 本标

7、准规定了基于We b s e r v i c e 技术的网络管理接口的通用技术要求。 本标准适用于基于We b s e r v c i e 技术的网络管理接口，也适用于采用该技术实现的其他管理接口。 2 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的 修改单 （ 不包括勘误的内容）或修订版均不适用于本标准。然而，鼓励根据本标准达成协议的各方研究 是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。 I T U - T M. 3 0 1 0 电 信网络管理基本原则 3 缩略语 下列缩略语适用于本标准。 H T T

8、P H y p e r T e x t T r a n s f e r P r o t o c o l I T U- T T e l e c o mmu n i c a t i o n S t a n d a r d i z a t i o n S e c t o r o f I n t e r n a t i o n a l T e l e c o mmu n i c a t i o n Un i o n J MS J a v a Me s s a g e s e r v i c e ME P Me s s a g e e x c h a n g e P a t t e r n MT O S

9、 I Mu lt i - T e c h n o l o g y O p e r a ti o n s S y s t e m I n t e r f a c e R E S T R e p r e s e n t a t i o n a l S t a t e T r a n s f e r S O A P S i m p l e O b j e c t A c c e s s P r o t o c o l S S L S e c u r e S o c k e ts L a y e r T MF T e l e Ma n a g e m e n t F o r u m T MN T e

10、l e c o m m u n i c a t i o n s Ma n a g e m e n t N e t w o r k X ML e X t e n s i b l e Ma r k u p L a n g u a g e 4 基干We b s e r v ic e 技术的网络管理接口位置 超文本传输协议 国际电信联盟电信标准化部 J a v a 消息服务 消息交互模式 多技术操作系统接口 具象状态传输 简单对象访问协议 安全套接层 国际电信管理论坛 电信管理网 可扩展的标记语言 本标准所定义的 基于We b s e r v ic e 技术的网络管理接口 适用于I T U - T M

11、.3 0 1 0 定义的 下图中 X , Q 和F 接 w w w . b z f x w . c o m YD汀 21 4 5 -2 01 0 ” 一1 爹 sw QA 图1 基于 We b s e r v i c e技术的网络管理接口适用位置 5 基于We b s e r v ic e 技术的网络管理接口的层次结构 基于We b s e r v i c e 技术的网管接口概念上可分为3 层，如图2 所示。 1 )应用传输层为通信双方提供了通信手段，使数据能够可靠、安全的被传输； 2 )消息交换模式 （ IT S ）层描述通信双方采用S O A P 消息进行通信的交互方式； 3 ) 信息模型

12、层抽象和描述了被管对象。 其内容依赖于特定的业务和对象， 本标准了描述这些业务和 对象的公共技术要求。 信息模型层 消息交互模式 （ ME P )层 应用传输层 HTr P / ATr P S / J MS / - - - 图2 基于 We b s e r v i c e技术的网络管理接口层次结构 6 基本技术要求 基于We b s e r v i c e 技术的网络管理接口必须满足如下基本条件： 1 )传输层需要制支持如下两种通信模式之一： a ）同步调用模式； b )异步交互模式； w w w . b z f x w . c o m 丫D汀 21 4 5 - 2 0 1 0 如果选择使用同

13、步调用模式，建议优先使用H T T P 或H T T P S 协议作为传输协议；如果选择使用异步 交互模式，建议使用J MS 或其他消息中间件来作为传输协议； 2 ) ME P 层至少支持简单的R e q u e s t - R e s p o n s e 模式 （ 包括o n e - w a y 模式） 和定购通知模式； 3 )信息模型层所定义业务和对象模型必须能够通过X ML S C H E MA 来描述或者能够转换成X ML S C H E M A 的语言来描述； 4 ) ME P 层与传输层之间要松祸合， 确保在不影响具体业务的 前提下可以 使用不同的 传输层。 7 信息模型层技术要求

14、 信息模型层必须满足如下要求： 1 ） 信息 模型 描 述语言 必 须 遵守 W e b S e r v i c e D e s c r i p t i o n L a n g u a g e v e r s i o n 1 . 1 ( WS D L ） 规 范 和 W S - I B a s i c P r o f i l e 1 .2 规范； 2 ） 用于 传送 X M L 数 据的 消 息 格式 定 义必 须 遵守 S im p l e O b j e c t A c c e s s P r o t o c o l v e r s i o n 1 . 1 / 1 .2 ( S O A P

15、 ) 规范； 3 ） 被传送的 X M L 数据必须使用X M L S c h e m a 进行描述， 并遵从 X M L S c h e m a v e r s i o n 1 .0 ( X S D ） 规范； 4 ）信息模型中的命名空间必须遵守U R I 定义的标注格式； 5 ）采用WS D L 定义的信息模型可以采用如下的模块化的方式： a ） 消息模块采用 S e r v i c e l n t e r f a c e M e s s a g e s .w s d l 命名方式； b ) p o r tT y p e 模块采用 S e r v i c e ln t e r f a c

16、e P o r tT y p e . w s d l 命名方式； c ）服务模块采用 S e r v i c e ln t e r f a c e H T T P . w s d l 或 S e r v i c e l n t e r f a c e J MS . w s d l 命名方式； 6 ）在使用X ML S c h e ma 描述信息模型时，建议尽量不使用X ML S c h e m a 的高级特性，比如复杂类型 中的a l l , u n i o n 等类型； 7 )对于X ML S c h e m a 的版本管理，如果一个X ML S c h e m a 定义的类型或实体的属性被

17、废弃或变更了 就应该更新主版本号，如果是增加了新的属性，就应该更新辅版本号； 8 ）版本信息要求能够在WS D L 文件中体现，推荐使用如下方式： ws d l : d e f i n i t i o n s n a me” 将版本号做为命名空间中的一部分； 9 ）版本的信息分成主版本号和辅版本号两个部分； 1 0）当用X ML S c h e m a 描述服务请求消息 响应消息时，请求消息的命名方式必须是 R e q u e s t ，应答消息的 命名方式必须是 o p e r a ti o n N a m e R e s p o n s e ， 异常的命名方式必须 是 o p e r a

18、ti o n N a m e E x c e p t i o n ; 1 1 )如果一个服务请求需要传递多个in 参数，必须将这些in 参数包装成一个复杂类型的参数来传递； 如果一个参数可选， 需要使用m i n O c c u r s = O 属性来标定； 1 2 ）如果一个操作可能抛出多个异常，则需要使用复杂类型中的c h o i c e 子项来描述。 8 ME P层技术要求 使用基于We b s e r v i c e 技术的网络管理接口需要支持以下四种消息交互模式 （ ME P )： 1 ) 简单请求响应模式 （ 包括o n e - w a y 模式）： 一次请求对应一次响应或者没有响

19、 应； 2 )一次请求多个响应模式：一次请求对应一次或是多次响应，主要是用于处理大数据量的交互； w w w . b z f x w . c o m Y D 厅 2 1 4 5 - 2 0 1 0 3 ） 文件批响应模式： 一次请求后， 响应信息被以文件的方式存放在指定的地方， 由请求方自己获取， 这种方式主要用于处理超大数据交互； 4 ）定购通知模式。 表1 给出了两种通信模式和四种ME P 交互模式组合所产生的具体化的交互场景。 表1 两种通信样式和四种通信模型相互组合形成的 种交互场景 M EP 通信样式 简单响应一次请求多次响应文件批响应定购通知 同步调用模式同步请求 响应同步迭代 同

20、步文件批响应 异步交互模式异步请求 响应 异步批量响应异步文件批响应异步通知 8 . 1 .1 简单响应模式 简单响应模式是最常用的消息交互模式，呈现为一次请求对应一次响应或无响应。同步调用和异步 交互唯一的区别是异步交互需要一种匹配机制来关联请求消息和响应消息。 8 . 1 .2 多次批响应模式 这种模式一般适用于大数据量的查询操作，查询出的最终结果不能通过一次简单的响应返回给请求 方。响应方需要提供如下机制用于帮助请求方获取后续的查询结果： 1 )同步迭代机制： 第一次请求的响应除了返回一部分响应数据外， 还返回一个迭代服务引用， 请求 方可以利用这个迭代服务引用获取后续的响应数据。请求方

21、负责控制整个调用流程，而响应方负责维护 这个迭代服务引用和相关的中间状态。响应方必须提供迭代子服务引用的自 动回收机制，用于释放相关 资源。具体交互过程如图3 所示。 请求方响应方 发送请求 IM - 了 迭 代 服 务 首批响应结果迭代服务引用 请求后续结果 终止请求后续的响应 图3 同步迭代过程 2 ） 异步批响应机制： 第一次请求的响应仅仅是一个通知信息， 通知请求方已经接受了这个请求并正 在处理，随后响应方将处理的结果分批次推送给请求方。 请求 方要 在 第一 次 请求的 消息中 提供自 己 接受 响 应结 果的 回 调 端口 。 请 求方 可以 使 用 W s - A d d r e

22、 s s i n g 的标准方式将这个回调端口发布给响应方，也可以直接将底层消息服务的消息队列标识 （ 如J MS 的消息 接受队列的名字）发布给响应方。详细交互过程如图4 所示。 w w w . b z f x w . c o m Y D 厅 2 1 4 5 - 2 0 1 0 请求方响应方 响应接收 服务 发送请求后续结果接受服务引用 响应O K 发送后续结果 发送后续结果 发送后续结果 图4 异步批响应过程 8 . 1 .3 文件批响应模式 针对超大数据量的交互，响应方将响应消息以文件方式存储在指定的存储位置，然后通知请求方来 提取结果文件；请求方在请求消息中要携带存储服务的U R L（

23、 遵从R F C 3 9 8 6 ， 格式应该是 s c h e m e :/ / u s e rn a m e :p a s s w o r d h o s t / w o r k d ir e c t o r y / f i l e N a n e .x m l ） 信息， 这个 信息 将被响 应 方用于 标 定结 果 文件存放的位置， 文件的传输和提取可以使用F T P / S F T P 或是其他协议；除此之外， 请求方还应提供结果 文件是否打包、打包的类型 （ Z I P / T A R )、是否压缩 （ G Z I P ）等信息用于指定结果文件格式。响应方需 要提供如下机制帮助请求

24、方获取最终的结果文件： 1 ) 同步调用机制：请求方在发送请求后进入等待状态，响应方在文件被正确无误的生成并存储到 指定位置后，向请求方发送通知；请求方在收到通知后自 行获取结果文件。具体交互过程如图5 所示。 请求方响应方 存储 服务器 发送请求 将结果存放到存储服务器上 发送响应 获取结果文件 图5 同 步文件批响应 2 ) 异步交互机制：请求方提供接收状态通知的回调服务。 在处理的整个过程中，响应方将定时通过 这通知服务发送通知消息给请求方，告知操作正在进行中，并提供响应的进度信息，直到文件被正确无 误的生成并存储到指定的存储器上后，才发送完成消息给请求方，通知其可以去取结果文件。具体交

25、互 过程如图6 所示。 w w w . b z f x w . c o m 丫D厅 2 1 4 5 - 2 0 1 0 请求方响应 方 存储 服务器 通 知 服 务、 刁-111 1 发送请求 状态信息 状态信息 发送结束响应 将结果存放到存储服务器 上 获取结果文件 图 6 异步文件批响 应 8 . 1 .4 定购通知模式 定购通知模式遵从Ws - N o t i f i c a t i o n 标准，它制定了在 We b s e r v i c e 环境中创建事件驱动系统的 标准流 程。响应方首先发布自己的主题，主题的类型由具体的业务来定义，每个主题都跟特定的事件绑定。请 求方向响应方订购

26、希望的主题，当和这个主题相关的事件发生时，响应方就要通知请求方。 通知消息也是由业务指定的，并且根据主题来进行分类，通知消息的订阅者根据主题来选择其想订 阅的消息。通知消息要包含可以被通知过滤系统识别的信息，可以被过滤系统用于实现通知过滤机制。 过滤器包括两个部分的信息： 1 ) 查询方言，用于指定查询表达式的 类型，如 X P A T H / X Q U E R Y 或是 J M S 过滤器； 2 ）查询表达式。 8 .2 M E P 对网络管理业务的适用情况 ME P 对网络管理业务的适用情况如表2 所示。 表2 M E P 对网 络管 理业务的适用 情况 MEP 业务 简单的请求响应多次

27、批响应文件数响应定购通知 故障管理 配置管理存量 业务发展 配置 性能管理 安全管理 图例：代表表示ME P 适用于该类管理业务 9 传输层的技术要求 当 使用H T T P 传输S O ”消息时，必须遵循下述条件： 1 ) H T T P 头中的m e d i a 类型必须依据R F C 2 3 7 6 设置成“ t e x t / x m P ; 2 ）只能使用H T T P 的P O S T 方法来传送S O A P 消息； 3 ) H T T P 头 中的 S o a p A c t i o n 头必 须 存在； 如 果 不用， 必须 填写 空 字符串 ； 4 ) H T T P 本身

28、的返回码必须能够正确指示S O A P 响应的状态，当出现S O A P 异常的时候，H T T P 月 及 务 器必须返回状态码5 0 0 用于指定服务器内部错误： w w w . b z f x w . c o m Y D / T 2 1 4 5 - 2 0 1 0 5 ）必须使用H T T P 协议的1 . 1 版本。 当使用H T T P S 进行传输S O A P 消息时，响应方和请求方必须独立提供自己的公钥和证书，对接过程 要实现双方认证，尽量避免出现单向认证情况。 如果使用异步交互方式，请参考相应中间件的具体规定，在附录A 中给出了使用J MS 中间件作为传 输层的技术要求参考。

29、 1 0 安全要求 基于WS 技术的网管接口必须具备如下安全能力： 1 )认证能力，实现请求方和响应方之间的信任认证，如X .5 0 9 数字证书或是K e r b e r o s 证书； 2 ）授权能力，控制和监控访问特定资源的能力： 3 ）审计能力和可追踪能力，用于避免各种欺骗、攻击等行为； 4 )数据的完整性和机密性，确保交互的数据不被窃听和串改。 为确保达到上述安全能力，在传输层面上，可以使用S S L / T S L 来实现双方的认证和消息的加密；在 消息层面上可以 使用X M L 签名和X M L 加密等技术来提高数据的完整性和机密性； 使用Ws - S e c u ir t y

30、规范定 义的S e c u r i t y T o k e n 和S A M L 来实现认证和授权功能。 w w w . b z f x w . c o m YD汀 21 4 5 - 2 0 1 0 附录A （ 资料性附录） 使用J MS作为传输协议的技术要求 J MS 作为J 2 E E 架构中的一部分为多个运行在不同环境下的J a v a 应用提供了灵活可靠的通讯机制。最 新的 J M S 版 本是1 . 1 版 本， 发布 于 2 0 0 2 年 4 月 ， 相 关的 规范 可以 参考 h t tp :/ /j a v a .s u n .c o m / p r o d u c t s

31、/J*m s / . 如果网管接口 A 使用J MS 作为通讯底层，对J MS 消息的具体要求： 1 )头部分，J MS 定义的标准头信息，J MS 标准定义了很多头属性，其中很多是有J MS 服务器在发送 消息的时候自 动填写，只有如下头信息可以通过程序设定： a ) d e li v e r y Mo d e ( x s d :i n t ）指定传送的消息是否需要持久化； b ) t i m e T o L i v e ( x s d : l o n g ） 毫秒级别， 指定消息的存活时间； c ) p r i o r i t y ( x s d : in t ) 指定消息的优先级别； d

32、 ) r e p ly T o N a m e ( x s d : s t r i n g ）指 定一 个J N D I 的 名字， 通过这 个名 字可以 找 到一 个 接受响 应消 息的 Q U E U E /T O P I C o 2 ） 属性部分， 有J MS 指定的标准属性，应用程序也可以添加自己的属性；这些属性是可以被用来作 为消息过滤；下面这些是标准属性，可以被用于过滤消息： a ) t a r g e t S e r v i c e ( x s d : s t r i n g ）用于指定最终处理消息的 服务的名字； b ) b i n d in g V e r s i o n (

33、 x s d : s t r in g ）指定 传 送的 S O A P 的 消 息的 版 本； c ) s o a p A c ti o n ( x s d :a n y U R I ） 指定s o a p A c t i o n ; d ) i s F a u lt ( x s d : b o o l e a n ） 指定消息体部分的S O ”消息是否是一个f a u l t 消息； e ) s o a p M E P ( x s d :s t r i n g ） 指定消息是否需要响 应 （ r e q - r e s p 或o n e - w a y )。 3 ）消息体部分，使用T E

34、X T 样式的消息格式。 无论是响应方还是请求方在使用J MS 作为通讯层的时候，都需要事先指定如下属性用于和 MS 服务 中事先定义好的 Q U E U E / T O P I C 建立连接： 1 ) d e s t in a t i o n N a m e ( x s d :s t r i n g ） 指 定一 个 J N D I 的 名 字， 用于 查找 将被 连接的 T O P I C 或是 Q U E U E ; 2 ) c o n n e c t i o n F a c t o r y N a m e ( x s d :s t r i n g ） 指定 一 个 J N D I 的

35、名字， 用于 查 找 建立 连 接所 需 要连 接 器 工厂； 3 ) i n i t i a l C o n te x t F a c t o r y ( x s d :s t r i n g ） 指定 一 个上 下文 工 厂的 J a v a 类名 字， 用 于初 始 化本 地 J N D I 上 下 文； 4 ) j n d i U R L ( x s d : a n y U R L ） 指定J N D I 服务器监听 连接请求的U R L o 当请求方通过 MS 发送消息时，需要按照上述要求设置 MS 消息。表A . 1 和A .2 做了概括和总结。 表 A . ， 请求方在构建请求消

36、息时需要完成的工作 域值 J M S 消息头 J MS D e l i v e r y Mo d e持久、非持久 J MS E x p i r a t i o n毫 秒，默认为 0（ 永久消息） J MS P r i o r i t y优先级 （ 如果不 指定， 将由 JMS 服务自 行决定） J MS De s t i n a t i o nJ N D I 名字 J MS R e p 1 y T o除了 。 n e - w a y 模式， 这个属性必须 指定， J N D I 名 字标定的Q U E U E t r O P I C ， 用于接 受响 应消息 w w w . b z f x w

37、 . c o m YD 汀 2 1 4 5 - 2 0 1 0 表 A . 1（ 续） 域值 J M S 消息属性 t a r g e t S e r v i c e 可选 s o a p A c t i o n 可选 b i n d i n g V e r s i o n 可选 s o a p M E P 可选 J MS 消息体 b o d y 建议是文本消息格式 表 A . 2 响应方在构建响应消息时熏要完成的工作： 域值 J MS 消息头 J MS D e l i v e r y Mo d e从请求消息中拷贝 J M S E x p i r a t i o n 毫秒，默认为0（ 永久消息） J M S P r i o r i t y 从请求消息中拷贝 J MS De s t i n a t i o n 从请求消息中拷贝 J MS Co r r e l a t i o n l D从请求消息中拷贝 （ J M S 自 动生成） J M S 消息属 性 i s F a u l t 指定是否是f a u l t 消息 b i n d i n g V e r s i o n 从请求消息中拷贝 s o a p