ESB提供事件驅(qū)動和文檔導(dǎo)向的處理模式.docx

ESB提供事件驅(qū)動和文檔導(dǎo)向的處理模式，以及分布式的運行管理機制，支持基于內(nèi)容的路由和過濾，具備了復(fù)雜數(shù)據(jù)的傳輸能力，并可以提供一系列的標(biāo)準(zhǔn)接口。ESB是中間件技術(shù)實現(xiàn)并且支持SOA的一組基礎(chǔ)架構(gòu)，支持異構(gòu)環(huán)境中的服務(wù)、消息以及基于事件的交互，并且具有適當(dāng)?shù)姆?wù)級別和可管理性。ESB是SOA中的消息框架，即消息相互交換和通信的方式，是業(yè)界標(biāo)準(zhǔn)與客戶消息框架的整合。分布式部署和集中控制。ESB服務(wù)器在物理上可能相隔很遠，但是通過集中管理，這些服務(wù)器組成一個ESB網(wǎng)絡(luò)，在邏輯上形成完整的企業(yè)服務(wù)總線。服務(wù)注冊、發(fā)布和編排。在Apusic ESB的服務(wù)倉庫中，任何符合標(biāo)準(zhǔn)的服務(wù)都可以在其中注冊，從而被其他服務(wù)調(diào)用。而消費服務(wù)也無需知道被調(diào)用服務(wù)的具體特征，只需要發(fā)送相應(yīng)地請求即可找到相應(yīng)的服務(wù)，并進。行綁定和數(shù)據(jù)的傳輸。同時為了滿足具體的業(yè)務(wù)需求，不同的服務(wù)需要被組裝在一起形成新的應(yīng)用系統(tǒng)。Apusic ESB引入了工作流流程的概念，引入自主實現(xiàn)且基于業(yè)界標(biāo)準(zhǔn)的，具有條件分支和合并并行流轉(zhuǎn)功能的BPEL4WS流程引擎，從而實現(xiàn)綜合的、復(fù)雜的業(yè)務(wù)邏輯編排。這個流程引擎支持子流程、條件腳本、路由節(jié)點等功能。通過靈活的流程定義，按照即時的業(yè)務(wù)需求，將單個離散服務(wù)有機的組合起來，達到服務(wù)重組的目的，完成集成的業(yè)務(wù)需求。 此外，Apusic ESB在引擎級別將BPEL規(guī)范的細節(jié)進行了包裝，對用戶來說，只需要關(guān)心流程中的一個服務(wù)即可，無須再去關(guān)心BPEL的具體技術(shù)細節(jié)。 最后，所有的調(diào)用、轉(zhuǎn)換都必須有一個良好的管理工具來幫助實施，并進行監(jiān)控。Apusic ESB則提供了一體化的管理工具，通過這些工具，您可以非常方便的對ApusicESB進行集中式管理、可視化的流程設(shè)計，以及運行期的實時監(jiān)控等功能。SOA項目不應(yīng)從ESB開始,因為ESB只是技術(shù)手段，而SOA的目標(biāo)則是業(yè)務(wù)價值。對技術(shù)手段的過分重視往往使人們忽略了SOA的最終目標(biāo)，陷入在技術(shù)的泥潭當(dāng)中不能自拔。 以ESB來啟動一個SOA項目是有害的，它將陷入技術(shù)的怪圈中，而無法產(chǎn)生最大的業(yè)務(wù)價值。業(yè)務(wù)才應(yīng)該是SOA開始的起點和最終的目標(biāo)。你首先要在業(yè)務(wù)上進行服務(wù)的分解，然后才把他們映射到技術(shù)實現(xiàn)中。 SOA項目的實施必須從業(yè)務(wù)需求的分析開始，而不是從構(gòu)建ESB來開始。SOA框架體系下的軟件開發(fā)，應(yīng)該是從業(yè)務(wù)流程分析開始的，用一些組件化的業(yè)務(wù)建模方法，對實際的業(yè)務(wù)場景進行分析。在這個基礎(chǔ)上建立業(yè)務(wù)用例，并根據(jù)這些業(yè)務(wù)用例構(gòu)造業(yè)務(wù)流程模型。ESB不過工具和技術(shù)而已，關(guān)鍵上集成業(yè)務(wù)如何做?業(yè)務(wù)邏輯如何編制?如何實施? ESB項目需求分析和方案設(shè)計淺談2010-1-6如同其它IT項目一樣，企業(yè)服務(wù)總線類項目的實施也要經(jīng)歷需求分析、方案設(shè)計、編碼和測試、上線部署等階段。下面我們將針對ESB項目的設(shè)計和實施過程中各個階段要完成的主要工作內(nèi)容和一些最佳實踐跟大家作一些討論，進而希望大家在企業(yè)ESB項目實施過程中借鑒科學(xué)的方法論的指導(dǎo)來保證其成功。 TT SOA編輯推薦：企業(yè)服務(wù)總線ESB（更新版）ESB的需求分析需求分析階段是梳理項目中相關(guān)功能需求和非功能需求的重要步驟，它是整個項目成敗的關(guān)鍵。在這個階段我們將從企業(yè)業(yè)務(wù)需求出發(fā)，梳理端到端的跨系統(tǒng)業(yè)務(wù)流程；基于業(yè)務(wù)流程，依據(jù)科學(xué)的方法論進行服務(wù)鑒別；由服務(wù)列表出發(fā)，梳理服務(wù)的消費和提供關(guān)系；然后根據(jù)SOA的最佳實踐，定義服務(wù)的接口，包括服務(wù)的Schema描述，字段的類型，編碼的規(guī)則；依據(jù)服務(wù)的消費提供關(guān)系，梳理ESB中的服務(wù)映射和轉(zhuǎn)換規(guī)則和策略。概括而言，我們需要從功能性和非功能性兩個方面來進行ESB的需求分析。針對ESB的功能性需求，我們要側(cè)重了解以下方面的問題：1. 梳理出要被集成的系統(tǒng)的名稱，個數(shù)。2. 針對每個系統(tǒng)而言，要了解：該系統(tǒng)的對外接口是向外調(diào)用，被別人調(diào)用，還是二者都有； 接口的實時性要求，是實時的還是批量的，還是二者皆有？ 接口的調(diào)用方式，是同步的還是異步的，還是二者皆有？ 應(yīng)用系統(tǒng)所運行的操作系統(tǒng)平臺。 應(yīng)用系統(tǒng)本身的編程語言？C/C+, Java. 這些系統(tǒng)現(xiàn)有接口的情況，是否已經(jīng)可以提供對外接口，接口的方式是什么，包括接口的通訊協(xié)議是什么，HTTP/MQ/Socket/ 其它？接口的數(shù)據(jù)格式是什么，XML/ 自定義格式 / 其他行業(yè)標(biāo)準(zhǔn)格式？接口的編程語言是什么，Java/C/C+？如果本身不能提供接口，那么要做接口開發(fā)時有什么要求或限制條件？ 這些應(yīng)用后臺數(shù)據(jù)庫的情況，數(shù)據(jù)庫能否直接訪問？ 每個應(yīng)用跟其他應(yīng)用交換數(shù)據(jù)時，源數(shù)據(jù)格式和目的數(shù)據(jù)格式，比如從文本格式轉(zhuǎn)換為 XML 格式？ 交易特征：哪些處理要采用兩階段提交；是否需要多個消息組成一個交易；是否要保證消息之間的處理順序； 適配器的情況：對于一些特殊系統(tǒng)，是否已經(jīng)具備現(xiàn)成的適配器；適配器是單向的還是雙向的； 消息通信的模式：是Send and Forget、Request/Reply還是Pub/Sub? 針對ESB的非功能性需求，我們要確認(rèn)：1. ESB平臺的擴展性和高可用性需求，包括HA和集群等；2. ESB平臺的性能需求，主要包括系統(tǒng)間數(shù)據(jù)交換的頻率，要交換的數(shù)據(jù)的大小 ( 消息大小將直接對效率造成影響 )；峰值時候?qū)SB數(shù)據(jù)吞吐量、響應(yīng)時間的要求等；3. 哪些交易要保證數(shù)據(jù)傳輸?shù)母呖煽啃裕?. ESB平臺的可管理性需求，如服務(wù)的生命周期管理，ESB 平臺的維護和管理；如果企業(yè)已經(jīng)設(shè)立了SOA管控方面的規(guī)范，那么要遵從規(guī)范的制約，比如要考慮是否有規(guī)定的命名規(guī)則，企業(yè)是否有企業(yè)級的數(shù)據(jù)規(guī)范和底層通訊協(xié)議的規(guī)范等；5. 安全性方面的要求：是否采用SSL傳輸加密，是否對消息進行加密/解密處理等；6. 錯誤處理和日志以及平臺本身的運行監(jiān)控等方面的要求等。ESB的方案設(shè)計方案設(shè)計的主要內(nèi)容包括：ESB涉及IT應(yīng)用環(huán)境分析，定義ESB與相關(guān)應(yīng)用的接口模式； ESB架構(gòu)概要設(shè)計，并定義架構(gòu)原則； ESB相關(guān)產(chǎn)品選擇，包括與外圍系統(tǒng)的適配器選擇和ESB產(chǎn)品選擇； ESB組件模型設(shè)計，分解ESB的相關(guān)模塊，滿足SOA的分離關(guān)注點等架構(gòu)原則； ESB運作模型設(shè)計，滿足平臺的非功能性需求； ESB平臺的服務(wù)流設(shè)計，涉及路由、轉(zhuǎn)換和映射等； ESB的同步、異步或者發(fā)布/訂閱模式設(shè)計； ESB平臺的接入渠道和數(shù)據(jù)接口設(shè)計，包括XML/JMS、SOAP/HTTP、EDI/MQ 等； ESB相關(guān)的適配器設(shè)計，包括技術(shù)適配器或者自開發(fā)的適配器； ESB平臺的容錯和重試機制設(shè)計，包括日志等的統(tǒng)一管理等； 圖 1 是一個采用ESB整合的高層架構(gòu)設(shè)計舉例：圖 1. ESB參考架構(gòu) 如圖 1 所示，ESB架構(gòu)設(shè)計時主要要考慮通訊協(xié)議接入和轉(zhuǎn)換、數(shù)據(jù)接入和轉(zhuǎn)換、數(shù)據(jù)處理流程以及服務(wù)的注冊和管理等方面的內(nèi)容。其中通訊協(xié)議接入和轉(zhuǎn)換是指對各種被集成的應(yīng)用系統(tǒng)的通訊協(xié)議的支持和轉(zhuǎn)換能力，例如HTTP、JMS、Socket、FTP等；數(shù)據(jù)接入和轉(zhuǎn)換是指對各種被集成的應(yīng)用系統(tǒng)提供的數(shù)據(jù)格式的支持和轉(zhuǎn)換能力，例如XML、SOAP、自定義格式以及符合某些行業(yè)標(biāo)準(zhǔn)的專有格式（SWIFT、EDI、HL7 等）；數(shù)據(jù)處理流程是指路由、格式轉(zhuǎn)換、數(shù)據(jù)庫讀寫等對數(shù)據(jù)的各種處理；統(tǒng)一服務(wù)注冊存儲管理是指對服務(wù)的注冊、發(fā)布、查詢，以及對運營時服務(wù)的管控，并且提供服務(wù)運營狀態(tài)的統(tǒng)計分析數(shù)據(jù)。ESB的組件模型圖 2. ESB組件模型 圖 2 給出了一個ESB組件模型的示例，其中包含的各主要組件及其功能如下：1. Message Broker Runtime組件提供消息路由、格式轉(zhuǎn)換、消息日志等操作的運行時環(huán)境。該運行環(huán)境由IBM Message Broker提供；2. Messaging Broker Instance組件是處理基于MQ消息業(yè)務(wù)請求的容器。它是作為一個Broker實例運行在Message Broker Runtime上的。該實例提供了MQ消息的業(yè)務(wù)請求處理器、服務(wù)日志、服務(wù)定位等功能的運行容器；3. Web Service Broker Instance組件是處理基于Web Service的業(yè)務(wù)請求的容器，它是作為一個Broker實例運行在Message Broker Runtime上的。該實例提供了Web Service的業(yè)務(wù)請求處理、服務(wù)日志、以及服務(wù)定位等功能。4. Event Broker Instance組件是平臺內(nèi)部處理Pub/Sub事件的容器。它是作為一個Broker實例運行在Message Broker Runtime上的。該容器提供了Event Handler組件的運行環(huán)境，將基于MQ/JMS的事件分發(fā)到不同平臺組件的目標(biāo)隊列上。5. Message Handler組件是處理基于MQ消息的業(yè)務(wù)請求，包括消息解析、格式轉(zhuǎn)換，服務(wù)鑒權(quán)與認(rèn)證、服務(wù)路由、服務(wù)日志等功能。Message Handler組件處理MQ消息的典型流程如下：首先對MQ消息進行解析，對解析后的業(yè)務(wù)請求進行分析，之后通過Authentication 與 Authorization組件判斷該請求者的業(yè)務(wù)請求是否可以進行后續(xù)處理； 通過Service Locating組件對該業(yè)務(wù)請求進行服務(wù)定位與路由；將基于MQ的業(yè)務(wù)請求消息轉(zhuǎn)換成Web Service的業(yè)務(wù)請求消息； 通過Service Logging組件對整個業(yè)務(wù)請求進行日志記錄； 返回業(yè)務(wù)請求處理結(jié)果給業(yè)務(wù)發(fā)起者，如果失敗，返回錯誤消息。 6. Web Service Handler組件是處理基于Web Service的業(yè)務(wù)請求，與Message Handler組件功能類似，也包括消息解析、格式轉(zhuǎn)換，服務(wù)鑒權(quán)與認(rèn)證、服務(wù)路由、服務(wù)日志等功能。Web ServiceHandler組件處理Web Service請求的典型流程如下：首先對Web Service請求消息進行解析，對解析后的業(yè)務(wù)請求進行分析，之后通過Authentication與Authorization組件判斷該請求者的業(yè)務(wù)請求是否可以進行后續(xù)處理； 通過Service Locating組件對該業(yè)務(wù)請求進行服務(wù)定位與路由； 通過 Service Logging 組件對整個業(yè)務(wù)請求進行日志記錄； 返回業(yè)務(wù)請求處理結(jié)果給業(yè)務(wù)發(fā)起者，如果失敗，返回錯誤消息。 7. Event Handler組件實現(xiàn)對Pub/Sub的處理。8. Service Locating組件負(fù)責(zé)根據(jù)業(yè)務(wù)請求定位具體的服務(wù)提供者。Service Locating通過對服務(wù)目錄的查詢選擇適合的服務(wù)進行后續(xù)的調(diào)用，該查詢工作可以通過實時的服務(wù)目錄查詢獲得結(jié)果。9. Service Logging組件負(fù)責(zé)記錄整個業(yè)務(wù)請求處理過程中的情況，該組件的實現(xiàn)可以通過文件或者數(shù)據(jù)庫的方式。10. Authentication組件負(fù)責(zé)對業(yè)務(wù)請求者進行鑒權(quán)，判斷該業(yè)務(wù)請求者是否可以訪問平臺服務(wù)，該鑒權(quán)的工作在企業(yè)服務(wù)總線的外部進行，Authentication組件只是調(diào)用外部功能完成。11. Authorization組件判斷業(yè)務(wù)請求者是否具備訪問某特定服務(wù)的權(quán)限，該驗證權(quán)限的工作在企業(yè)服務(wù)總線的外部進行，Authorization 組件只是調(diào)用外部功能完成。以處理基于MQ消息輸入為例，ESB的組件交互圖如圖 3 所示：圖 3. ESB組件交互圖 ESB方案設(shè)計時的最佳實踐根據(jù)我們以往項目設(shè)計和開發(fā)時的一些經(jīng)驗，我們建議進行ESB的方案設(shè)計時要遵循下述最佳實踐：確定標(biāo)準(zhǔn)的使用：使用與否、使用到什么程度； 確定在ESB上實現(xiàn)的業(yè)務(wù)邏輯：ESB是一個服務(wù)路由和轉(zhuǎn)換中心，而不是一個應(yīng)用服務(wù)器，因此它并不能取代應(yīng)有服務(wù)器。復(fù)雜的消息解析和轉(zhuǎn)換相比簡單的路由操作所需消耗的成本要高的多，因此在ESB上應(yīng)該主要考慮路由、格式轉(zhuǎn)換、服務(wù)調(diào)用等問題，而對于數(shù)據(jù)本身的處理應(yīng)該交給相應(yīng)的應(yīng)用來完成； 確定消息格式：從標(biāo)準(zhǔn)化的角度而言，XML當(dāng)然是首選，但是從解析 / 處理性能、行業(yè)標(biāo)準(zhǔn)以及對現(xiàn)有應(yīng)用的最大兼容性的角度而言，可能會采用某些特定格式，例如EDI、SWITF、平文本或者自定義格式等； 區(qū)別消息頭和消息體：把數(shù)據(jù)的Meta-data，例如：安全相關(guān)的信息、日志的等級、請求端的標(biāo)識等放在消息頭中，而不要放在消息體中。這樣可以很容易地改變其內(nèi)容及其對其的處理邏輯。在ESB中只處理消息頭，避免對消息體的解析； 設(shè)計時參考ESB相關(guān)的成熟Patterns； 使用服務(wù)注冊庫：如需要服務(wù)Endpoint的查找：推薦從服務(wù)注冊中心進行查找，這樣的好處在于：服務(wù)提供者可以容易地發(fā)布新的服務(wù)，服務(wù)提供者和ESB之間的耦合度可以更低，通過關(guān)于服務(wù)本身的Metadata來進行服務(wù)的查找和路由； 注重性能和高可用性的考慮； 在必須的情況下考慮交易完整性； 適配器的采用：應(yīng)用系統(tǒng)通過適配器實現(xiàn)與 ESB 的雙向交互，適配器主要分為技術(shù)適配器、應(yīng)用適配器兩種，適配器的物理部署可以與EIS部署在一起、或者與ESB部署在一起，也可以單獨部署，在適配器設(shè)計時要考慮通信協(xié)議和消息格式兩個方面；多 ESB 的設(shè)計：ESB 也是一個邏輯的組件，在一個企業(yè)里可能需要多個ESB，例如：企業(yè)內(nèi)部ESB連接企業(yè)內(nèi)部各個系統(tǒng)，外部ESB實現(xiàn)企業(yè)與合作伙伴等的外部連接；再如：企業(yè)內(nèi)部可能存在若干個部門級ESB和一個全企業(yè)ESB； 確定服務(wù)版本控制策略； 確定端到端的QoS準(zhǔn)則； 注重安全性； 確定IT部門ESB平臺的負(fù)責(zé)主體，長期的投入。 ESB的安全性考慮對于ESB的安全性考慮，主要有兩種方式，第一種方式是通過ESB內(nèi)部的Mediation節(jié)點來進行服務(wù)請求者的認(rèn)證 / 授權(quán)；另一種是調(diào)用一個外部服務(wù)進行服務(wù)請求者的認(rèn)證 / 授權(quán)，如圖4所示，圖中給出了這兩種方式的示意圖，具體實施時可以進行選擇。圖 4. ESB的兩種安全實現(xiàn)方式 運行在ESB平臺上的服務(wù)的管理和監(jiān)控當(dāng)一個企業(yè)開始它的SOA之旅時，開始階段通常會選取一個具體的項目進行 SOA 的嘗試，然后便會逐步走向全企業(yè)采納，這時，大多數(shù)企業(yè)都會面臨一個問題，那就是服務(wù)越來越多，對這些服務(wù)目錄的管理出現(xiàn)了很多問題，例如：所有與服務(wù)相關(guān)的信息是如何被管理的，包括存儲、管理、維護、存取等？服務(wù)請求者如何決定使用哪個服務(wù)？服務(wù)請求者如何定位服務(wù)的 Endpoint？當(dāng)服務(wù)信息發(fā)生改變時如何得到通知？因此我們建議用戶在盡可能早的情況下考慮服務(wù)注冊中心的建設(shè)，所謂服務(wù)注冊中心是一個企業(yè)范圍內(nèi)的服務(wù)信息的存儲庫，該存儲庫存儲了企業(yè)中注冊的服務(wù)和服務(wù)相關(guān)的信息，它的主要功能包括：采用集中的方式來管理服務(wù)相關(guān)的信息，為服務(wù)元數(shù)據(jù)同時提供“注冊中心”功能，允許用戶存儲、管理和查詢包含服務(wù)描述的服務(wù)元數(shù)據(jù)構(gòu)件； 提供服務(wù)的治理功能，實現(xiàn)整個服務(wù)生命周期的管理； 提供服務(wù)間依賴、包容關(guān)系的管理； 提供分類和版本控制等功能； 提供服務(wù)發(fā)現(xiàn)和通知等能力等。 除了服務(wù)注冊中心的考慮之外，我們還要考慮對服務(wù)的管理。服務(wù)不僅具有特定的功能，還應(yīng)該滿足一些諸如性能、可用性、安全性等QoS指標(biāo)。服務(wù)響應(yīng)的快慢、什么時間可用、可以被誰調(diào)用、在某個時間段里能被調(diào)用多少次、哪些事件要記錄日志，這些都是服務(wù)管理要考慮的問題。通過服務(wù)注冊中心和服務(wù)監(jiān)控平臺的有機配合，我們可以根據(jù)服務(wù)的響應(yīng)時間、服務(wù)可用與否等策