摘要：企業(yè)服務總線（Enterprise Service Bus，ESB）從面向服務體系架構(gòu)（Service Oriented Architecture，SOA）發(fā)展而來，是傳統(tǒng)中間件技術(shù)與XML、Web服務等技術(shù)結(jié)合的產(chǎn)物，可以消除不同應用之間的技術(shù)差異，讓不同的應用服務器協(xié)調(diào)運作，實現(xiàn)了不同服務之間的通信與整合。文章以某制造企業(yè)ESB平臺部署及設計為例，介紹了ESB的實現(xiàn)方法。

關(guān)鍵詞：企業(yè)服務總線；服務體系架構(gòu)；ESB平臺部署；接口服務設計；制造企業(yè) 文獻標識碼：A

中圖分類號：TP393 文章編號：1009-2374（2016）23-0021-02 DOI：10.13535/j.cnki.11-4406/n.2016.23.009

1 概述

ESB全稱為Enterprise Service Bus，即企業(yè)服務總線。它是傳統(tǒng)中間件技術(shù)與XML、Web服務等技術(shù)結(jié)合的產(chǎn)物。ESB提供了網(wǎng)絡中最基本的連接中樞，是構(gòu)筑企業(yè)神經(jīng)系統(tǒng)的必要元素。ESB的出現(xiàn)改變了傳統(tǒng)的軟件架構(gòu)，可以提供比傳統(tǒng)中間件產(chǎn)品更為廉價的解決方案，同時它還可以消除不同應用之間的技術(shù)差異，讓不同的應用服務器協(xié)調(diào)運作，實現(xiàn)了不同服務之間的通信與整合。從功能上看，ESB提供了事件驅(qū)動和文檔導向的處理模式以及分布式的運行管理機制，它支持基于內(nèi)容的路由和過濾，具備了復雜數(shù)據(jù)的傳輸能力，并可以提供一系列的標準接口。

本文以某制造企業(yè)建設ESB的過程為例，簡要介紹了企業(yè)部署ESB平臺，并通過該平臺進行接口服務設計的一些基本方法。

2 ESB平臺部署

第一，系統(tǒng)軟件的選擇主要包括如下：

ESB平臺軟件：IBM Message Broker 8.0

系統(tǒng)管理服務器及日志服務器：Apache Tomcat 9.0

系統(tǒng)日志數(shù)據(jù)庫：采用Oracle或者MySQL

第二，系統(tǒng)主要硬件設備如下：

負載均衡設備：基于F5構(gòu)建，對外提供ESB平臺的標準服務端口，由該設備接收所有的ESB服務請求，并將服務請求按照MB服務器集群中各服務器的負載情況分發(fā)給MB服務器集群中的MB服務器。

MB服務器集群：基于Linux服務器構(gòu)建，安裝了IBM MessageBroker軟件，基于集群的Message Queue構(gòu)建；服務器上運行了株機ESB平臺系統(tǒng)，進行相關(guān)的數(shù)據(jù)處理及基于株機ESB規(guī)范的業(yè)務操作。

管理、日志服務器：MessageBroker的日志服務器，安裝了Apache Tomcat，運行了日志軟件以及系統(tǒng)配置軟件，MB服務器將在啟動時從該服務器讀取相關(guān)配置信息，并在業(yè)務操作中將日志數(shù)據(jù)發(fā)送到該服務器?？紤]到維護管理的復雜度，該服務器可以酌情建設APP服務器集群，但是基于關(guān)鍵性原則，不建議構(gòu)建超過2臺服務器的集群。

NAS：安裝了NFS提供共享硬盤，通過iScsi對外提供數(shù)據(jù)庫存儲，主要保存在ESB運行過程中的各項日志信息，該數(shù)據(jù)庫服務器可以使用主機現(xiàn)有的服務器實例來運行。

3 集成概念設計

3.1 業(yè)務場景到ESB集成的判斷標準

3.1.1 業(yè)務服務滿足度判斷標準。業(yè)務服務滿足度的判斷標準是用來分析、判斷該服務是否能夠滿足具體的業(yè)務，或者換言之是否存在具體的業(yè)務會使用到該服務。在業(yè)務分析時，該問題主要是用來衡量業(yè)務使用ESB來支持的價值，當該服務被越多的業(yè)務場景使用到，服務在該問題評判上的評分就越高。業(yè)務服務滿足度的問題是“這個服務提供的業(yè)務功能能否滿足業(yè)務流程和目標？這個服務能夠直接（相對于繼承于它的子服務）滿足某個業(yè)務目標？”

3.1.2 服務實現(xiàn)復雜度判斷標準。服務實現(xiàn)技術(shù)復雜度評判標準是用來分析、判斷該服務的實現(xiàn)成本以及該成本是否能夠被預算所實現(xiàn)。在實際業(yè)務實現(xiàn)時，存在一些老舊的不能支持Web service模式的系統(tǒng)，并且在過去集成這些系統(tǒng)時，使用了耦合度較高的集成模式，比如DLL方式；這樣如果要將這些集成遷移到ESB上，需要較多的預算甚至需要重新改造軟件系統(tǒng)本身；部分系統(tǒng)雖然支持Web service模式，但是因為原開發(fā)廠商的問題，要使用Web service的成本較高，服務實現(xiàn)復雜度判斷標準的問題是“業(yè)務上是否可以提供資金支持本服務的整個生命周期（創(chuàng)建、管理、治理和維護）？”

3.1.3 服務實現(xiàn)安全性判斷標準。服務實現(xiàn)安全性評判標準是用來分析、判斷該服務在實現(xiàn)后是否會帶來潛在的數(shù)據(jù)暴露風險。在實際業(yè)務中，任何數(shù)據(jù)都存在它的保密級別，比如某類數(shù)據(jù)可以被匿名訪問獲取或者某類數(shù)據(jù)的所有訪問操作均需要記錄訪問者，也存在一些數(shù)據(jù)只能被少數(shù)人訪問，而使用了ESB后，數(shù)據(jù)被發(fā)布到ESB上，客觀上就可以被所有能訪問ESB的外部用戶訪問到，因此需要考慮每一個服務對外公開的范圍，甚至部分數(shù)據(jù)就不能使用ESB來對外提供集成。服務實現(xiàn)安全性判斷標準的問題是“業(yè)務上是否允許將本服務提供給內(nèi)部或外部的用戶或業(yè)務合作伙伴？比如這樣做可能會帶來額外的成本、商業(yè)秘密、安全性等問題？”

3.2 集成概念設計的原則性要求

3.2.1 完整性。基于業(yè)務的需要，所有交互的數(shù)據(jù)、文檔必須是完備的，數(shù)據(jù)交互本身必須包含所有本次需要交互的數(shù)據(jù)，并確保發(fā)送端發(fā)出的數(shù)據(jù)與接收端接收的數(shù)據(jù)完全一致。自校驗可以被認為是保證數(shù)據(jù)完整性的主要手段，這是指：（1）在每一次數(shù)據(jù)交互過程中，通過技術(shù)手段來確保交互的數(shù)據(jù)的完整性；（2）在數(shù)據(jù)交互結(jié)束后，通過其他方法對于雙方的數(shù)據(jù)進行檢驗，按照檢驗值判斷雙方數(shù)據(jù)一致。

3.2.2 及時性。該企業(yè)的信息系統(tǒng)均設計為支持內(nèi)部生產(chǎn)業(yè)務運作，這就意味著大多數(shù)業(yè)務集成場景下，數(shù)據(jù)的實時性要求并不高，系統(tǒng)操作是要求當業(yè)務操作到需要被交互數(shù)據(jù)時，能夠得到數(shù)據(jù)；在系統(tǒng)設計時就對應著可以通過在業(yè)務操作過程中補充拉取數(shù)據(jù)的方法來保證交互的及時性。

3.2.3 自糾錯。作為數(shù)據(jù)完整自校驗的后續(xù)手段，當發(fā)現(xiàn)兩邊數(shù)據(jù)出現(xiàn)不一致情況時，需要在系統(tǒng)集成時從集成方法上提供方法，來完成數(shù)據(jù)的重新交互。這意味著系統(tǒng)間的數(shù)據(jù)交互可以在任何狀態(tài)下重新開始，無論是系統(tǒng)在數(shù)據(jù)傳輸過程中停機，還是業(yè)務問題需要重新初始化數(shù)據(jù)，均能夠通過自糾錯方法完成數(shù)據(jù)的重傳，以達到數(shù)據(jù)在所有系統(tǒng)的最終一致。

3.3 集成場景

按照業(yè)務場景的特點，可以將業(yè)務場景分成如下種類來設計每一種場景的實現(xiàn)方法，來保證集成的完整性、及時性、自糾錯。需要說明的是，這種方法僅是每一種場景集成設計的建議模板，在實際的設計過程中可以根據(jù)具體情況進行調(diào)整。集成場景的區(qū)分主要是基于每一個集成場景所交互的數(shù)據(jù)的特點進行分類，這些數(shù)據(jù)特點包括：

3.3.1 交互類型：交互類型是指在業(yè)務場景的使用過程中，服務的請求方對于服務返回的時間要求，這主要反映了及時性的要求，交互類型主要分為異步數(shù)據(jù)交互與同步數(shù)據(jù)交互。

3.3.2 數(shù)據(jù)變化頻度：數(shù)據(jù)變化頻度是指服務所提供的數(shù)據(jù)的變化頻度，該類數(shù)據(jù)的增改的頻次情況，基本上以每天都可能有更新描述為頻度較高，否則為頻度較低。

3.3.3 數(shù)據(jù)量大?。簲?shù)據(jù)量大小是指服務交互的數(shù)據(jù)的單次交互數(shù)據(jù)量的大小，這包括兩種情況：（1）單條數(shù)據(jù)的數(shù)據(jù)量較大；（2）單條數(shù)據(jù)的數(shù)據(jù)量不大，但是每次交互的數(shù)據(jù)條目較多。數(shù)據(jù)量大小一般以字節(jié)單位衡量；單次交互數(shù)據(jù)量在2K字節(jié)以上被認為數(shù)據(jù)量大，否則被認為數(shù)據(jù)量小，單次交互數(shù)據(jù)量在1M字節(jié)以上被認為數(shù)據(jù)量超大；在集成場景中，因為交互多條數(shù)據(jù)而造成的交互數(shù)據(jù)量大并不被認為數(shù)據(jù)量大。

3.3.4 數(shù)據(jù)實時性要求：數(shù)據(jù)實時性要求主要反映在異步數(shù)據(jù)交互中，數(shù)據(jù)使用系統(tǒng)對于數(shù)據(jù)的實時性要求，或者換言之系統(tǒng)間針對某服務提供的數(shù)據(jù)，多少時間內(nèi)不一致不會造成業(yè)務問題。在分析時，系統(tǒng)間僅允許10分鐘的數(shù)據(jù)差異稱之為數(shù)據(jù)實時性要求高，否則稱之為數(shù)據(jù)實時性要求低。

4 公共接口服務設計

公共服務是指在ESB規(guī)范中，要求所有業(yè)務系統(tǒng)均實現(xiàn)的交互服務，這些服務被用來支持最基礎的集成業(yè)務，保證系統(tǒng)間集成的可靠性以及企業(yè)信息化系統(tǒng)數(shù)據(jù)的整體一致性。因此公共服務被設計為在所有接入ESB平臺的系統(tǒng)中部署，作為規(guī)范要求所有接入系統(tǒng)實現(xiàn)。我們整理出了如下公共服務，作為企業(yè)ESB平臺的公共服務，要求各業(yè)務系統(tǒng)實現(xiàn)。

表1

服務名 服務說明 業(yè)務系統(tǒng)角色

CHECKAVAIL 基礎的心跳服務，ESB使用該服務確認業(yè)務系統(tǒng)的狀態(tài)，并進行基礎信息的交互。 作為服務提供端

NOTIFYINFOCHANGE 基礎的通知消息服務，ESB通過該消息通知業(yè)務系統(tǒng)某種業(yè)務數(shù)據(jù)發(fā)生了變化。 作為服務提供端

RECINFODESC 基礎的數(shù)據(jù)對照服務，業(yè)務系統(tǒng)通過該服務獲取某業(yè)務數(shù)據(jù)的描述。 作為服務請求端

SYNCBASORG 獲取組織機構(gòu)信息服務，ESB通過該服務對業(yè)務系統(tǒng)提供組織機構(gòu)的更新信息。 作為服務請求端

SYNCBASUSER 獲取用戶信息服務，ESB通過該服務對業(yè)務系統(tǒng)提供用戶的更新信息。 作為服務請求端

SYNCBASDATA 系統(tǒng)預留的獲取部分公共數(shù)據(jù)編碼的方法，該數(shù)據(jù)編碼形式為名稱=值的形式，提供諸如性別編碼、職位類型編碼等編碼的獲取。 作為服務請求端

5 開發(fā)及應用流程

5.1 確定業(yè)務系統(tǒng)功能范圍

該階段的主要工作是確認當前需要部署到ESB的業(yè)務系統(tǒng)的功能范圍，并討論各功能集成場景。

5.2 確定該業(yè)務系統(tǒng)相關(guān)的服務接口

本階段的主要工作是針對前一階段得到的服務列表進行分析，確認能夠完成本次系統(tǒng)集成。

5.3 基于ESB提供的wsdl生成代碼

代碼生成后即可開始Web服務的調(diào)用。

5.4 測試及上線

為了確保各自實現(xiàn)的正確性，為了以后的聯(lián)調(diào)聯(lián)測工作能夠順利進行，要求參與集成的各方對自己的開發(fā)結(jié)果進行測試。測試過程中使用的測試數(shù)據(jù)由各自虛構(gòu)，但需使用有意義、符合規(guī)則、盡量真實的數(shù)據(jù)。集成相關(guān)方按照上線計劃準備相關(guān)程序和基礎數(shù)據(jù)，在指定時間進行上線。

作者簡介：龔偉（1979-），男，四川榮縣人，中車株洲電力機車有限公司信息管理部高級工程師，碩士，研究方向：裝備制造業(yè)信息化。

（責任編輯：黃銀芳）