轉載 JBI與ESB SOA

時間 2019-11-17

標籤轉載 jbi esb soa 欄目微服務简体版

原文原文鏈接

業界正在普遍尋求解決 B2B 以及 EAI （企業應用集成）所存在問題的方案。這些方案不一樣於基於 JMS 手段的面向消息中間件技術和 Web 服務技術。本筆記歸納地闡述了與 SOA （面向服務體系架構）規範及 ESB （企業服務總線）基礎架構有關的 JBI （Java 業務集成）標準。如下第一，二部分轉載後整理的。html

一．關於面向服務體系架構java

關於SOA的概念，你能夠找到不少的文章從不一樣的角度來描述它，不一樣的軟件提供商也有不一樣的定義方式。BEA有流體計算，微軟有Indigo 和SOA-building， SAP有ESA。每一個人均可以從不一樣的視角來理解SOA，從程序員的角度，SOA是一種全新的開發技術，新的組件模型，好比說Web Service；從架構設計師的角度，SOA就是一種新的設計模式，方法學；從業務分析人員的角度，SOA就是基於標準的業務應用服務。從概念的角度，IBM對SOA的定義是最爲全面的，既SOA是一種構造分佈式系統的方法，它將業務應用功能以服務的形式提供給最終用戶應用或其餘服務。SOA包括以下要素:程序員

l 一個體系架構，用開放的標準將軟件資產(Asset)化爲服務web

l 提供標準的方法來表示軟件資產及其交互數據庫

l 單獨的軟件資產做爲構造單元，被重複使用來開發其餘應用apache

l 將關注點從細節實現轉移到應用(application)組裝設計模式

l 整合企業外部的應用（B2B）的方式架構

l 開發（如今）和整合（將來）的統一app

本文針對的讀者是軟件開發人員，站在開發人員的角度，每每但願軟件開發可以知足對於開發效率、可靠性、易維護性、易管理等多方面的更高要求。讓咱們經過回顧軟件開發的演化過程來看一看SOA出現的必然性：框架

l 面向機器語言(Monolithic)的開發模式：須要根據不一樣平臺的機器語言來開發代碼。

l 面向過程(Procedure)的開發模式：獨立於機器的程序語言(C, Pascal等)使開發過程變得簡單了，用過程來表明一個抽象的代碼集合，包裝重用現成的代碼。

l 面向對象(Object)的開發模式：用更接近現實的對象來表述一個相對完整的事物。面向對象的語言(Smalltalk，Java等)，提供了更抽象的封裝和重用模式。面向對象的開發強調從現實世界問題域到軟件程序的直接映射，更接近人類的天然思惟方式。

l 面向組件(Component)的模式：隨着軟件開發規模的擴大，在涉及分佈式、異構等複雜特徵的環境中，代碼級別的重用性差，可維護性差，效率低的弱點是不可逾越的，所以人們以架構運行環境(如.Net，J2ee等)來提供完善的支撐平臺，從而把開發者解放出來，更專一於業務核心的開發。而這些業務功能(Business Function) 以組件的形式(DCOM， EJB等)發佈運行在架構運行環境中。軟件開發的重用模式也上升到業務組件的級別。

l 面向服務(SOA)的模式：當軟件的使用範圍擴展到更廣闊的範圍，每每會面對更加複雜的IT環境和更加靈活多變的需求。服務(Service)的概念出現了，人們將應用(Application)以業務服務(Business Service)的形式公佈出來供別人使用，而徹底不須要去考慮這些業務服務運行在哪個架構體系上，由於全部的服務都講着一樣的語言。SOA考慮了業務發展的長期性，體現了"變化就是永恆"的思想。SOA的核心體如今企業應用或者業務功能上的"重用"和"互操做"，而再也不把IT與業務對立起來，這能夠被視爲在IT驅動業務的方向上邁出的重要一步。

咱們注意到，SOA一樣也強調重用(Reuse)，可是相對於傳統的代碼重用，對象重用，和部件重用，SOA的重用粒度更粗。SOA的重用在於業務級的應用，即服務的重用，這與軟件的發展規律是相一致的。在軟件發展的過程當中，軟件重用的對象愈來愈接近咱們的現實生活。經過部件的重用，軟件的開發更具效率，而且開始試圖用組件表達業務模式。可是，IT人員仍很難對業務人員解釋清楚IT結構怎樣映射到業務模型上。然而，IT架構與業務模型的彌合是不可避免的方向。現代企業的業務環境所面臨的最大挑戰就是變化，規則在變，需求在變，而對變化作出最快的反應，儘快地適應變化，成爲企業佔得先機，成功運做的關鍵。不少企業的業務環境依賴於他們的IT架構，所以，IT部門每每直接承載了業務變化帶來的壓力。每個具體的業務變化，都直接反應到對現有的IT平臺的要求：要麼企業IT架構自己對變化自適應，要麼IT架構可以在短期內根據新的業務規則作出調整。這就是SOA架構提出的根本緣由，咱們須要一種更加貼近業務的IT架構，可以直接描繪業務，對那些不懂IT技術的業務領域專家來講，業務服務倒是他們最熟悉的，也就是說是SOA把軟件重用的對象從IT人員上升到了業務人員。所以，咱們能夠說SOA與其它的模式相比，最大的進步在於它與業務的關聯性，"服務"對應到實際業務。IT經過"服務"與業務發生了密切的關係，業務人員和IT人員均可以專一於業務邏輯的實現，而共同的語言就是"服務"。

但不是什麼場合都適用SOA。一般來說，SOA適用於較爲複雜的IT架構，常常須要與外部複雜的IT環境交互，而且須要快速地應對頻繁發生的業務變化。就像你不可能在控制洗衣機的芯片上使用EJB開發同樣，若是你的IT環境規模很小，足以靈活地應對變化，不須要與其餘的異構IT環境頻繁交互，那麼SOA帶來的好處就不足以抵消它給你帶來的系統複雜性。可是，即令如此，你也並無被徹底排除在SOA的大趨勢以外。SOA是如此地倍受矚目，咱們能夠預見到它的迅猛發展，所以即便你的內部IT架構自己並非基於SOA的，你也還有機會參與到將來的SOA架構中去。例如，將你的某個業務以服務的形式發佈到某個外部SOA平臺上供別人使用，做爲第三方SOA平臺的一個服務提供者(Service Provider)存在。

在選擇SOA的實施方案時，要記住，軟件的具體實現技術諸如Web 服務與SOA是兩回事，SOA是一個概念，方法學，或者用一個更時髦的詞：一種模型。而Web 服務呢？它是一種具體的實現技術，就像EJB同樣。SOA ≠ Web服務。不過公平地講，Web 服務倒確實是目前最適合實現SOA的技術之一，用Web 服務來封裝業務服務是個不錯的選擇。由於Web服務是標準的，WS-I協議保證了來自不一樣廠商的Web服務即便運行在不一樣的平臺上，底層的實現機理不一樣也能夠順利交互，這是之前的任何一種技術如CORBA，EJB，或DCOM都不能作到的。並且，Web服務的定義與實現是分開描述的，即鬆散耦合，所以，能夠很方便地替換服務的內在實現而不會對現有的系統形成任何衝擊，這也極大地促進了IT架構的靈活性。

對於SOA更進一步的瞭解，能夠參考IBM developerWorks上其餘SOA相關的文章(請參見參考資料)，咱們的系列文章將主要討論ESB，所以再也不此過多地論述SOA了。爲了使咱們下面的論述更順暢，請先牢記典型的SOA架構有哪些基本的要求：

1. SOA在相對較粗的粒度上對應用服務或業務模塊進行封裝與重用；

2. 服務間保持鬆散耦合，基於開放的標準，服務的接口描述與具體實現無關；

3. 靈活的架構 -服務的實現細節，服務的位置乃至服務請求的底層協議都應該透明；

二．關於標準提出的背景(EAI 和 B2B 的若干問題)以及ESB

假定如今已經按照SOA的思想提煉出了各類業務服務，公佈出來，一樣，你發現其餘不少人也作了一樣的事情。你們都很振奮，開始踊躍的嘗試，我調用你的一個服務，你調個人一個服務。啊哈！你們都SOA了。且慢，那麼這個SOA給大家帶來了什麼好處呢？Ok，如今我能夠在J2EE環境裏調用.Net的組件了，可是原來沒有SOA的時候也能夠作到的呀。只要兩個節點之間互相承認對方的方式，即便不存在公開/統一的服務界面也能夠實現點到點的互聯。所以咱們不得不認可，若是咱們只有服務，而服務的請求者和服務的提供者之間仍然須要這種顯式的點到點的調用，那麼這就不是一個典型的SOA架構。請看圖二，服務的參與雙方都必須創建1對1 的聯繫。這樣一個結構與我十幾年前的那種互聯的方式何其類似！可是，還記得咱們上面提到的SOA三個基本要素嗎？顯然第三點沒有作到。

所以，在SOA中，咱們還須要這樣一箇中間層，可以幫助實如今SOA架構中不一樣服務之間的智能化管理。最容易想到的是這樣一個HUB-Spoke結構，在SOA架構中的各服務之間設置一個相似於Hub的中間件，由它充當整個SOA架構的中央管理器的做用。請看圖三，如今服務的請求者和提供者之間有了一個智能的中轉站，服務的請求者再也不須要了解服務提供者的細節。不錯！看上去是一個好的SOA結構。事實上，傳統的EAI就是經過這樣一種方式來試圖解決企業內部的應用整合問題。

EAI的目標是支持對現有IT系統的從新利用，經過EAI技術可以將不一樣的軟件和系統串聯起來，延長這些應用系統的生命週期。傳統的EAI，每每使用如CORBA和COM等的消息中間件進行分佈式，跨平臺的程序交互，修改企業資源規劃以達到新的目標，使用中間件、XML等方法來進行數據分配。所以，實際上傳統的EAI是部件級的重用。很不幸的是，基於部件的架構沒有統一的標準，所以，各個廠商都有各自不一樣的EAI解決方案，你會看到各類各樣的中間件平臺。若是EAI碰到了異構的IT環境，就必須分別考慮怎樣在各個不一樣的中間件之間周旋，來實現合理的互聯方式，你不得不考慮各類複雜的可能性。所以，你所見過的大多數傳統EAI解決方案都比較笨重。

再回顧一下咱們上面介紹過的SOA的應用場景：複雜的企業級架構。若是咱們選擇Hub的模式來構建SOA基礎架構，從純粹邏輯的角度，可能會出現哪些問題呢？首先，整個SOA架構的性能，若是每一個服務的請求都通過中央Hub的中轉，那麼Hub的負擔會很重，速度會隨着參與者的增多而越來越慢；其次，這樣的系統會很脆弱，一旦Hub出錯，整個SOA架構都會癱瘓；最後，這樣的架構會破壞SOA的開放性原則，參與者運行在一個相對封閉的環境中，擴展起來十分麻煩。所以，這也不是理想的SOA架構。

好了，如今該ESB登場了:

它與前面的Hub結構有什麼不一樣呢？首先，它比單一Hub的形式更開放，總線結構有無限擴展的可能；其次，真正體現了SOA的理念，一切皆爲服務，服務在總線(BUS)中處於平等的地位。即便咱們須要一些Hub，那麼它們也是以某種服務的形式部署在總線上，相比上面的結構要靈活的多。這就是ESB，咱們須要給它一個明確的定義：ESB是一種在鬆散耦合的服務和應用之間標準的集成方式。它能夠做用於：

l 面向服務的架構 -分佈式的應用由可重用的服務組成

l 面向消息的架構 - 應用之間經過ESB發送和接受消息

l 事件驅動的架構 - 應用之間異步地產生和接收消息

很不幸，上面的定義看上去很拗口，咱們暫且用一句較通俗的話來描述它：ESB就是在SOA架構中實現服務間智能化集成與管理的中介。而它與SOA的關係要相對好理解一些：ESB是邏輯上與SOA 所遵循的基本原則保持一致的服務集成基礎架構，它提供了服務管理的方法和在分佈式異構環境中進行服務交互的功能。能夠這樣說，ESB是特定環境下(SOA架構中)實施EAI的方式：首先，在ESB系統中，被集成的對象被明肯定義爲服務，而不是傳統EAI中各類各樣的中間件平臺，這樣就極大簡化了在集成異構性上的考慮，由於無論有怎樣的應用底層實現，只要是SOA架構中的服務，它就必定是基於標準的。

其次，ESB明確強調消息(Message)處理在集成過程當中的做用，這裏的消息指的是應用環境中被集成對象之間的溝通。以往傳統的EAI實施中碰到的最大的問題就是被集成者都有本身的方言，即各自的消息格式。做爲基礎架構的EAI系統，必須可以對系統範疇內的任何一種消息進行解析。傳統的EAI系統中的消息處理大可能是被動的，消息的處理須要各自中間件的私有方式支持，例如API的方式。所以儘管消息處理自己很重要，但消息的直接處理不會是傳統EAI系統的核心。ESB系統因爲集成對象統一到服務，消息在應用服務之間傳遞時格式是標準的，直接面向消息的處理方式成爲可能。若是ESB可以在底層支持現有的各類通信協議，那麼對消息的處理就徹底不考慮底層的傳輸細節，而直接經過消息的標準格式定義來進行。這樣，在ESB中，對消息的處理就會成爲ESB的核心，由於經過消息處理來集成服務是最簡單可行的方式。這也是ESB中總線(Bus)功能的體現。其實，總線的概念並不新鮮，傳統的EAI系統中，也曾經提出過信息總線的概念，經過某種中間件平臺，如CORBA來鏈接企業信息孤島，可是，ESB的概念不只僅是提供消息交互的通道，更重要的是提供服務的智能化集成基礎架構。

最後，事件驅動成爲ESB的重要特徵。一般服務之間傳遞的消息有兩種形式，一種是調用(Call)，即請求/迴應方式，這是常見的同步模式。還有一種咱們稱之爲單路消息(One-way)，它的目的每每是觸發異步的事件，發送者不須要立刻獲得回覆。考慮到有些應用服務是長時間運行的，所以，這種異步服務之間的消息交互也是ESB必須支持的。除此以外，ESB的不少功能均可以利用這種機制來實現，例如，SOA中服務的性能監控等基礎架構功能，須要經過ESB來提供數據，當服務的請求經過ESB中轉的時候，ESB很容易經過事件驅動機制向SOA的基礎架構服務傳遞信息。

關於ESB的總結：

ESB （企業服務總線）爲面向服務體系提供了基礎架構。經過設計工具定義服務間交互和規則， ESB 爲部署和發現服務提供了運行時環境。

在 ESB 的世界中，服務不會直接彼此交互。「 ESB 運行時」做爲一個仲裁者在服務間鬆散的耦合它們。「 ESB 運行時」將實現協議綁定、消息傳輸、消息處理，等等。

一個服務總線將包括下列關鍵項：

爲服務提供傳輸綁定

定義和發現已部署服務

在服務間基於規則的路由和編排消息

包括文檔傳遞在內的增值服務等

大部分的 ESB 提供商基於本身的 SOA 提議來開放標準和技術，包括多種 Web 服務標準和協議。他們提供多種調用服務的傳輸綁定，包括 HTTP 、 FTP 以及JMS 等等。大部分 ESB 用戶利用 WS-BPEL （ Web 服務的業務流程執行語言）來了解已部署服務之間是如何實現業務流程的。 ESB 提供商同時也提供服務質量特性，包括容錯、故障轉移、負載平衡、消息緩衝等等。

三．Java 業務集成

JBI （Java 業務集成）的提出是基於面向服務體系提倡的方法和原則，爲了解決 EAI 和 B2B 若干問題的 Java 標準。當前版本（ 1.0 ）是 2005 年 8 月經過的JSR （Java 規範需求） 208 定案。商業和開源界都歡迎 JBI 成爲他們 ESB 產品的集成標準。

JBI環境的架構

JBI 定義了基於插件方式的架構，以便服務能融入「 JBI 運行時」環境。 JBI 提供了詳細的接口，使服務能與「 JBI 運行時」環境交互。這些服務要爲「 JBI 運行時」環境暴露接口，以便「 JBI 運行時」環境爲服務路由消息，也即JBI定義了一種環境，在這種環境下，插件組件使用一種直接基於WSDL2.0的服務模型來進行交互。因此，「 JBI 運行時」環境在部署在 SOA 環境中的服務間扮演着仲裁者的角色。

在同一 JVM 中，「 JBI 運行時」核心主要包括以下組件：

組件框架：組件框架把不一樣類型的組件部署到「 JBI 運行時」。

歸一化的消息路由器：歸一化的消息路由器利用標準機制實現服務間消息交換。

管理框架：管理框架基於 JMX 進行部署、管理以及監控「 JBI 運行時」中的組件。

下圖爲JBI高層架構的視圖

JBI環境外面的是服務消費者跟提供者，它們表明了將被JBI集成進來的外部實體。這些外部實體可使用各類不一樣的技術來跟JBI環境裏的Binding Components來進行通訊。而服務引擎是一個基本的標準化的容器，它用來容納基於引擎規範所定義的實體(好比說wsdl所定義的服務提供者和消費者)。

組件模型――組件框架(Component Framework)

JBI 在「 JBI 運行時」環境中定義了兩種組件：

服務引擎（SE）組件：該組件負責實現業務邏輯和其餘服務。服務引擎組件在其內部可以使用多種技術和設計模式。服務引擎組件可提供數據傳輸和轉換這種簡單的基礎服務，也可實現像 WS-BPEL 實例同樣複雜的業務處理。

綁定（BC）組件：綁定組件主要爲已部署服務提供傳輸級綁定。綁定組件有多種類型：

利用標準傳輸協議與外部系統進行遠程通信。

使已部署服務能在同一個 JVM 內部相互調用。

服務間可以使用標準的 WS-I （ Web 服務協同工做組織）規範通信。

JBI 的關鍵是分離服務引擎和綁定組件，以便業務邏輯不被下面的具體細節所幹擾。這種方式促進了體系的靈活性和可擴展性。綁定組件和服務引擎組件在JBI 內部均可以是服務提供者和 / 或服務消費者。

綁定組件和服務引擎組件爲「 JBI 運行時」提供接口以便從「 JBI 運行時」接收消息。一樣的，它們也利用 JBI 提供的接口來和「 JBI 運行時」通信。

消息傳輸模型－－歸一化的消息路由器（Normalized Message Exchange）

JBI 利用消息傳輸模型分離服務提供者和服務消費者之間的耦合。消息傳輸模型利用了 WSDL 。 WSDL 用於描述暴露的服務引擎組件和綁定組件的業務處理。另外， WSDL 也用於定義抽象服務處理的傳輸級綁定。

JBI 架構中一個關鍵組件是 NMR （歸一化消息路由器，也譯做「正規消息路由器」）。 NMR 基於 WSDL 提供了主要的消息傳輸中樞， NMR 爲部署在「JBI 運行時」中的服務引擎組件和綁定組件間的消息傳遞提供鬆散耦合。服務須要有聚合業務處理的接口，每一個業務處理由零個或多個消息組成。而一個接口有一個或多個傳輸級綁定。

基於WSDL的消息模型，示意圖以下：