航空发动机行业企业服务总线设计方案

王洋 沈阳发动机研究所

引言

当前，企业信息化的程度越来越深，内部针对不同专业领域的系统也越来越多。单纯的从企业内部的工作方式来看，企业高度依赖各种专业的应用系统。

企业门户本质上就是系统集成，但由于门户的需求一般都是在使用业务的层面上提出，所以其注意力在视图展示层面。门户的架构也更注重于单点登录和商务智能等方面。为实现这些功能，底层的集成方式一般都是采用点对点的方式与相关系统联接。这种底层集成方式还处于非常原始的状态，谈不上“架构”，有很多缺点。虽然视图展现层面很灵活，但要修改集成结构或是容纳更多的应用系统，集成的工作量一定与修改或集成系统的数量成正比。且开发过程中复杂的集成问题使开发者不能太关注业务。

企业的基础结构实际上解决的是集成的问题，所以自然而然的采用了面向服务的架构（SOA）作为解决方案。而在集成的细节上，SOA 的典型基础结构——企业服务总线（ESB）就成了解决底层集成问题的首要手段。

1 企业服务总线（ESB）技术

1.1 企业服务总线的概念

企业服务总线（Enterprise Service Bus， ESB）是由SOA 的概念发展而来的，它是SOA 的一种典型的实现方式，支撑SOA 底层的信息传输和集成适配，是整个架构中最基本的联接中枢。就像工厂的总线系统一样，所有接入的应用系统都只和总线联接，彼此间无复杂耦合。

1.2 企业服务总线的应用状况

目前，企业服务总线作为中间件，有很多厂商提供商业化的解决方案。在我国国内最近两年就出现好多成熟的总线产品。国际上，IBM 的总线产品IBM Web Sphere Message Broker(MB)就是一款应用广泛的总线中间件产品。除了商业化的总线解决方案，近两年开源的总线中间件也逐渐成熟起来。

由于ESB 目前还缺乏规范和标准的原因，开源的总线中间件在使用上不是很方便。各开源产品都试图自己建立规范。规范意味着统一，意味着可以通过配置来简化使用。所以大多数开源总线过于依赖非标准配置和自己提供的开发环境，操作使用方便的同时又导致扩展的不便和使用的繁琐

1.3 在门户的底层架构中使用企业服务总线

流程和待办都需要从各个业务系统中抽取相应功能来完成。当这些功能以SOA 的思想封装成服务并在总线上流动时候，还可以使用流程引擎对其进行重新编排整理形成新的服务以适应新业务要求。流程抽取，待办等需求只是比较简单的数据流动，数据路由的要求不高。

综上所述，在开源产品和商业产品在某些条件下都不甚理想的状况下。企业可以尝试自己针对自己的业务和应用特点设计自己的企业服务总线。这样，设计企业服务总线的核心功能并适配以简单的、少量的协议联接满足自身要求即可，在成本上非常合算。后续的扩展工作也好展开。本文下面就力求设计一个简单的，只满足自身需要的ESB 方案。

2 总线的设计

2.1 架构设计

在架构设计中，异构的应用通过适配器接入该总线，门户也直接接入总线。总线中的接入适配器有多种传输协议可供选择。信息通过接入适配器后，经过数据解析后找到数据传输目标（服务地址）。然后再路由到目的地。同时，如果信息是异步的，则借助消息服务器代理转发。在这种架构中，不用区分服务消费者和服务提供者。同一种接入方式都可实现服务提供和消费的功能。

总线中也集成流程引擎，可以将总线中的服务编排成新流程功能服务使用。

2.2 具体实现方式

为了实现消息的跨业务的异步通信，总线中必须集成消息服务器。按照java 平台标准，即选择采用JMS（Java Messaging Service）服务器。

总线这个中间件的“壳”可使用开源的应用服务器，考虑到这个中间件要集成JMS，则一定要选择Java EE 服务器。同时考虑到集成开源的Java 平台标准流程引擎JBPM，设计中选用JBOSS 产品。该产品包含了消息服务器和JBPM 流程引擎。

数据解析模块涉及到统一数据模型，统一数据模型采取XML方式，因为在SOA 化的组织结构中，XML 已经成为了数据表示和数据交换的事实标准。

总线中服务的注册模块采取UDDI 的方式进行，该方式将Web服务管理起来，利用Web 服务技术实现控制服务接口，使用Web 服务描述语言（WSDL）定义服务，再采用服务组件技术SCA(Service Component Architecture)将服务组封装，可快速、有效地实现企业服务总线。通过配置需要提供服务的WSDL 输入输出文件的XML Schema 即可分析和检查结果。

2.3 应用集成设计

在框架中，集成采取了适配器的方式联接总线，因为接入系统都是异构的或是跨平台的，所以必须采用多种协议和适配器的方式联接总线。

考虑到总线集成的跨平台性，Web Service协议的提供是必须的，由于其跨平台性Web Service 和XML 现在几乎是SOA 和ESB 的唯一被认可的事实标准。甚至企业服务总线有这样的定义：（ESB）是传统中间件技术与可扩展标记语言（XML），Web Service 等技术结合的产物。

为了集成历史遗留的其它系统，在“其他协议”中设计了以TCP/IP 的方式直接传输来解决这些系统的跨平台联接问题。在C/S 架构的应用系统中，基于java 平台的系统还是占优势的，所以要提供RMI 的访问方式解决java 系统间传输（直接调用）的问题。

3 问题和总结

此方案的优点：

提供了一个简单的企业服务总线的设计方案，该方案可实现了企业服务总线的基本功能。中间件和流程引擎、JMS 服务器都采用开源产品，成本较低，实现方案的门槛不高。适合一般企业的初级使用。如果企业以简单应用开始构建SOA。按照该方案自主开发，则以后的扩展性会有优势。

缺点和待改进之处：

（1）功能少，只完成了核心功能。应用时可根据自身情况丰富功能。如安全控制和监控，日志等管理功能。也可扩充通信协议和联接方式。

（2）消息服务器跨业务不跨平台。也是由于消息服务器没有标准和规范的问题，目前提出标准消息服务器JMS 只能在Java 平台使用。非Java 平台无法使用该消息服务，目前在开源范围没有好的解决方案。如有条件将JMS Server 替换成商业软件IBM Web Sphere Message Queue(MQ)则可解决消息服务器的跨平台问题。

4 结论

企业应用的“数据孤岛”的问题已经是企业信息化过程面临的一个瓶颈。OA 的具体实现形式一定是因地制宜而不是依赖于标准的（实际上也没有标准），无论是EAI 还是ESB，无论是一个健壮的ESB还是经过剪裁并本地化的ESB，都是通向SOA 之路的实现形式。按照自身需求并合理的安排并设计集成方案，才能适合本企业的状况，节省成本，使企业应用集成更具备可行性。