基于ESB 企业信息化系统改造的研究

过 怡

（苏州市职业大学 计算机工程学院， 江苏 苏州215104）

0 引 言

ESB（企业服务总线的简称），作为一种低耦合的服务和应用之间的集成方式，用于集成应用程序和服务的灵活连接基础设施，是当今先进的企业应用整合方案。 ESB 作为SOA（面向服务）架构的信息传输龙骨，通过减少应用程序和服务之间的接口数量、大小和复杂性来简化IT 架构，降低运作成本，实现系统之间、部门之间、不同厂商之间的应用集成，从而降低了企业应用集成的难度和成本，提升了业务灵活性和市场响应速度，最终提升了企业的竞争优势［1-2］。

近年来，ESB 技术在系统架构设计中得到了广泛的应用，尤其在新系统的实施过程中，通过自上而下的系统规划使得后台服务开发标准化、服务监控规范化、服务配置管理统一，保证了数据的一致性、实时性和安全性，降低了IT 整体管理成本，内部数据得到了整合，提高了系统的灵活度和快速响应能力［3］。

然而，对于企业而言，随着业务发展和规模扩大，原有的信息系统建设存在着明显的局限性，保障业务运行的大量存量信息化系统，没有ESB 架构，有着独立的数据库平台、以及海量的业务数据，存在着信息孤岛，无法实现信息共享和资源整合［4］。

因此，对企业信息化系统通过ESB 架构进行系统改造，实现系统解耦，完成能力封装，降低维护成本，提升服务扩展能力。

1 企业信息化系统ESB 架构改造

以某上市企业的ESB 项目为例，在实施之前，企业的信息化系统架构中存在大量点对点的系统接口和数据流，如图1 所示。

图1 ESB 项目前的信息化系统架构Fig. 1 IT System Architecture Before ESB Project

实施策略：导入合适的ESB 产品，在ESB 产品的基础上，搭建企业ESB 平台，将主数据和业务数据逐步分批开发接口，并注册发布在该平台，按优先级逐步改造存量信息化系统的数据调用方式，逐步实现对公司数据流和接口的整体管理监控，减少系统之间的耦合，如图2 所示。

图2 ESB 项目后的信息化系统架构Fig. 2 IT System Architecture After ESB Project

2 企业信息化系统ESB 架构改造过程

2.1 ESB 系统产品选型

企业在ESB 项目选型过程中，试用过很多产品，最终选择IIB（IBM Integrated Bus）搭建企业服务总线平台。 IIB 有大量的国内外企业客户，具有完善的功能，包括支持多种协议（CICS， IMS， CORBA，SAP， JDEdwards...）、传输（MQ， HTTP（S）， SOAP，REST， FTP， TCP／IP...）和数据格式（Binary， XML，csv， JSON， IDOCs， 自定义），各种消息处理的能力（路由、过滤、转换、监测、发布、分解、序列、关联、检测）强大，图形化的编程方式（通过图形数据流描述应用和服务之间的连接，通过图形映射，Java，XSL ＆WTX 来定义逻辑），垂直和水平的扩展能力。 支持集成现有系统而无需考虑其底层采用何种技术。

2.2 ESB 系统技术框架

企业根据业务系统的实际情况，结合信息系统规划和行业最佳实践，设计了ESB 系统架构，如图3所示。

图3 ESB 系统架构图Fig. 3 ESB System Architecture

其中，系统架构的软硬件清单如表1 所示。

2.3 ESB 接口设计总体原则

（1）ESB 系统应用集成的范围。 ESB 系统主要用于企业不同业务领域的业务系统之间的应用集成，数据库层面的数据共享需求，无数据共享需求则不属于ESB 服务集成的服务接口。

表1 ESB 系统软硬件清单Tab. 1 Hardware ＆ Software List of ESB System

（2）ESB 集成的接入方式。 平台允许接入的协议包括：HTTP API／Restful、WebService、JMS／MQ、FTP、RFC、IDOC。 如果有特殊需求可以接入邮件服务器、LDAP、文件等服务，优先使用HTTP API 传输协议方式。

（3）满足企业内和企业间的数据传输要求。ESB 被设计成可以满足企业内各个系统间数据交换的服务总线，也可以满足上下游企业间系统数据交换的服务网关。

（4）服务虚拟化。 ESB 服务请求方不需要关心服务提供方在哪，当前的状态是什么，只需要提交自己的数据到ESB 总线，ESB 负责将消息送达到指定的服务提供方，并在服务处理完毕后将结果返回到服务请求方。 实现了后端SOA 生态环境的服务虚拟化，构建了一个基于SOA 服务的私有云。

（5）数据传输的可靠性。 保证不同系统间数据传输的可靠性是企业级数据集成需要实现的首要目标。 在ESB 核心交换层，使用MQ／JMS 和基于HTTP 的Web Service 和Restful 协议，使用双节点部署部署IIB 核心节点，运行在ESB 内的消息流可以被逻辑隔离，最大限度避免由于ESB 单点故障导致的系统数据交换问题。

（6）跨平台兼容性。 使用XML／JSON 消息格式，满足跨系统跨平台的兼容性要求，采用UTF-8编码的XML／JSON 格式作为消息封装标准。 服务调用方和接收方根据业务需求约定XML／JSON 内封装的数据内容。

（7）消息的大小。 ESB 被设计成为快速吞吐数据的数据总线，在可能的情况下，应该将消息拆解为单个消息比较小的大批量数据。 考虑到性能因素。规定使用Web Service／HTTP API 接入方式的报文大小控制在4 MB 以内；MQ／JMS 接入方式的报文大小控制在10 MB 以内；如果需要传送较大的报文，需将报文拆分，使用多次服务交互和发送；FTP 和MQ 分段报文大小控制在16 M 以内。

2.4 ESB 系统编码规范

（1）接入系统规范。 ESB 平台定义了各个请求方的系统代码，编码ID 为定长3 字节，内部系统从0 开始编码，外部系统从9 开始编码。 新系统接入前，需要向ESB 系统管理员申请系统编码。 编码样例如表2 所示。

表2 ESB 接入系统编码样例Tab. 2 NamingCode Sample of Connected System

（2）服务编码。 通过对服务的统一梳理，将每个服务统一分配一个唯一编号，另外每个服务对应的serviceName 也是唯一的，两者都可以用来标示一个唯一的服务，例如serviceName 用在报文头中标示需要访问的服务。 服务编码示例如表3 所示。

表3 ESB 系统服务编码样例Tab. 3 NamingCode Sample of ESB System Service

（3）响应码编码。 响应代码用于消息响应XML／JSON 数据的EsbCode 字段。 响应代码遵循编码格式为6 位等值数字或等值字符串，由各个接入系统自行定义内部响应码编码规则：SSS NNN。 其中：

SSS：系统编码，具体参考表2。

NNN：各系统内部响应码，000～999；000 表示操作成功。 一般而言，0XX 代表操作成功；4XX 代表资源请求失败或安全相关异常；5XX 代表服务器处理异常。

ESB 平台响应码样例如表4 所示，可以进行扩展。

表4 ESB 平台响应编码样例Tab. 4 Response Code Sample of ESB System

3 结束语

本文建立了ESB 平台，针对企业特性，从系统耦合程度最高的订单系统开始ESB 接口开发，完成了主数据和订单业务的ESB 接口开发，包括客户主数据，产品主数据，价格主数据，库存信息，客户信贷，销售订单，交货单，订单规则类信息等31 个ESB接口的开发和应用，形成了以ERP 系统为核心，将订单系统的主数据和和核心业务数据发布到ESB平台，订单系统订阅ESB 服务的低耦合数据交互模式，为后续ESB 平台的持续建设建立了规范，有效地改进了信息化系统架构，为系统能力提升打下了良好的基础。