6.ctg-mboss crm2.0渠道服务总线功能技术_v0.99

1、目录1文档说明编制说明1适用范围1阅读指南2起草. 3解释权3. 32综述.1驱动力3CSB 概念4CSB 定义42.2.2CSB 集成类型52.2.3SOA 与 EAI 的异同53CSB 应用体系架构综述8省内交互服务9省 CRM 与CRM 交互服务124CSB 平台体系架构.1通用模型14CSB 服务提供模块14功能描述CSB 服务逻辑模块15功能描述CSB 服务配置模块18功能描述CSB 服务模块20功能描述文

2、件交换模块21功能描述215CSB 平台技术要求25.3.1总体技术要求28支持协议及标准30性能要求31主要性能指标315.3.2性能指标要求35.7可用性33可扩展性33安全性33指标346CSB 实施说明36.4服务设计原则35CSB 平台技术应用说明35CSB 建设模式41实例417附录一规范编制. 428附录二ESB 相关介绍48.4IBM Message Broker42Oracle Service BUS49TIP(The Integration Platform)51其他579附录三SOA 管控建议

3、5910附录四术语定义6111附录五 参考文档6212附录六 命名规则6312.4服务编码规则63服务名称规则64服务命名规则65名称空间命名规则661文档说明1.1 编制说明是在中国电信信息化战略规划（ITSP）2.0 的总体指导下结合第二阶段的“主动服务，优化管理”的目标，为了实现 IT 服务支撑的流程化、标准化、规范化,引入了 IT 系统的整合技术 SOA。由于 CSB 在中国电信的和作用，CSB 的引入时机，CSB 平台的选型依据，CSB 的实施方法等问题，缺乏系统而准确的论述，因而急需一份规范以指导的 CSB 建设。下图所示 CSB 规范文档在总体规范中的。图

4、表 1-1： CSB 规范文档在总体规范中的1.2 适用范围作为中国电信 CTG-MBOSS 规范的重要组成部分，结合 CTG-MBOSS的总体框架和各目标系统的规划，统一考虑 CRM 域内部各系统，与其他域系统如 OSS、EDA、MSS、Billing 及枢纽系统的集成关系和服务要求，适用于中国电信集团公司下属省（市）电信公司对 CSB 的规划和建设。1.3 阅读指南第 2 章节对 CSB 概念进行了具体的定义，并阐述了 CSB 的集成类型，分析了 SOA 与 EAI 的异同点。第 3 章节阐述 CSB 的应用体系架构，强调 CSB 必须承担和 CRM，接入和 CRM 之间的服务交互，并列举

5、了省 CRM 提供给和的服务列表。第 4 章节对 CSB 平台的体系架构进行了具体的图示与描述，并详细描述了服务提供层，服务逻辑层，服务配置层，服务层，文件交换的功能。第 5 章节对 CSB 的总体技术要求及性能指标性能要求上做出了详细明确的阐述，并从可用性，可靠性，可扩展性，安全性对 CSB 平台功能进行具体的说明。第 6 章节对 CSB 与服务实施原则进行了具体的阐述。附录一规范编制。附录二 ESB 相关介绍， IBM Message Broker ， Oracle AquaLogicService BUS，普元 TIP。附录三 SOA 管控建议。附录四 术语定义。附录五定义了服务编码规则

6、，服务名称规则，服务命名规则，名称空间命名规则。在中，对于规范要求的刚性程度采用以下级别：必须：表示该条目是必须，原则上不能这样的要求。不允许（不可以）：标识该条目绝对。应该（建议）：表示在某些特定条件下存在忽视该条目的理由，但是忽视或该条目时必须仔细衡量。不应该（不建议）：表示在某些特定条件下存在所描述行为可接受或有效的理由，但实现该行为时必须仔细衡量。可选（可以）：标识该条目确实可选。某些厂商可能出于市场或其它原因实现该选项，另一厂商可能出于类似理由不实现该选项。1.4 起草起草为中国电信公司。1.5 解释权的解释权属于中国电信公司。1.6的属于中国电信公司。2综述2.1 驱动力近几年在中

7、国电信企业信息化战略规划（ITSP）1.0指导下,信息化建设取得了显著成果，对企业运营的总体支撑能力日益增强。与此同时，技术体系方面存在着关键应用系统支撑能力不足、数据质量不高、系统间互联互通不畅等问题；中国电信企业信息化战略规划（ITSP）2.0 提出技术体系应继续按照“模块化、松耦合、可配置”的技术思路；遵循“数据与功能分离，功能与流程分离，应用与展现分离，生产与分析分离”的技术原则，保证以相对稳定的技术架构去适应不断变化的企业需求。在 CRM 域内存在多个系统，例如 10000 号、网厅、CRM系统，缺乏统一的交换点，CRM 域内各系统之间存在网状连接。各个功能重复、系统维护难、需求支持

8、难、管控难、投资大，协同难、客户体验不统一等问题。目前 CRM 域各系统已经初步形成各种基础构件（例如管理、用户信息保存）等，但是在使用基础构件组一个业务逻辑的时候，基本是采用硬编码的方式，而不是基于流程技术和规则技术进行动态集成，导致系统不能很好的支持各种差异化需求（例如对特定的受理场景增加默认处理规则），不能很好的融入一些新的功能点（例如进行业务布点，例如推荐信息按需推送），难以对业务规则等通用的逻辑进行有效管理, 系统不能敏捷的对新需求做出反应;TMF( 电信管理) 所提出的 eTOM （ 增强的电信运营模型） 中的实现域（Fulfillment），为了提升管理子功能域，为各的、销售、服

9、务提供支撑能力，需要专属的平台去支持实现域（Fulfillment）支撑流程。通过引入 SOA 的架构可以有效解决目前 CRM 域内存在的问题，采用 SOA 架构可以重用现有服务，或者扩充服务，减少重复开发。采用 SOA 的服务分析方法对 CRM 域内的主要业务流程进行分析，发现大量可复用的业务服务，需要建设 CRM 域的服务总线去承载。通过引入 CSB 的概念后能实现应用的规范化接入，应用的集成由点对点接入转换为松耦合的总线型接入，通过规范化的服务封装标准对应用服务进行封装，发布到服务总线，通过服务总线的通入、消息处理和路由，结合流程集成平台，实现服务在应用间的集成和协作。2.2 CSB 概

10、念2.2.1 CSB 定义企业服务总线（Enterprise Service Bus，ESB）是实现 SOA 基础架构的关键组件， 它为 SOA 提供了一个底层的通讯架构，用于实现服务请求者和服务调用者之间交互。企业服务总线在 SOA 架构中实现服务间的智能化集成与管理中介，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能，它支持异构环境中的服务、消息以及基于的交互，并且具有适当的服务级别和可管理性。SOA 是面向服务的体系结构，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口起来。接口是采用中立的方式进行定义的，它于实现服务的硬件平台、操作系统和编程语言, 这

11、使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。服务总线是CRM 域内所有服务的中心，CRM 业务服务层甚至业务流程层提供的服务都可以在CSB 上进行，从而对 CRM 域内的所有服务进行统一管理和；解耦域内各个子系统之间的调度。本次 CRM 规范中新引入的 CSB 为 ESB 在 CRM 域内的应用，主要功能是负责连通性和服务中介。2.2.2 CSB 集成类型SOA 是面向服务的体系结构。是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约起来。ESB 是逻辑上与 SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方

12、法和在分布式异构环境中进行服务交互的功能。因此 CSB 的集成类型是服务的集成。服务集成：基于中间件技术建立应用系统之间的连接，处理应用之间的服务请求，进行通信协议、消息格式和消息内容的转换，并提供路由服务，实现服务请求和信息在应用之间安全而有效的传输。支持多种服务集成方式，比如 JCA、Web 服务、Messaging、Adaptor 等；服务总线集成的对象是服务，所有集成的服务由服务目录统一管理，服务被加入到服务目录时，产生入站服务和出站服务。入站服务包括端口器和入站服务目的地，出站服务包括出站服务目的地和端口目的地。对于服务使用者来说，它看到的是端口器，调用消息发给端口器，由端口器将消息

13、路由到入站服务目的地，服务总线再将消息路由到出站服务目的地，出站服务目的地将消息路由到端口目的地，端口目的地将消息到正在使用的协议的总线调度模块，由调度模块调用相应服务。2.2.3 SOA 与 EAI 的异同SOA 和 EAI 的相同点:1. 在技术层面有统一的数据和接口定义，可以方便整合各个异构系统。2.都兼容各组件技术（,EJB），调用技术(RMI)。3.提供将简单服务或者操作编排组织成更复杂的服务或者操作。4.支持各种通讯协议转换、消息格式转换。从技术角度上讲，两者是很类似的。SOA 和 EAI 的区别：1.SOA 提供了开放的规范和标准：数据定义 SDO，接口定义 SCA，服务编排 B

14、PEL;EAI 的规范和标准都是各个 EAI 平台厂商私有的。2.SOA 服务调用时可以动态绑定服务。对于 EAI 来说，调用是设计时静态绑定的。3.SOA 提供的服务接口是开放的，可以在 SOA 平台以外异构的接口调用 SOA 平台上的服务,如可以使用 EJB 接口调用 SOA 平台上的服务。EAI 的接口是私有的，只能在 EAI 平台内部调用，EAI 只提供一种标准的接口来调用异构系统的功能。4.从设计思想角度，SOA 旨在基于分布式的高可复用性服务集合来构建企业应用系统；EAI 只提供连接，流程编排，在设计思想方式上不做任何限制。5.SOA 的服务分为业务服务，基础服务两个层次；EAI

15、中的适配器相当于封装已有系统的基础服务。SOA 强调服务的复用性，实现异构服务接口的互联互通。EAI 强调集成异构系统，把各个已有系统的异构接口封装为统一的接口。EAI 不强调服务复用，但也可以用 SOA 的思想配以 EAI 平台来设计开发企业应用。6.在设计层面，SOA 将应用系统划分为高可复用的服务组成的集合。服务提供层，服务逻辑层，服务配置层，服务层几个层次。设计思路更强调从上到下，即从业务到技术。EAI 提供接口封装技术，自动流程的编排。适配器相当于基础服务。设计思路一般是从下而上，即从技术到业务。技术层面，SOA 是旧的组件技术和 EAI 技术的组合和升级。所以实施 SOA 项目，最

16、主要的还是在设计层面上如何把业务系统划分为粒度合适，高聚合低耦合，复用性好又兼顾性能的服务集合。7.在技术层面，SOA 提供了开放的数据接口标准，方便异构系统的互通互连，和 EAI功能相同，但更开放更灵活。ESB 是 SOA 的应用的重要组件，ESB 服务总线是 EAI 总线的升级版，CSB 与 EAI之间主要有以下主要区别：图表 2-1： CSB 与 EAI 差异CSBEAI概念面向服务，服务重用，重视标准和开放性应用集成，面向接口，靠适配器完成数据转换，目标为解决特定的问题CSB CRM 域内各子系统之间的服务集成,并承担与 公司 DEP 的服务集成在企业内部各功能域之间的集成技术CSB

17、主要进行服务集成,量级轻,采用统一的接口数据格式与标准，支持服务组件架构（SCA）主要进行应用集成，量级重，接口数据格式和标准不统一，不支持服务组件架构（SCA）运维CSB 平台重视服务管控，服务重用可配置化平台无服务概念，只有接口，无法进行管控，应用整合需要开发适配器33.1CSB 应用体系架构综述图表 3-1： CSB 应用体系架构针对目前情况，CRM2.0 新引入 CSB，提供对服务的管理能力，包括生命周期、版本管理、质量保证以及安全认证等，提供对异构数据的封装转换能力，支持服务请求的查找、透明路由等，细化总线支持的接术标准。从业务功能层面主要包括以下几个方面：必须承担省 CRM 与DE

18、P 平台进行交互的CSB（DEP 平台）的服务交互：支持 CRM 系统把涉及与服务(3.3 省 CRM 与CRM 交互服务)必须在 CSB上，CSB 能够结合 CRM 提供的服务, 通过路由、协议转换、数据转换的等基础功能，按照<<中国电信级 CRM枢纽 - CEP 协议>>的要求，为DEP 提供相应的全网服务。必须承担省 CRM 与接入的服务交互：支持 CRM 系统把涉及与接入进行交互的服务(3.2 省内交互服务)必须在 CSB 上(这里的接入包括门户或是其他的外部接入，如淘宝等) , CSB 能够结合 CRM 提供的服务, 通过路由、协议转换、数据转换的等基础功能,

19、 按照<< CTG-MBOSS CRM2.0 客户接触门户分册 >>要求, 为接入渠道提供相关的服务。CRM 域内不同子系统之间的服务请求者对服务提供者的调用，可以通过 CSB 来进行；由 CSB 提供智能路由、协议转换、数据转换、应用适配，传输加密，流量控制等功能。可以将 CRM 系统对外系统提供的服务到 CSB 上，如提供给 OSS、Billing、MSS、ODS 等系统的服务。省内其他业务域系统，通过 EAI/ESB 进行应用的整合，由 EAI/ESB 将这些系统对 CRM 系统提供的能力，包装成服务，到 CSB 上。如服务开通的服务、费用、帐务的服务等，供 CR

20、M 域内的子系统使用。CRM 业务服务层甚至业务流程层提供的服务都可以在 CSB 上进行，从而对 CRM 域内的所有服务进行统一管理和；解耦域内各个子系统之间的调度。实现对所有服务的管控，包括对服务调用权限的定义和控制以及对服务全生命周期的管理，即管理每个服务从需求提出-开发-发布-部署上线-维护更新-下线的全过程。3.2 省内交互服务名称服务描述服务提供者参见CustInfoMaintain完成 的建立、修改、客户群关联、客户关系关联、客户群组关联、客户归并等 的操作。CRMCTG-MBOSSCRM2.0 技术规范中的 章节CustPasswordMgr为客户提供客户 及 密

21、码的 修改和 重置等功能。CRMCTG-MBOSSCRM2.0 技术规范中的 章节CustAuthenticate根据客户 、证件类型、证件号码、业务号码，对接入客户进行识别验证，返回识别验证结果。CRMCTG-MBOSSCRM2.0 技术规范中的 章节CustInfoQry根据输入条件客户的相关信息CRMCTG-MBOSSCRM2.0 技术规范中的 章节CustPointsInfoQry根据获取的客户标识信息，按时段 信息， 信息包括当月新增 、当月可用、当月已用 等。CRMCTG-MBOSSCRM2.0 技术规范中的 章节Cu

22、stPointExchange根据兑换规则进行兑换并兑换日志，兑换结果反馈CRMCTG-MBOSSCRM2.0 技术规范中的 章节CustPointTransfer根据业务规则，客户把自己拥有的部分或全部 转赠给其他客户CRMCTG-MBOSSCRM2.0 技术规范中的 章节MarketResInfoQry根据、操作员和属性信息（属性编码或者属性名称）， 信息CRMCTG-MBOSSCRM2.0 技术规范中的 章节MktResMantain根据输入的号码信息占用/预占移动号码CRMCTG-MBOSSCRM2.0 技术规范中的 章节

23、EqptMaintNetworkQ ry根据省、地市、终端品牌或者售后网点的名称关键字模糊 所在位置的售后网点信息，返回售后网点信息包括售后网点名称、售后网点地址、业务受理范围、营业时间、联系 、附近标志性建筑、公交线路等信息。CRMCTG-MBOSSCRM2.0 技术规范中的 章节OrderCreate根据获取的订单信息，进行订单校验，如果校验通过，新增订单 ，并启动订单处理流程，返回订单保存结果。CRMCTG-MBOSSCRM2.0 技术规范中的 章节OrderCancel用于获取 枢纽转发CRM 系统的撤单申请或省 CRM 本身发起的撤单申请，根据获取的撤

24、单原因及订单编号，进CRMCTG-MBOSSCRM2.0 技术规范中的 章节行撤单审核、撤单校验和订单撤销处理竣工操作，并启动撤单处理流程，生成撤单 ， 返回保存结果。OrderUntreat用于获取 枢纽转发CRM 系统的退单申请，包括退单规则验证和退单处理，并启动退单处理流程，返回保存结果。CRMCTG-MBOSSCRM2.0 技术规范中的 章节OrderChargeCalcul ate根据获取的订单信息，计算与订单操作相关的 费用， 返回 费用信息CRMCTG-MBOSSCRM2.0 技术规范中的 章节OrderInfoQry根据受理时间段

25、、业务号码、受理操作员、客户编码等条件订单，返回订单信息(包括订单状态等)CRMCTG-MBOSSCRM2.0 技术规范中的 章节pleteNotice向省订单竣工/起租信息CRMCTG-MBOSSCRM2.0 技术规范中的 章节OrderActionValid根据客户标识、 实例标识和业务操作类型对即将受理的订单进行可行性验证，返回验证结果CRMCTG-MBOSSCRM2.0 技术规范中的 章节OrderChargeWriteO ff根据获取的订单信息和支付信息，对 费用进行销帐， 返回销帐结果。CRMCTG-MBOSSCRM2.0 技术规范中

26、的 章节CustQuestionAccep t根据获取的客户问题信息，生成客户问题受理单（按照不同的问题类型，形成投诉建议、故障申告、服务请求问题单），返回保存结果CRMCTG-MBOSSCRM2.0 技术规范中的 章节CustQuestionQry根据通过问题单号等 条件对问题单的处理过程和结果进行 ，返回 情况CRMCTG-MBOSSCRM2.0 技术规范中的 章节CustAppraiseRetur n根据客户接触后获取的客户评价，客户问题单的客户评CRMCTG-MBOSSCRM2.0 技术规范图表 3-2：省内交互服务列表3.3 省 CRM

27、 与CRM 交互服务服务名称服务描述服务提供者参见CustInfoMaintain完成 的建立、修改、 、客户群关联、客户关系关联、客户群组关联、客户归并等 的操作。CRMCTG-MBOSS CRM2.0 技术规范中的 章节CustInfoQry根据输入条件客户的相关信息CRMCTG-MBOSS CRM2.0 技术规范中的 章节CustPointsInfoQ ry根据获取的客户标识信息， 按时段信息，信息包括当月新增、当月可用、当月已用CRMCTG-MBOSS CRM2.0 技术规范中的 章节价结果中的 章节MarketEvent

28、Manage管理维挽活动信息，包括新增、修改等CRMCTG-MBOSSCRM2.0 技术规范中的 章节MarketInfoDeal获取下发的工单信息，进行活动执行。CRMCTG-MBOSSCRM2.0 技术规范中的 章节MarketResResp接收 对省公司在商机转化过程中提出的 申请反馈。CRMCTG-MBOSSCRM2.0 技术规范中的 章节SellingNetworkQry用于 营业网点信息，根据地市、区县 或者营业厅的名称关键字模糊 所在位置的营业厅信息，返回营业厅信息包括营业厅名称、营业厅地址、业务受理范围、营业时间、 、附近标志性建

29、筑、公交线路等信息CRMCTG-MBOSSCRM2.0 技术规范中的 章节图表 3-3：省 CRM 与CRM 交互服务等。CustPointExchan ge根据兑换规则进行 兑换并 兑换日志，兑换结果反馈CRMCTG-MBOSS CRM2.0 技术规范中的 章节OrderCreate根据获取的订单信息，进行订单校验，如果校验通过， 新增订单 ，并启动订单处理流程，返回订单保存结果。CRMCTG-MBOSS CRM2.0 技术规范中的 章节OrderCancel用于获取 枢纽转发CRM 系统的撤单申请或省 CRM 本身发起的撤单申请，根据获取的撤

30、单原因及订单编号，进行撤单审核、撤单校验和订单撤销处理竣工操作，并启动撤单处理流程， 生成撤单 ，返回保存结果。CRMCTG-MBOSS CRM2.0 技术规范中的 章节OrderUntreat用于获取 枢纽转发CRM 系统的退单申请，包括退单规则验证和退单处理， 并启动退单处理流程，返回保存结果。CRMCTG-MBOSS CRM2.0 技术规范中的 章节OrderInfoQry根据受理时间段、业务号码、受理操作员、客户编码等条件 订单，返回订单信息(包括订单状态等)CRMCTG-MBOSS CRM2.0 技术规范中的 章节pleteNotice

31、向省订单竣工/起租信息CRMCTG-MBOSS CRM2.0 技术规范中的 章节MarketResResp接收 对省公司在商机转化过程中提出的 申请反馈。CRMCTG-MBOSS CRM2.0 技术规范中的 章节4CSB 平台体系架构4.1 通用模型一个通用的 CSB 架构，根据其功能的不同划分成以下几个层次：服务提供层、服务逻辑层、服务配置层，管理层，文件交换层，如图 5-1 所示：图表 4-1：CSB 参考模型4.2 CSB 服务提供模块4.2.1 功能描述服务提供层提供 CSB 平台和应用系统的连接功能。CSB 平台作为连接各种应用的核心平台，通过它的服务

32、提供层来实现与其它应用系统的通信，并这些系统的。1. 协议适配必须支持协议转换，将其他应用系统的协议转化为CSB标准的接入协议。并将请求数据至逻辑层做相应处理。服务配置流量控制协议适配服务提供传输加密认证鉴权管理服务编排消息路由服务中介消息分发服务逻辑服务丰富消息组合数据转换服务发现文件交换服务编排管理配置文件交换服务质量管理配置目录管理路由规则配置数据转换配置日志审计权限管理容器 服务服务服务配置2. 认证鉴权必须提供对服务的权限控制的能力，根据需要可在不同级别上进行，如服务调用、服务中介的操作。3. 传输加密可以采用数字签名、加密或同时使用两种加密方式。4. 流量控制可以控制目标服务的请求

33、数量，防止对目标服务造成过大，可以动态调标服务的请求数量。4.3 CSB 服务逻辑模块4.3.1 功能描述服务逻辑层是 CSB 服务总线逻辑处理的具体实现层，服务逻辑层包含的具体功能包括：1. 消息路由是基于一定的规则将数据或消息到合适的目标系统，是一种寻址功能，路由的规则存放在配置表中。动态路由通过条件转移语句（或服务调用）分析消息，从而检索某个数据元素或多个数据元素的数值。不同的业务服务目的地被赋予这个条件检查的不同数值组合，允许将消息动态到多项业务服务。根据业务服务需求，转换可用于一个或多个此类目的地。Ø 消息路由应该支持以下几种方式1) 基于内容的动态路由服务请求者将请求消息

34、给 CSB，CSB 平台根据消息内容和事先定义好的路由规则决定应调用的服务。图表 4-2：基于内容的路由示意图2) 静态路由这种路由方式主要用在请求/应答的传输模式下，客户端向 CSB请求时，CSB，CSB 查找要对服务进行。这种情况下，服务 B 必须已在服务目录中进行到相应服务后，对服务进行调用。图表 4-3：基于服务的路由示意图2. 可以有消息组合功能： 从一个或多个应用程序获取多个消息并将其合并为单个信息，以作为新消息。入站消息可以来自应用程序或可以为来自一组应用程序的异步响应消息，而这些应用程序从消息拆分器模式（在下面描述）实现接收请求。3.可以有消息分发功能：将数据从一个应用系统转发

35、到另一个或者多个应用系统，无需修改消息有效负载的格式或内容。4.应该有数据格式转换功能：提供不同的数据模型间的转换能力，系统间数据的差异性，负责在不同种类的系统和应用之间进行数据的转换，统一数据中的内容和语法，并且负责维护在不同系统之间的数据结构。它能在分布式的企业应用系统中对和接收的数据进行设计，使得输入的数据根据自定义的格式或规则进行合并、校验、转化、分解为输出的数据，这样，每个应用系统都可以保留各自原有的数据，且不同应用系统之间可以实现数据共享。在多个应用系统之间实现数据转换有两种方式：一是在两个应用之间直接定义数据关系，二是引入通用数据模型，建立通用数据模型和各个应用系统的数据模型之间

36、的转换，而不是直接在应用系统之间进行转换。现有的 ESB 平台在实现数据转换时多是采用上述第二种转换方式，实现通用数据模型和各个应用系统的数据模型之间的转换，而不是直接在应用系统之间进行转换。这样做的好处在于：被集成的应用系统之间是松耦合的关系，当某一应用系统发生改变时只需要改变该系统的数据模型与通用数据模型之间的转换关系、传输协议特定格式与 ESB 统一消息模型的转换、各服务间数据模型的转换。5.可以有服务编排功能：每个服务均可以承担服务提供者和服务使用者两种，服务使用者通过服务总线的接口获取相应的服务；ESB 提供服务编排的能力； 服务编排是指可以通过开发或者第流程配置的方式实现服务组合，

37、形成新的服务的过程。6.应该有面向服务的中介功能：为了支持服务请求者和提供者之间的交互所必需的服务虚拟化和面向服务的连接，ESB 提供了中介流。中介流（通常简称为中介）包括通过某个接出点接收来自请求者的入站请求消息，处理请求消息，然后使用某个接入点向提供者出站消息。如果适用的话，中介还可以包括接收相关的入站响应消息，处理相关的响应消息，以及向请求者出站响应消息。ØØØ7.应该提供位置透明性的服务路由和服务。应该支持多种消息传递型式(请求/响应，单路请求，发布/订阅等等) 。应该支持广泛使用的传输协议(例如 HTTP)等等 。可以有服务发现功能：服务提供者可以组织到

38、可执行的目录中。使用者可以搜索这样的目录来查找所需服务的提供者。8.应该支持服务丰富功能：将请求消息在 CSB 平台上进行消息的丰富，构造新的符合服务提供者要求的消息，对丰富后的消息调用相应的服务。4.4 CSB 服务配置模块4.4.1 功能描述1. 服务配置应该包括系统运行参数、业务功能参数的配置，如服务的并发数，优先级，可用性，重试性，超时的配置等和原有服务的配置（对于新的服务在总线上配置）。2.服务Ø必须提供服务组件的服务和服务发布功能，实现服务接口、服务运行与服务参数等各种服务信息的和发布。Ø应该建立服务目录和服务库，对这些服务以及服务的元数据进行定义和，以便进行服

39、务的查找、发布、和管理。Ø3.建议支持服务批量发布、Web 界面发布和 API 方式发布等多种发布方式。权限管理ØØØØØØ必须提供组织、用户、及的动态维护；必须支持对组织的分级管理，支持对组织级别及层次的动态定义；所拥有的权限必须包括能够管理的数据范围和操作权限的集合；操作权限集合应该包括使用权限(如：增加、删除、修改等)和两类；当所拥有权限，支持将其拥有的权限进行转赋；必须支持一个用户可以拥有多个；ØØØ必须支持自动生成用户的初始，并提供的修改功能；不允许以明文的方式用户；必须支持自动或人工

40、生成账号，账号不能重复，用户在组织间调整时，无需调整用户的账号；Ø应该支持设置账号有效期及其到期后设置该账号状态为“无效”，删除用户时，只需将该用户置为“无效”状态；4.数据转换配置Ø应该具有配置不同数据格式转换的能力，能够对来自不同应用系统的数据进行识别和。Ø建议以图形化方式定制不同的数据转换逻辑，实现数据格式的转换和数据内容的整理；5.路由规则配置Ø建议动态路由通过条件转移语句（或服务调用）分析消息，从而检索某个数据元素或多个数据元素的数值。Ø允许将消息动态到多项业务服务，不同的业务服务目的地被赋予这个条件检查的不同数值组合配置。6.服务质

41、量管理配置Ø建议针对不同的服务请求者提供不同质量的服务响应的能力，例些服务的请求需要在事务中完成，有些服务的交互需要保证其可靠性，完整性。Ø建议支持参与者或系统管理员他们的服务质量需求，包括：请求的、消息内容的加密和、服务交互的自动审计以及应该如何传递他们的请求（例如，进行优化以提高速度或降低成本）。Ø建议设置服务级别协议 (SLA)，SLA 定义了业务和服务所期望服务的精确级别和质量。用户可以根据 SLA 的指标配置触发提示的规则。一个提示可以配置多级严重性，包括正常、提示、轻微、和严重。每个业务或服务可以组合多个提示情况，而每个提示可以基于下列参数。1). 成

42、功率，失败率2). 消息数3). 错误数4). 故障切换/重试次数5). 验证错误数6). 响应时间，最小响应时间，最大响应时间Ø 用户可设置 SLA 提示，向运行团队通知业务和质量有关的问题。服务的状况，或与提供的服务7. 服务编排管理配置可以将一个或多个服务进行编排而形成的组合服务，组合服务也可被其它服务调用。4.5 CSB 服务模块4.5.1 功能描述CSB服务、容器、日志审计的功能。CSB平台可模块主要包括服务以支持以一定间隔(不大于15分钟)向系统提供告警与指标数据。服务告警信息、指标可以支持JMS、SNMP或者等。服务信息可以提供给统一平台。1.服务服务必须包括服务、操作

43、等级别的调用 / 失败次数、平均响应时间等信息。2.容器Ø应该对服务容器的指标进行，例如服务容器运行状态、服务容器消耗、服务容器所包含服务的数量、当前服务容器中的请求数量等。Ø3.应该对于登录及越权调用服务的行为进行。日志审计日志是系统运行过程中，在某一时刻对系统某一运行状态的，其主要目的是对系统自身的运行状态、过程与性能进行跟踪、分析与调测。Ø应该进程的处理情况，包括每个步骤的处理成功与否，方便事后跟踪查找出错原因。Ø建议各应用系统到 CSB 平台的数据传输情况，日志内容，包括数据源 IP，数据目的 IP，文件名称、大小，服务调用开始时间，服务调用功能

44、结束时间等相关信息。ØØ应该保留的日志信息供。建议对系统的参数设置、操作的日志。4.6 文件交换模块4.6.1 功能描述在实施过程中，建议文件交换组件与其他组件分别部署以避免性能影响。与DEP 的批量信息交互可以由 CSB 承担。省内的批量文件交换建议由 CSB 承担。1. 可以进行目录管理目录管理格式是文件交换所使用的 FTP 协议的目录结构及文件命名规则等约定。批量数据文件由 CSB 平台提供统一的 FTP 服务器和空间。FTP 用户根据系统对目录的需要设置。目录结构如下图所示：应答目录上传目录缓存目录交互业务分类目录1上传目录省内交互目录请求归档应答归档应答目录上传目

45、录缓存目录目录管理交互省内归档上传目录省内交互目录图表 4-4：管理目录各类目录及文件名编码规则及权限如下表所示：序号目录/文件类型编码规则说明1目录管理CSBCSB 具有权限及其所有子目录的权限；业务分类目录2缓存目录目录缓存目录回复目录回复目录目录序号目录/文件类型编码规则说明2业务目录业务功能编码业务功能说明参见中国电信级 CRM枢纽 CEP 协议主数据的说明，业务系统拥有全部子目录权限。3交互headquarters4省内交互province5上传目录upload6目录download7回复目录reply8应答目录response9缓存目录mqsiarchive10请求归档hqreqa

46、rchive只有 CSB 具有权限；11应答归档hqresparchive只有 CSB 具有权限；12省内归档provincearchive只有 CSB 具有权限；13交互请求文件机构编码 +业务功能编码 +日期 + 序号 + “.xml”机构编码参见CEP 协议主数据说明；业务功能编码参见CEP 协议主数据说明； 协议编码参见主数据说明；日期格式为 YYYYMMDD；序号由系统自动产生，三个字节字符串。14交互应答正确文件机构编码 +业务功能编码 +日期 +序号 +“.xml.ok”在请求文件名称的基础上加上“.ok”的后缀。15交互应答错误文件机构编码 +业务功能编码 +协议编码 +日期

47、+序号 +“.xml.err”在请求文件名称的基础上加上“.err”的后缀。图表 4-5：目录文件命名规则及权限2. 可以进行文件交换文件交换由发起方、落地方、CSB 平台及CRM枢纽按照目录及文件的约定进行文件的上传、迁移、与备份。省公司系统发起接收处理流程：序号目录/文件类型编码规则说明16省内交互数据文件From+业务功能编码+to+ 业务功能编码+数据说明+日期+序号+.后缀省内系统间文件交换不采用 CEP 协议，采用文件名中定义传输者接收者的方式表示需要传送到的目的系统。数据说明是对文件内容进行简要说明，由传输和接收双方系统进行约定，例如：custinfo、 res 等。数据说明后缀

48、按照双方系统的约定格式，例如 txt、xml、gzip、bin 等。17省内交互数据文件成功文件From+业务功能编码+to+ 业务功能编码+数据说明+日期+序号+.后缀+.ok由数据接收方向数据发起方给出的处理成功标志文件，文件名由省内交互数据文件+.ok。18省内交互数据文件失败文件From+业务功能编码+to+ 业务功能编码+数据说明+日期+序号+.后缀+.err由数据接收方向数据发起方给出的处理失败标志文件，文件名由省内交互数据文件+.err。省内方CSB平台枢纽接收方1、方上传文件2、CSB迁移文件3、传输至枢纽4、DEP迁移文件5、接收方文件6、接收方处理文件7、应答文件上传到DE

49、P9、CSB应答文件8、DEP迁移文件11发起方应答文件10、CSB迁移文件12发起方处理应答文件图表 4-6：省公司系统-公司系统1)发起方系统在生成请求文件后将请求文件 FTP 到 CSB 该业务分类-交互-上传目录。2)CSB 自动定时扫描，将请求文件迁移到发起方上传目录的子目录缓存目录中。3)CSB 把发起方请求文件通过 FTP 上传到DEP 平台该机构目录-该业务分类目录-上传目录下，同时备份至 CSB 平台“请求归档目录”中。4)DEP 自动定时扫描，将发起方上传目录的请求文件迁移到接收方的目录。在迁移完成后同时将请求文件备份到发起方上传目录的子目录缓存目录中。5)接收方系统目录的请求文件并删除请求文件（防止下次重复处理）。6)接收方系统进行业务处理后按照应答文件的规则生成应答正确文件或应答错误文件。7)接收方系统把应答文件放在落地方目录的子目录的回复目录。8) DEP 自动定时扫描，将接收方系统回复目录的应答文件迁移到发起方的应答目录。在迁移完成后同时将应答文件备份到落地方目录的子目录缓存目录中。9) CSB 自动定时扫描，DEP 平台该机构目录-该业务分类目录-目录下-回复目录下的应答文件，并删除 DEP 平台上