企业服务总线ESB方案书
1需求综述 (4)
1.1主数据平台接口 (4)
1.2业务数据接口 (4)
1.3OA系统接口： (5)
1.4国家法定信息发布媒体： (5)
2系统解决方案 (5)
2.1系统技术架构 (5)
2.1.1运行平台 (6)
2.1.2开发平台 (6)
2.1.3监控平台 (7)
2.1.4公共服务 (7)
2.1.5适配器 (7)
2.2部署方案 (9)
2.2.1管理监控部分部署方案 (9)
2.2.2硬件选型建议 (10)
2.2.3逻辑分区部署方案 (11)
2.2.4硬件配置建议 (11)
2.2.5服务接口规范 (12)
2.2.6高性能、高可用性及扩展能力设计 (12)
2.2.7完善的安全机制 (13)
2.3整体解决方案 (15)
2.3.1接入控制 (16)
2.3.2通信接入模块 (17)
2.3.3请求系统适配 (18)
2.4集成服务功能 (19)
2.4.1服务治理 (19)
2.4.2提供对出错服务的及时检测和隔离功能 (20)
2.4.3协议转换 (20)
2.4.4消息格式转换 (21)
2.4.5服务路由 (22)
2.4.6监控和运维 (22)
2.4.7服务等级 (23)
2.5系统非功能需求 (24)
2.5.1可用性 (24)
2.5.2可扩展性 (24)
2.5.3可维护性 (25)
2.5.4安全性 (25)
2.5.5性能需求 (25)
2.6公用服务 (26)
2.6.1流量控制 (26)
2.6.2故障隔离 (26)
2.6.3统一流水号 (27)
2.6.4日志记录 (27)
2.7管理监控 (27)
2.7.1系统平台级监控 (27)
2.7.2应用级监控 (27)
2.7.3统计分析 (27)
2.7.4异常报警 (28)
2.7.5统一的运维管理 (28)
3技术支持与服务方案 (28)
3.1技术支持与售后服务体系 (29)
3.2服务管理模式 (29)
3.3服务响应 (30)
3.3.1问题优先级（或问题严重程度）级定义 (30)
3.3.2服务响应时间 (31)
3.3.3问题解决时间 (33)
3.3.4服务文档 (34)
3.4维护支持服务流程 (35)
3.4.1服务消息创建流程 (35)
3.4.2问题处理流程 (35)
3.4.3服务确认流程 (36)
3.4.4投诉及问题升级流程 (37)
1 需求综述
1.1 主数据平台接口
系统建立与SAP 相同的基础数据管理库，通过数据总线接口同步能源集团MDM 中传输过来的编码或数据，以满足电子采购平台基础数据管理的需求。基础数据信息包括：物料编码、计量单位、供应商、客户等。
1.2 业务数据接口
系统业务数据通过数据总线接口同SAP 、OA 、EC 等系统进行数据交互。
系统必须确保通过数据总线接口访问SAP 、OA
、EC 等系统数据与电子采购平台数据传输及时准确、数据完整统一；
1.3OA系统接口：
支持将电子采购平台中的待办事项发送到OA办公系统进行审批，并读取审批流。
1.4国家法定信息发布媒体：
按照国家相关要求，选择相关媒体建立统一接口，支持招标公告、变更公告、结果公示等的自动发布。如国家无强行规定，可以不做接口。
2系统解决方案
2.1系统技术架构
2.1.1运行平台
运行平台内部按照集成应用的特点分为多个集成“通路”，目前考虑分为四类通路：1、关键服务通路
关键业务、实时性要求高。
2、非关键通路
非关键业务，查询等。
3、服务代理通路
从目标架构过渡过程中，与集成目标无关的可以采取“穿透”的方式，减少实施工作量和实施成本。
另外，复用价值较低的服务请求也适合采用“代理模式”。
4、低成本通路
对于实时性要求不高，且信息量大的服务，可采取批量处理模式，降低集成实施成本。实际部署环境中，每一类通路都可以有多个物理部署，用来保证系统的可靠性，同时也支持横向的扩展和减少不同系统之间的相互影响。
2.1.2开发平台
基于ESB系统标准的服务接口定义、内部统一的元数据管理、数据结构和服务接口定义、路由规则等，实现多个技术通路的统一配置开发。
开发平台的是对各个技术通路实际实现方法的抽象封装。提供服务逻辑的开发框架和组件库，用于转换适配逻辑、公共服务逻辑等的标准化开发、组件重用和统一管理。
2.1.3监控平台
ESB应用系统要建立统一的日志规范、流水记录规范、错误码规范、系统运行状态检测规范、系统运行状态控制标准，实现对ESB系统整体统一的监视和控制。是
ESB系统的集成“控制面板”。
主要功能包括：异常监视、通知提醒、运行控制、实时查询、统计分析、服务的配置和发布、服务管理、统一维护和版本部署等。
由于ESB系统是整个企业的服务访问枢纽，ESB可以集中监控企业内所有的服务访问，能够提供各个系统的服务质量和状态的统计数据，例如：成功率、服务响应时间、服务访问量、服务状态异常等。
2.1.4公共服务
提供统一的流量控制服务、日志记录、接入参数控制等公共服务。从而实现多技术平台、多物理部署运行环境的公共服务支持。
2.1.5适配器
适配器是ESB系统解决与外部系统之间各类差异的总称。
ESB将外部系统分为请求系统和服务系统两类。
2.1.5.1服务系统适配器
对于服务系统，尤其是遗留服务系统，基本集成策略是由ESB项目组开发适配器进行集成。但是服务系统适配器，并不能解决所有的服务适配问题，例如：ESB服务接口规范与服务系统规范的复杂对应和匹配工作，尤其是涉及到多个服务系统接口的复杂流程调用部分，如果由ESB组合这类服务流程组合，解决相关的交易完整性、一致性问题，代价太大而且无法保证。
因此，实际集成实施过程中，不可避免的要涉及到对服务系统的改造工作。
2.1.5.2请求系统适配器
对于请求系统，ESB的基本原则是要求请求系统符合ESB的技术规范和服务接口规范。目的是减少不必要的转换适配层次，提高系统的集成服务效率，降低资源消耗。ESB系统可为请求系统提供API，对请求系统屏蔽通讯适配、报文组包等技术细节。请求系统只需要理解业务层面的接口规范，从而大大简化请求系统的集成工作，同时还可以加强对请求系统的监控管理，同时为接口技术实现的升级改造提供辅助支持。ESB也可以开发适配器，实现请求系统的集成。主要针对那些无法改造或改造成本过高的请求系统。
2.2部署方案
2.2.1管理监控部分部署方案
ESB系统的部署方案必须符合企业基础架构的要求。
1）WebServer和Application Server必须分离，分别部署在Web2区和APP区。或者Web2区的应用通过生产区域的APP，访问DB。
2）用户管理要符合集团的规范。用户权限控制统一通过UM。
UM决定用户是否有权限操作ESB的管理监控平台。
UM权限通控制通过以后，由ESB管理监控应用来进行详细的角色权限管理。3）考虑到费用问题，可以采用Apache和Tomcat。
2.2.2硬件选型建议
ESB系统目标架构硬件选型主要考虑从以下因素：
1）成本因素
ESB系统基于Java技术实现，具有跨平台的技术优势，因此可将成本是考虑硬件选型的首要指标，未来随着ESB应用规模的不断增长，硬件成本在项目投入所占比重将会增加，因此选择性价比高的硬件平台是提高效费比的有效途径。
2）硬件扩容周期
ESB作为企业内部信息化最为关键的服务枢纽，必须能够快速响应应用规模的增长，其中包括硬件的采购周期、系统扩容部署速度。
3）资源调配的简便性、灵活性
ESB系统应能够针对业务量的周期性变化，灵活的增减系统资源配置，资源的调整不应对集成服务持续性造成影响。
基于上述考虑，ESB系统的硬件推荐采用刀片服务器。
刀片服务器还具有以下优点：
1) 硬件成本相对低廉，配套的系统软件和中间件价格也相对较低。
2) 虚拟化的集中资源管理，可有效提高资源的利用率。
3) 在集群中插入新的刀片，就可以提高整体性能。
4) 支持热插拔，硬件资源可以轻松地进行替换，并且将维护时间减少到最小。
5) 节约空间、便于集中管理、易于扩展和提供不间断的服务。
2.2.3逻辑分区部署方案
2.2.4硬件配置建议
其对应分配如下：
2.2.5服务接口规范
ESB系统负责解决实施服务接口规范与服务系统接口的差异，可将主要的实施工作控制在ESB项目范围内，大大降低周边系统的改造工作量，配合一些系统的瘦身计划的分阶段顺利实施。
2.2.6高性能、高可用性及扩展能力设计
高处理能力保证措施
控制信息+XML应用报文，中间层次不必解析XML应用报文，使系统不仅具备完善的管理控制能力，同时还减少了报文解析开销，提高了效率。
非阻塞的异步模式、流水线式的作业处理，提高吞吐能力。
异步记录流水日志，保证信息的完整记录，同时不影响系统的处理性能。
系统处理能力可随硬件资源的扩展线性的增长。
系统所有配置规则均加载到Cache中，运行过程中不存在对数据库配置信息的读写操作，保证系统高效运行。
持续稳定运行保障措施
所有应用模块均为群集部署，系统不存在单点故障隐患，某个模块的故障不影响正常运行。
系统应用版本的升级可按模块分别进行，不影响业务的正常运行。
采用数据库分区技术，实现海量数据记录的清理和分区切换过程15秒钟内完成，无需采用与应用相关的数据库分表方式，实现批量数据处理对总线应用透明。
系统提供完备的动态安全刷新手段，配置信息可运行时在线刷新。
可扩展性
系统可以在CPU、内存等资源增加及扩容的情况下自我线性扩展处理能力；每个逻辑模块可以采用横向扩展的多物理模块部署。中间用队列进行通讯。
可维护性
系统具有较为完善的用户管理界面，提供对系统所有功能的维护与参数配置管理的功能；系统采用统一的服务模式和开发框架，从开发商增加可维护性，系统部署上采用多逻辑单元分离部署，减少系统内部的耦合度，增加整个系统的可维护性。
2.2.7完善的安全机制
企业应用集成技术使复杂的业务流程、大量的信息和数据在各IT应用系统和业务部门之间高效的流转和共享，实现业务流程标准化和自动化，促进业务流程优化，提高建行运营效率。任何不安全因素都会造成不可估量的损失，故所有数据的传输、处理、交换都必须在良好的安全环境下进行，因此，必须建立一套完整的安全机制，以确保整个通信系统的安全运行。方案主要为ESB系统提供如下几个方面的安全服务：1. 密钥管理
提供安全有效的密钥管理方案，实现应用系统和ESB系统的密钥产生、密钥分发、密钥更新、密钥注销等。提供密钥的自动更新机制，保证密钥的安全性，提供高效的对称密码算法，确保应用系统具有可用性和易用性。
2. 身份认证
保证接入ESB系统的合法性，提供应用系统和ESB系统之间的双向身份认证，采用基于证书的认证模式，系统使用的数字证书由第三方CA或者采用自运行维护的CA 提供。CA证书采用离线下发的方式，以PKCS#12文件的格式安装到ESB系统和应用接入系统。
身份认证完成后，双方得到一个64个字节的随机数，通讯双方使用的对称密钥都是基于这一组随机数产生，对称密钥的选取规则双方使用相同的策略。对称密钥和对方的公钥信息存放在系统主机的共享内存，方便应用系统加密使用
3. 通讯加密
ESB系统的安全性是保障IT应用系统安全可靠运行的重要环节，使用PKI技术实现系统的密钥管理和通讯加密是目前解决此类问题的最有效途径，应用系统和ESB系统之间通讯的报文使用对称算法加密保护其机密性。为了提高密码运算的处理速度，这里推荐使用AES算法，密钥的长度为128bit。
通讯双方在身份认证完成后，在共享内存中保存对称密钥。客户端和服务器端的加密流程如下：
客户端加/解密流程：
1) 查询共享内存中的对称密钥和算法ID，根据加密要求选取对称密钥，如果共享内存中没有对称密钥，加/解密失败。
2) 使用查询得到的对称加密密钥，对报文进行加/解密处理。
服务器端加/解密流程：
1) 根据客户端的系统代码，查询共享内存的加密密钥和算法ID，如果共享内存中没有对称密钥，加/解密失败。
2) 使用查询得到的对称密钥，对报文进行加/解密处理。
4. 关键字段MAC
2.3整体解决方案
ESB集成技术架构方案划分为四个层面：渠道通迅接入、数据交换层、平台服务调度层、服务适配层。系统的每个层次都可进行横向扩展，实际应用中系统处理能力可以线性增长。
●对于渠道服务请求的接入，ESB提供标准的通迅协议（支持TCP/IP、HTTP、
SNA、FTP、MQSeries、JMS等协议和中间件）和ＭＢＳＤ标准接口规范，同时还为请求系统提供服务请求的API，屏蔽通讯协议和报文格式的技术细节，能够提高请求系统的集成开发效率、减少转换适配环节，同时还大大加强了总线系统对接入的控制和管理，促进了集成应用的快速推广和可靠运行。
●对于改造成本过高的存量系统，
通过集成开发在数据交换层实现分类路由、同步异步转换、消息格式转换、代码转换等功能。
●平台服务调度支持四种模式：
（一）、ＭＢ通道，用于高时效性、高一致性、高吞吐能力的服务；
（二）、ＷＥＢＭＥ通道，用于时效性和一致性要求不高的服务；
（三）、服务代理通道，目标架构过渡过程中，与当期集成目标无关，可以采取“穿透”的方式，减少实施工作量和实施成本。另外，复用价值较低的服务请求也适合采用“代理模式”；
（四）、低成本通道，对于实时性要求不高，且信息量大的服务，可采取批量处理模式，降低集成实施成本及节省系统资源。
所有适配器需要在对存量系统分析后集成开发，ESB集成方案中集成产品的相互访问统一使用ＭＱ队列方式。
2.3.1接入控制
需要完成以下功能：
1.对渠道提供不同协议的接入功能，包括MQ，webmethods, http等协议的接入。
2.对不同的渠道提供不同的接入点，实现系统负载均衡和最大限度的故障隔离，提供高容量，高可靠性的服务。
3.参数服务为渠道提供统一服务接口模式，伺服渠道下载需要的通道接入信息。
4.渠道通过轮询请求方式主动下载版本变化信息，初始化变化的连接池。
5.服务端进行主动控制，实时控制渠道的接入通路。
6.当某一接入点故障时，通过主动控制渠道接入点，自动切换到可以的接入点，实现故障的完全隔离。
7.对压力较大的接入点，通过主动控制，把部分数据切换到压力较小的通路，实现实现负载控制。
8.服务端为渠道维护相应标识信息和其所有当前版本和历史版本信息。
9.通过维护历史版本信息，实现版本回退功能。
实现方案：
1.整体架构图
2.3.2通信接入模块
负责和外部系统进行通讯，进行原始报文数据的传输。通信接入层实现以下功能：
1．利用系统层通讯协议和请求系统进行通讯，包括TCP/IP、HTTP、SNA、FTP、MQSeries、JMS。
2．外部系统约定的通讯方式的实现，包括如何进行通讯连接，如何进行通讯应答，如何进行数据传输，如何约定通讯报文的大小，如何确定数据传输是否完毕，如何处理通讯错误，如何关闭通讯连接，如何处理通讯层数据完整性校验等。
3．识别外部系统类型。
4多通讯连接的并发处理。
以下的功能不需要由通讯接口层完成：
1.非通讯层面的数据报文的加解密。
2. 非通讯层面的数据报文的压缩，解压缩处理。
通讯接入层屏蔽了所有的通讯细节，数据交换层只知道从某个外部系统获得了或者发送了一个数据报文，至于该数据报文是如何获得或者发送的，和数据交换层本身无关。
2.3.3请求系统适配
完成从服务端返回数据到标准输出之间的转换或从一个渠道端请求接口数据到MBSD服务标准请求数据之间的转换。具体功能包括：
1.应用层面的数据报文的加解密。
2.应用层面的数据报文的压缩，解压缩处理。
3.数据报文类型的识别。
4.数据报文的打包拆包，根据报文类型以及相关配置将数据报文拆分成统一的数据接口或者相反。
5.数据接口之间的转换，根据定义的规则从一个数据接口转换成服务数据接口或者相反。
接入适配层屏蔽了数据的具体物理表示和组织，平台服务调度层只知道收到了一个服务请求要求处理，至于该服务请求是从哪个系统发起的，原始的请求数据是什么，和服务整合层没有关系，只和数据交换层有关。
接入适配框架提供可配置的定长、变长报文转换适配器，以及可扩展的接口可以适应各种不同格式的报文转换。同时接入框架提供了MBSD元数据管理功能，能够方便的定义报文的元数据，为报文的转换以及应用的开发提供便利。
2.4集成服务功能
2.4.1服务治理
提供服务标准定义、服务封装、注册与发布等功能, 提供位置透明性的服务路由和定位服务ESB的服务接口规范应该基于对业务流程的理解，经过抽象、归纳形成，服务
接口规范独立与现有系统的具体实现，接口规范具有较强的独立性、稳定性。从而真正消除请求系统与服务系统之间的关联关系，实现服务的位置以及服务的具体实现与服务的访问过程无关。
我们提供MBSD规范落地实施的工具：元数据管理，服务接口定义配置，导入导出工具（可以通过web页面形式和导出文件形式对外公布），服务规范适配的开发框架。我们提供MBSD规范落地实施的工具：元数据管理，服务接口定义配置，导入导出工具（可以通过web页面形式和导出文件形式对外公布），服务规范适配的开发框架。
2.4.2提供对出错服务的及时检测和隔离功能
ESB系统实时检测服务系统的服务状态，当服务出现异常时，能够及时发现，通过监控平台发出报警，通过人工手段或预先设定的规则，对状态异常的服务或服务系统进行迅速隔离，避免因故障导致服务阻塞，保证请求系统对其他服务的正常访问。
2.4.3协议转换
支持外部系统通过TCP/IP、HTTP、SNA、FTP、MQSeries、JMS等协议和中间件与ESB平台通讯。
一般情况下，请求系统使用ESB系统提供的API，按照ESB系统的技术标准和服务规范进行服务访问，从而避免不必要的协议转换开销。
但是对于请求系统无法改造或改造成本过高的情况下，ESB系统应提供接入协议适配的功能，支持外部系统通过不同的通讯协议与ESB平台通讯。
区域医疗 SOA 解决方案 第 4 部分: ESB 在医疗行业中的应用 - 健康服务总线 健康服务总线是企业服务总线在医疗行业的实现，它使用 SOA 架构和医疗行业标准为基础，将医疗卫生机构的业务流程、应用系统和相关数据整合起来，提供统一的访问总线。本文给出了 IBM WebSphere Message Broker 为实现平台的参考架构，并详细介绍了与 IBM 其他产品进行集成以提供健康服务总线的相关功能。 背景介绍 区域医疗信息网络内多系统的整合 在区域医疗卫生信息网络（Regional Healthcare Information Network，RHIN）内医疗卫生机构之间共享临床与医疗健康信息的能力是当今医疗行业内面临的主要挑战之一，现有的医疗机构应用系统由于采用了不同标准、数据模型或者实现平台，在需要数据共享时候，常常根据某些特定需求实现了特定方式的连接，由于系统的异构性以及集成需求的变化和增加，这种点对点的信息交换模式越来越复杂而且难以维护，逐渐不能满足日益复杂的数据共享和交换要求，现有的系统整合和集成需要一种统一的应用架构来解决上述挑战，从而形成一个互联互通的医疗卫生业务协作网络，实现市民在各医疗机构间（例如医院与医院之间，医院与社区中心之间，社区中心与社区中心之间）的诊疗资料的共享和交换。 健康服务总线概念 在面向服务的体系架构（SOA）中，企业服务总线（Enterprise Service Bus, ESB）是一个实现系统间集成和互联互通的重要技术架构，它提供一个基于企业总线的先进应用整合理念，最大限度地减少应用系统互联所面临的复杂性，降低集成和维护成本。在区域医疗卫生信息整合环境下，构建统一的企业服务总线是实现区域医疗信息网络内多系统整合的重要实现手段，在这里，我们把企业服务总线在医疗卫生行业内特定的实现称之为健康服务总线（Health Service Bus，HSB）。健康服务总线在实现企业服务总线基本特点的同时，例如消息转换、路由、协议接入等，还需要满足医疗卫生行业内的特定需求，例如病人隐私保护、医疗卫生行业标准支持等。
关于SOA 关于SOA的概念，你可以找到很多的文章从不同的角度来描述它，不同的软件提供商也有不同的定义方式。BEA有流体计算，微软有Indigo和SOA-building，SAP有ESA。每个人都可以从不同的视角来理解SOA，从程序员的角度，SOA是一种全新的开发技术，新的组件模型，比如说Web Service；从架构设计师的角度，SOA就是一种新的设计模式，方法学；从业务分析人员的角度，SOA就是基于标准的业务应用服务。从概念的角度，IBM 对SOA的定义是最为全面的，既SOA是一种构造分布式系统的方法，它将业务应用功能以服务的形式提供给最终用户应用或其他服务。SOA包括如下要素: 一个体系架构，用开放的标准将软件资产(Asset)化为服务 提供标准的方法来表示软件资产及其交互 单独的软件资产作为构造单元，被重复使用来开发其他应用 将关注点从细节实现转移到应用(application)组装 整合企业外部的应用（B2B）的方式 开发（现在）和整合（未来）的统一 本文针对的读者是软件开发人员，站在开发人员的角度，往往希望软件开发能够满足对于开发效率、可靠性、易维护性、易管理等多方面的更高要求。让我们通过回顾软件开发的演化过程来看一看SOA出现的必然性： 面向机器语言(Monolithic)的开发模式：需要根据不同平台的机器语言来开发代码。 面向过程(Procedure)的开发模式：独立于机器的程序语言(C,Pascal等)使开发过程变得简单了，用过程来代表一个抽象的代码集合，包装重用现成的代码。 面向对象(Object)的开发模式：用更接近现实的对象来表述一个相对完整的事物。面向对象的语言(Smalltalk，Java等)，提供了更抽象的封装和重用模式。面向对象的开发强调从现实世界问题域到软件程序的直接映射，更接近人类的自然思维方式。
XXXXXX股份有限公司 ESB企业服务总线建设项目 厂商价格调查版 第二部分项目基本需求 一、公司介绍 二、信息系统概述 略
三、项目总体目标和项目实施范围 项目总体目标： 通过构建ESB企业服务总线来统一各个信息系统的服务接口协议，对全司内所有服务接口统一标准、统一管理，并且进行全局监控，从而打造信息系统之间信息交互的高速公路，以此来支持XXXX的信息化建设。 项目实施范围： 根据XXXX业务发展情况和信息系统建设情况，结合目前已知的需求范围，ESB企业服务总线将进行分阶段实施： 1、项目一期建设内容 首先按照项目总体目标构建功能齐全的ESB企业服务总线，在此基础上制定信息技术部ESB管理规范和ESB技术标准。 根据信息技术部计划，将下列软件系统的服务接口迁移到ESB企业服务总线：
项目一期建设周期，需求分析、设计开发、系统集成及联合调试的整体周期为5个月。 四、ESB企业服务总线技术需求描述 1.技术体系及基础架构 1)描述系统的体系架构，说明系统的层次结构（包括物理和逻辑）。 2)描述系统的硬件、系统软件、网络需求的估算和选型建议。 系统应使用当前主流的开源Mule ESB产品和ActiveMQ产品，系统应 具有多机集群功能，并容易实现未来扩展。系统使用的硬件应为当前主 流的硬件产品，该机型应具备升级扩充能力，以满足用户未来一定范围 内的需求变化。 3)描述系统的开发方式、开发技术、开发环境等； 4)描述系统的备份和恢复方案。 2.系统性能要求 部署在物理环境（CPU：1Core 2.2GHZ；RAM：4GB）上的ESB企业服务总线单个实例，需要满足如下性能要求： 1)并发用户数为100，PayLoad<10KB的条件下，透传业务在ESB中的平均处 理时间需要在100ms以下，CPU、RAM等系统资源使用率低于70%。 2)并发用户数为100，PayLoad<10KB的条件下，对于需要进行协议数据转换 业务在ESB中的平均处理时间需要在1s以下，CPU、RAM等系统资源使用 率需要低于70%。
企业服务总线系统(ESB) 技术白皮书 [V1.0.1115] 厦门博立特有限公司 版权所有 保留所有权利 目录 1.前言 4 2 .ESB简介 4 3. ESB主要功能和特点 6 3.1.ESB主要功能： 6 3.1.ESB主要特点： 7 4.ESB接口设计 8 4.1 总体设计框图 8 4.2 技术规范 8 4.3 消息传输流程 8 4.4 文件传输流程 8
4.5 MsgService接口说明 8 4.5.1 登陆到ESB(Login) 8 4.5.1.1 服务.NET原型 8 4.5.1.2 传入参数 9 4.5.1.3 返回参数 9 4.5.1.4 服务说明 9 4.5.2 发送消息到ESB(SendMessage) 9 4.5.2.1 服务.NET原型 9 4.5.2.2 传入参数 10 4.5.2.3 返回参数 10 4.5.2.4 服务说明 10 4.5.3 从ESB接收消息(ReceiveMessage) 10 4.5.3.1 服务.NET原型 10 4.5.3.2 传入参数 11 4.5.3.3 返回参数 11 4.5.3.4 服务说明 11 4.5.4 发送确认消息到ESB(AcknowledgeMessage) 11
4.5.4.1 服务.NET原型 11 4.5.4.2 传入参数 11 4.5.4.3 返回参数 12 4.5.4.4 服务说明 12 5.附录A 返回代码对照表 12 1.前言 随着信息技术的不断发展，企业、政府部门等在信息化建设上投入了大量的资金、人力，逐步形成了适合自身某些部门或某些业务需要的管理信息系统，如办公自动化、客户关系管理CRM、企业资源计划ERP、生产制造系统等，这些管理信息系统，在企业和政府某些部门或业务的管理上，发挥了信息电子化、流程自动化、管理科学化的重要作用。 但是，企业和政府现有的管理信息系统，由于投入的时间、使用的部门、生产的厂家及实现技术等各不相同，造成企业和政府现有的应用信息系统各自独立运行，数据不能共享，各自业务流程不能自动衔接，造成企业和政府内部许多自成体系的信息化孤岛，各个应用系统不能相互协作，形成统一高效的有机整体。 企业应用集成，英文名称为Enterprise Application Integration，简称EAI，是为了解决企业和政府现有多种应用系统不能互连互通、数据共享、业务流程协调统一的问题，将异构的两个或更多的硬件、平台及应用系统进行无缝集成，使它们形成一个统一的整体。
企业服务总线ESB项目供应商征集要求 一、项目名称 企业服务总线ESB项目 二、项目背景 随着我行经营战略的实施，经营管理改革不断深化，业务规模不断壮大，产品种类不断增多，对应的支撑信息系统也在不断增加，目前已达到了一百多个，且系统与系统之间的交互也越来越多，如何高效的实现这一百多个系统之间的互联互通互用，从而形成一个有机的整体，就成了我行当前面临的一个新问题，这个问题需要在科技层面引入一种先进的架构来解决。 面向服务的SOA架构思想是当前IT架构发展的主流，SOA 是一种面向服务的分布式应用体系架构，它将各应用程序的业务功能定义为服务，并按松耦合方式组合服务形成业务功能或业务流程。通过SOA架构建设，可极大的提升整体系统对业务发展变化响应的敏捷性和灵活性。企业服务总线（简称ESB：Enterprise Service Bus）是企业SOA架构落地的最佳实践，是实施SOA的切入点。通过ESB项目建设，可建立起多层次、条线化、松耦合的IT应用架构，简化了接口和交易环节，架构更加清晰，从而能更有效支撑我行未来的业务发展战略。
三、项目要求 本系统的建设目标为建立起一个灵活的、高效的、稳定的全行总线系统，实现我行异构系统的互联互通互用，实现我行统一服务视图和统一服务监控。建设该系统，具体需达到以下要求： 1.建立起松耦合的、灵活、稳定的面向服务的SOA 系统架构,高效解决我 行异构系统间互联互通互用问题。 2.制定起我行统一的银行服务规范和技术规范，搭建一套服务治理平台， 梳理我行服务，实现服务全生命周期管理，形成我行的统一服务视图，以支持快速地构建新业务和新产品。 3.提升我行系统整体效率，通过引入流量控制和故障隔离机制，增强系统 整体健壮性。 4.通过对各系统的服务运行情况监测及分析，实现对全行系统的有效监控。
企业服务总线ESB方案书
1需求综述 (4) 1.1主数据平台接口 (4) 1.2业务数据接口 (4) 1.3OA系统接口： (5) 1.4国家法定信息发布媒体： (5) 2系统解决方案 (5) 2.1系统技术架构 (5) 2.1.1运行平台 (6) 2.1.2开发平台 (6) 2.1.3监控平台 (7) 2.1.4公共服务 (7) 2.1.5适配器 (7) 2.2部署方案 (9) 2.2.1管理监控部分部署方案 (9) 2.2.2硬件选型建议 (10) 2.2.3逻辑分区部署方案 (11) 2.2.4硬件配置建议 (11) 2.2.5服务接口规范 (12) 2.2.6高性能、高可用性及扩展能力设计 (12) 2.2.7完善的安全机制 (13) 2.3整体解决方案 (15) 2.3.1接入控制 (16) 2.3.2通信接入模块 (17) 2.3.3请求系统适配 (18) 2.4集成服务功能 (19) 2.4.1服务治理 (19) 2.4.2提供对出错服务的及时检测和隔离功能 (20) 2.4.3协议转换 (20) 2.4.4消息格式转换 (21) 2.4.5服务路由 (22) 2.4.6监控和运维 (22) 2.4.7服务等级 (23) 2.5系统非功能需求 (24) 2.5.1可用性 (24) 2.5.2可扩展性 (24) 2.5.3可维护性 (25)
2.5.4安全性 (25) 2.5.5性能需求 (25) 2.6公用服务 (26) 2.6.1流量控制 (26) 2.6.2故障隔离 (26) 2.6.3统一流水号 (27) 2.6.4日志记录 (27) 2.7管理监控 (27) 2.7.1系统平台级监控 (27) 2.7.2应用级监控 (27) 2.7.3统计分析 (27) 2.7.4异常报警 (28) 2.7.5统一的运维管理 (28) 3技术支持与服务方案 (28) 3.1技术支持与售后服务体系 (29) 3.2服务管理模式 (29) 3.3服务响应 (30) 3.3.1问题优先级（或问题严重程度）级定义 (30) 3.3.2服务响应时间 (31) 3.3.3问题解决时间 (33) 3.3.4服务文档 (34) 3.4维护支持服务流程 (35) 3.4.1服务消息创建流程 (35) 3.4.2问题处理流程 (35) 3.4.3服务确认流程 (36) 3.4.4投诉及问题升级流程 (37)
企业服务总线系统(ESB) 技术白皮书 [V1.0.1115] 厦门博立特有限公司 版权所有 保留所有权利
目录 1.前言 (4) 2 .ESB简介 (4) 3. ESB主要功能和特点 (6) 3.1.ESB主要功能： (6) 3.1.ESB主要特点： (7) 4.ESB接口设计 (8) 4.1 总体设计框图 (8) 4.2 技术规范 (8) 4.3 消息传输流程 (8) 4.4 文件传输流程 (8) 4.5 MsgService接口说明 (8) 4.5.1 登陆到ESB(Login) (8) 4.5.1.1 服务.NET原型 (8) 4.5.1.2 传入参数 (9) 4.5.1.3 返回参数 (9) 4.5.1.4 服务说明 (9) 4.5.2 发送消息到ESB(SendMessage) (10) 4.5.2.1 服务.NET原型 (10) 4.5.2.2 传入参数 (10) 4.5.2.3 返回参数 (10) 4.5.2.4 服务说明 (10) 4.5.3 从ESB接收消息(ReceiveMessage) (11) 4.5.3.1 服务.NET原型 (11) 4.5.3.2 传入参数 (11) 4.5.3.3 返回参数 (11) 4.5.3.4 服务说明 (11) 4.5.4 发送确认消息到ESB(AcknowledgeMessage) (12) 4.5.4.1 服务.NET原型 (12)
4.5.4.2 传入参数 (12) 4.5.4.3 返回参数 (12) 4.5.4.4 服务说明 (12) 5.附录A 返回代码对照表 (13)
1.前言 随着信息技术的不断发展，企业、政府部门等在信息化建设上投入了大量的资金、人力，逐步形成了适合自身某些部门或某些业务需要的管理信息系统，如办公自动化、客户关系管理CRM、企业资源计划ERP、生产制造系统等，这些管理信息系统，在企业和政府某些部门或业务的管理上，发挥了信息电子化、流程自动化、管理科学化的重要作用。 但是，企业和政府现有的管理信息系统，由于投入的时间、使用的部门、生产的厂家及实现技术等各不相同，造成企业和政府现有的应用信息系统各自独立运行，数据不能共享，各自业务流程不能自动衔接，造成企业和政府内部许多自成体系的信息化孤岛，各个应用系统不能相互协作，形成统一高效的有机整体。 企业应用集成，英文名称为Enterprise Application Integration，简称EAI，是为了解决企业和政府现有多种应用系统不能互连互通、数据共享、业务流程协调统一的问题，将异构的两个或更多的硬件、平台及应用系统进行无缝集成，使它们形成一个统一的整体。 企业服务总线（Enterprise Service Bus，缩写ESB），是面向服务架构的骨干，在完成服务的接入，服务间的通信和交互基础上，还提供安全性、可靠性、高性能的服务能力保障。采用SOA架构，基于ESB总线进行企业应用集成，应用系统之间的交互通过总线进行，这样可以降低应用系统、各个组件及相关技术的耦合度，消除应用系统点对点集成瓶颈，降低集成开发难度，提高复用，增进系统开发和运行效率，便于业务系统灵活重构，快速适应业务及流程变化需要。 2 .ESB简介 ESB作为博立特科技公司的企业应用集成产品，主要功能是在两个或更多的异构系统（如不同的数据库、消息中间件、ERP或CRM等）之间进行资源整合，实现互连互通、数据共享、业务流程协调统一等功能，构建灵活可扩展的分布式企业应用。
企业服务总线ESB方案书 1需求综述 (3) 1.1主数据平台接口 (3) 1.2业务数据接口 (3) 1.3OA系统接口： (4) 1.4国家法定信息发布媒体： (4) 2系统解决方案 (5) 2.1系统技术架构 (5) 2.1.1运行平台 (5) 2.1.2开发平台 (6) 2.1.3监控平台 (6)
2.1.5适配器 (6) 2.2部署方案 (7) 2.2.1管理监控部分部署方案 (7) 2.2.2硬件选型建议 (8) 2.2.3逻辑分区部署方案 (9) 2.2.4硬件配置建议 (9) 2.2.5服务接口规范 (10) 2.2.6高性能、高可用性及扩展能力设计 (10) 2.2.7完善的安全机制 (11) 2.3整体解决方案 (12) 2.3.1接入控制 (12) 2.3.2通信接入模块 (13) 2.3.3请求系统适配 (14) 2.4集成服务功能 (15) 2.4.1服务治理 (15) 2.4.2提供对出错服务的及时检测和隔离功能 (15) 2.4.3协议转换 (15) 2.4.4消息格式转换 (16) 2.4.5服务路由 (16) 2.4.6监控和运维 (16) 2.4.7服务等级 (17) 2.5系统非功能需求 (17) 2.5.1可用性 (17) 2.5.2可扩展性 (17) 2.5.3可维护性 (18) 2.5.4安全性 (18) 2.5.5性能需求 (18) 2.6公用服务 (18) 2.6.1流量控制 (18) 2.6.2故障隔离 (19) 2.6.3统一流水号 (19) 2.6.4日志记录 (19) 2.7管理监控 (19) 2.7.1系统平台级监控 (19) 2.7.2应用级监控 (19) 2.7.3统计分析 (19) 2.7.4异常报警 (20)
谈及企业服务总线（ESB），在有面向服务的架构（SOA）实施经验的开发者眼中一定不会陌生。这些年，人们一直在谈论它，以至有些人认为“实施SOA一定需要ESB”，或“只要将ESB架起来了，我们就SOA了”。这些说法有可取之处，也存在片面之嫌，由于业界对于ESB没有统一、标准的定义，所以一千个人眼中有一千个“ESB”也就成了情理中的事情了。然而，怎么才能将ESB 用好？我们需要清楚地认识ESB在SOA中所扮演的角色，理解哪些工作是ESB的职责之内，哪些却不是。只有正确地认识了ESB的职能，并委以恰当的任务，才能将它用在刀刃上、发挥其巨大的能量。 事实上，ESB在SOA中扮演着重要的角色，在技术层解决了SOA的整合问题，耦合了应用与应用之间的集成逻辑，使得SOA更灵活，更易于扩展，更敏捷。有了ESB，新建的服务消费者应用程序不需要关心服务的提供者在哪里，使用何种通讯协议，与其交互的数据是怎样的……，它只需向ESB发出请求，使用开放的、标准的通讯协议。相反，若某个可重用的价值较大的服务位于某一个遗留系统中，而由于种种原因，该遗留系统不能在短期内重写，此时ESB可以架起该服务与其使用者之间沟通的桥梁。当然，ESB的作用远不止这些，业内也有很多讨论，本文不再赘述。读者可在Google上搜索ESB Patterns获得相关资料。 然而，ESB并非“救世主”，它注定也不可能解决应用系统整合中出现的所有问题。道理很简单，计算机发展历史长从没有出现过一个产品/工具可以满足所有的应用需求，技术发展得很快，需求发展更快，所以技术永远跟不上需求。此外，ESB或ESB产品有其特定的适用范围，它是基础设施层的概念/产品，解决的是整合中的常见问题，比如服务连通、路由、消息丰富、服务的注册/查找/发布等服务的管理、服务监控和质量保证等。ESB不能解决的问题比其能解决的问题多很多。比如，让它去做人工流程的编排是不合适的，让它提供门户类产品那样的用户交互也是极其困难的……。 笔者支持过许多客户项目。在这些项目中，有的客户将ESB用的好，有的则勉强用上，用的功能很简单，有的则用ESB做一些原本不属于它该做的工作。在这里，笔者仅从个人的立场，分享自己这些年来积累的ESB实施经验。下面列出笔者常看到但不推荐的实施和笔者在实施ESB 的过程中积累的一些较好的实践方式，供读者参考。同时欢迎批评指正。 不推荐实施 挟ESB以令外围应用 ?现象： ESB的架构师在ESB上设计一套标准的数据接口（通用的XML格式），规定使用统一 的协议（如Web Service/HTTP）。所有的ESB服务消费者和接入ESB的服务必须符合该标准。其目的是为了简化ESB上的开发工作。这就是一种“挟天子以令诸侯”的做法，因为在实际情况中，可能领导规定了“所有的服务必须要经过ESB，即便是透传”。 ?分析： 国内的ESB实施者大多数是一些SI/ISV，出于成本/人力或其他个方面的原因，总会有 一些架构师希望达成这样一个目标：我能否设计/实现一个一劳永逸的ESB中间平台， 将来不论哪种服务都可以方便地接入到ESB上？
ESB（Enterprise Service Bus，即企业服务总线）是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。 企业服务总线ESB就是一种可以提供可靠的、有保证的消息技术的最新方法。ESB中间件产品利用的是Web服务标准和与公认的可靠消息MOM协议接口(例如IBM的WebSphere MQ、Tibco的Rendezvous 和Sonic Software的SoniCMQ)。ESB产品的共有特性包括:连接异构的MOM、利用Web服务描述语言接口封装MOM协议，以及在MOM传输层上传送简单对象应用协议(SOAP)传输流的能力。大多数ESB产品支持在分布式应用之间通过中间层如集成代理实现直接对等沟通。 企业服务总线（Enterprise Service Bus，ESB）的概念是从面向服务体系架构(Service -Oriented Architecture，SOA)发展而来的。SOA描述了一种IT基础设施的应用集成模型，其中的软构件集是以一种定义清晰的层次化结构相互耦合，其中，一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。 一、ESB的出现改变了传统的软件架构 ESB 是传统中间件技术与XML、Web服务等技术相互结合的产物，ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。 二、企业服务总线（ESB）的用处 ESB 不是万能的,他不是一个应用程序框架,也不是一个企业应用的解决方案.它只是一个基于消息的调用企业服务的通信模块!你可以把它嵌入到你的应用程序框架中,例如嵌入到spring容器里面,或者嵌入到工作流系统中.它的作用是对企业里面的SOA服务的调用提供一个框架和简便的方法. 三、企业服务总线（ESB）的应用特征 大规模分布式的企业应用需要相对简单而实用的中间件技术来简化和统一越来越复杂、繁琐的企业级信息系统平台。面向服务体系架构（SOA）是能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。SOA使用户可以不受限制地重复使用软件、把各种资源互连起来，只要IT人员选用标准接口包装旧的应用程序、把新的应用程序构建成服务，那么其他应用系统就可以很方便的使用这些功能服务。 支撑SOA的关键是其消息传递架构-企业服务总线（ESB）。ESB是传统中间件技术与XML、Web服务等技术相互结合的产物，用于实现企业应用不同消息和信息的准确、高效和安全传递。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务协调运作，实现不同服务之间的通信与整合。ESB在不同领域具有非常广泛的用途: 电信领域：ESB能够在全方位支持电信行业OSS的应用整合概念。是理想的电信级应用软件承载平台。电力领域：ESB能够在全方位支持电力行业EMS的数据整合概念，是理想的SCADA系统数据交换平台。金融领域：ESB能够在全方位支持银企间业务处理平台的流程整合概念，是理想的B2B交易支撑平台。电子政务：ESB能够在全方位支持电子政务应用软件业务基础平台、信息共享交换平台、决策分析支撑平台和政务门户的平台化实现。 四、几种ESB的结构和功能 ESB提供了一种开放的、基于标准的消息机制，通过简单的标准适配器和接口，来完成粗粒度应用（服务）和其他组件之间的互操作，能够满足大型异构企业环境的集成需求。它可以在不改变现有基础结构的情况下让几代技术实现互操作。 通过使用ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口，并能够在部署环境中支持任何标准。更重要的是，充当“缓冲器”的ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使得不同的应用程序可以同时使用同一服务，用不着在应用程序或者数据发生变化时，改动服务代码。 1. IBM WebSphere ESB IBM 提供了三种ESB 产品：IBM WebSphere ESB、IBM WebSphere Message Broker、IBM WebSphere DataPower Integration Appliance XI50。根据您的需求选择ESB 来增强您的SOA。WebSphere ESB 是一种基于平台的ESB，作为集成的SOA 平台，针对WebSphere 应用服务器进行了优化。WebSphere Message Broker 是跨平台的ESB，是为异构IT 环境中的统一连接和转换而构建的。WebSphere DataPower
企业服务总线消息框架. Mule 1Mule简介 Mule是一个轻量级的基于Java的ESB消息框架，它允许用户快捷地连接多个应用并且在这些应用之间交换数据。Mule使用了SOA的体系结构思想，可以方便的集成已有的应用。它是可升级的、高分布式的对象代理，可以通过异步传输消息技术来无缝的处理服务与应用之间的交互。 Mule框架提供了一个可升级的环境，可以把自己的业务组件部署在里面。Mule管理所有组件之间的交互，不管它们是在同一个虚拟机中还是在internet上，也不管底层使用的传输方式。 Mule围绕着企业服务总线（ESB）架构进行设计，保证了不同的组件或者应用可以通过公共的消息总线进行交互，公共的消息总线一般是由JMS或者其他消息服务器来实现。 在应用中会使用不同的技术，包括JMS,Web Services，JDBC，HTTP等等，Mule可以很好地处理他们之间的交互。 2Mule快速入门
2.1Mule特性 Mule是一个企业服务总线(ESB)消息框架.它的主要特性包括: 1.基于J2EE1.4的企业消息总线(ESB)和消息代理(broker). 2.可插入的连接性:比如Jms,jdbc,tcp,udp,multicast,http,servlet,smtp,pop3, file,xmpp等. 3.支持任何传输之上的异步，同步和请求响应事件处理机制. 4.支持Axis或者Glue的Web Service. 5.灵活的部署结构[Topologies]包括Client/Server, P2P, ESB 和Enterprise Service Network. 6.与Spring 框架集成:可用作ESB 容器，也可以很容易的嵌入到Spring应用中. 7.使用基于SEDA处理模型的高度可伸缩的企业服务器. 8.强大的基于EIP模式的事件路由机制等. 2.1.1产品简介 Mule ESB 是一个轻量级的基于java的企业服务总线和集成平台，使得开发人员可以快速，简单的连接多个应用，使得它们可以交换数据。 Mule ESB 容易集成现有异构系统，包括：JMS, Web Services, JDBC, HTTP, 等. ESB的关键特性是允许不同的应用通讯，其作为运输系统在企业内或Internet应用间搬运数据。 Mule ESB 包含如下强大的能力： ?服务创建和托管—暴露和托管可重用服务，使用Mule ESB作为一个轻量级服 务容器； ?服务调解— shield services from message formats and protocols, separate ； business logic from messaging, and enable location-independent service calls ； ?消息路由—路由, 过滤, 聚合, 基于内容和规则对消息re-sequence； ?数据转换—通过一些格式和传输协议交换数据。