王洋 沈陽發(fā)動機研究所

引言

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

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

企業(yè)的基礎結構實際上解決的是集成的問題，所以自然而然的采用了面向服務的架構（SOA）作為解決方案。而在集成的細節(jié)上，SOA 的典型基礎結構——企業(yè)服務總線（ESB）就成了解決底層集成問題的首要手段。

1 企業(yè)服務總線（ESB）技術

1.1 企業(yè)服務總線的概念

企業(yè)服務總線（Enterprise Service Bus， ESB）是由SOA 的概念發(fā)展而來的，它是SOA 的一種典型的實現(xiàn)方式，支撐SOA 底層的信息傳輸和集成適配，是整個架構中最基本的聯(lián)接中樞。就像工廠的總線系統(tǒng)一樣，所有接入的應用系統(tǒng)都只和總線聯(lián)接，彼此間無復雜耦合。

1.2 企業(yè)服務總線的應用狀況

目前，企業(yè)服務總線作為中間件，有很多廠商提供商業(yè)化的解決方案。在我國國內最近兩年就出現(xiàn)好多成熟的總線產(chǎn)品。國際上，IBM 的總線產(chǎn)品IBM Web Sphere Message Broker(MB)就是一款應用廣泛的總線中間件產(chǎn)品。除了商業(yè)化的總線解決方案，近兩年開源的總線中間件也逐漸成熟起來。

由于ESB 目前還缺乏規(guī)范和標準的原因，開源的總線中間件在使用上不是很方便。各開源產(chǎn)品都試圖自己建立規(guī)范。規(guī)范意味著統(tǒng)一，意味著可以通過配置來簡化使用。所以大多數(shù)開源總線過于依賴非標準配置和自己提供的開發(fā)環(huán)境，操作使用方便的同時又導致擴展的不便和使用的繁瑣

1.3 在門戶的底層架構中使用企業(yè)服務總線

流程和待辦都需要從各個業(yè)務系統(tǒng)中抽取相應功能來完成。當這些功能以SOA 的思想封裝成服務并在總線上流動時候，還可以使用流程引擎對其進行重新編排整理形成新的服務以適應新業(yè)務要求。流程抽取，待辦等需求只是比較簡單的數(shù)據(jù)流動，數(shù)據(jù)路由的要求不高。

綜上所述，在開源產(chǎn)品和商業(yè)產(chǎn)品在某些條件下都不甚理想的狀況下。企業(yè)可以嘗試自己針對自己的業(yè)務和應用特點設計自己的企業(yè)服務總線。這樣，設計企業(yè)服務總線的核心功能并適配以簡單的、少量的協(xié)議聯(lián)接滿足自身要求即可，在成本上非常合算。后續(xù)的擴展工作也好展開。本文下面就力求設計一個簡單的，只滿足自身需要的ESB 方案。

2 總線的設計

2.1 架構設計

在架構設計中，異構的應用通過適配器接入該總線，門戶也直接接入總線?？偩€中的接入適配器有多種傳輸協(xié)議可供選擇。信息通過接入適配器后，經(jīng)過數(shù)據(jù)解析后找到數(shù)據(jù)傳輸目標（服務地址）。然后再路由到目的地。同時，如果信息是異步的，則借助消息服務器代理轉發(fā)。在這種架構中，不用區(qū)分服務消費者和服務提供者。同一種接入方式都可實現(xiàn)服務提供和消費的功能。

總線中也集成流程引擎，可以將總線中的服務編排成新流程功能服務使用。

2.2 具體實現(xiàn)方式

為了實現(xiàn)消息的跨業(yè)務的異步通信，總線中必須集成消息服務器。按照java 平臺標準，即選擇采用JMS（Java Messaging Service）服務器。

總線這個中間件的“殼”可使用開源的應用服務器，考慮到這個中間件要集成JMS，則一定要選擇Java EE 服務器。同時考慮到集成開源的Java 平臺標準流程引擎JBPM，設計中選用JBOSS 產(chǎn)品。該產(chǎn)品包含了消息服務器和JBPM 流程引擎。

數(shù)據(jù)解析模塊涉及到統(tǒng)一數(shù)據(jù)模型，統(tǒng)一數(shù)據(jù)模型采取XML方式，因為在SOA 化的組織結構中，XML 已經(jīng)成為了數(shù)據(jù)表示和數(shù)據(jù)交換的事實標準。

總線中服務的注冊模塊采取UDDI 的方式進行，該方式將Web服務管理起來，利用Web 服務技術實現(xiàn)控制服務接口，使用Web 服務描述語言（WSDL）定義服務，再采用服務組件技術SCA(Service Component Architecture)將服務組封裝，可快速、有效地實現(xiàn)企業(yè)服務總線。通過配置需要提供服務的WSDL 輸入輸出文件的XML Schema 即可分析和檢查結果。

2.3 應用集成設計

在框架中，集成采取了適配器的方式聯(lián)接總線，因為接入系統(tǒng)都是異構的或是跨平臺的，所以必須采用多種協(xié)議和適配器的方式聯(lián)接總線。

考慮到總線集成的跨平臺性，Web Service協(xié)議的提供是必須的，由于其跨平臺性Web Service 和XML 現(xiàn)在幾乎是SOA 和ESB 的唯一被認可的事實標準。甚至企業(yè)服務總線有這樣的定義：（ESB）是傳統(tǒng)中間件技術與可擴展標記語言（XML），Web Service 等技術結合的產(chǎn)物。

為了集成歷史遺留的其它系統(tǒng)，在“其他協(xié)議”中設計了以TCP/IP 的方式直接傳輸來解決這些系統(tǒng)的跨平臺聯(lián)接問題。在C/S 架構的應用系統(tǒng)中，基于java 平臺的系統(tǒng)還是占優(yōu)勢的，所以要提供RMI 的訪問方式解決java 系統(tǒng)間傳輸（直接調用）的問題。

3 問題和總結

此方案的優(yōu)點：

提供了一個簡單的企業(yè)服務總線的設計方案，該方案可實現(xiàn)了企業(yè)服務總線的基本功能。中間件和流程引擎、JMS 服務器都采用開源產(chǎn)品，成本較低，實現(xiàn)方案的門檻不高。適合一般企業(yè)的初級使用。如果企業(yè)以簡單應用開始構建SOA。按照該方案自主開發(fā)，則以后的擴展性會有優(yōu)勢。

缺點和待改進之處：

（1）功能少，只完成了核心功能。應用時可根據(jù)自身情況豐富功能。如安全控制和監(jiān)控，日志等管理功能。也可擴充通信協(xié)議和聯(lián)接方式。

（2）消息服務器跨業(yè)務不跨平臺。也是由于消息服務器沒有標準和規(guī)范的問題，目前提出標準消息服務器JMS 只能在Java 平臺使用。非Java 平臺無法使用該消息服務，目前在開源范圍沒有好的解決方案。如有條件將JMS Server 替換成商業(yè)軟件IBM Web Sphere Message Queue(MQ)則可解決消息服務器的跨平臺問題。

4 結論

企業(yè)應用的“數(shù)據(jù)孤島”的問題已經(jīng)是企業(yè)信息化過程面臨的一個瓶頸。OA 的具體實現(xiàn)形式一定是因地制宜而不是依賴于標準的（實際上也沒有標準），無論是EAI 還是ESB，無論是一個健壯的ESB還是經(jīng)過剪裁并本地化的ESB，都是通向SOA 之路的實現(xiàn)形式。按照自身需求并合理的安排并設計集成方案，才能適合本企業(yè)的狀況，節(jié)省成本，使企業(yè)應用集成更具備可行性。