航空發動機行業企業服務總線設計方案

王洋 沈陽發動機研究所

引言

當前，企業信息化的程度越來越深，內部針對不同專業領域的系統也越來越多。單純的從企業內部的工作方式來看，企業高度依賴各種專業的應用系統。

企業門戶本質上就是系統集成，但由于門戶的需求一般都是在使用業務的層面上提出，所以其注意力在視圖展示層面。門戶的架構也更注重于單點登錄和商務智能等方面。為實現這些功能，底層的集成方式一般都是采用點對點的方式與相關系統聯接。這種底層集成方式還處于非常原始的狀態，談不上“架構”，有很多缺點。雖然視圖展現層面很靈活，但要修改集成結構或是容納更多的應用系統，集成的工作量一定與修改或集成系統的數量成正比。且開發過程中復雜的集成問題使開發者不能太關注業務。

企業的基礎結構實際上解決的是集成的問題，所以自然而然的采用了面向服務的架構（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 之路的實現形式。按照自身需求并合理的安排并設計集成方案，才能適合本企業的狀況，節省成本，使企業應用集成更具備可行性。