JBI與SCA的差別

最近我在做有關ESB的開發工作，發現我們的産品（開源的Celtix  http://celtix.objectweb.org ） 要支援JBI和SCA兩個标準。這讓我困惑了好久，JBI和SCA有什麼差別呢？

前幾天好好在網上收羅了一番，現在把收獲到的東西和大家分享一下：

JBI definition http://www.theserverside.com/news/thread.tss?thread_id=35053

SCA 與JBI的差別 http://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html

上面的連結有詳細的讨論，我簡單整理了一下。

JBI 的由來

Java One 2005 had a very heavy emphasis on JSR-208, Java Business

Integration. However, he says, "there seemed to be some folks with

confused looks on their faces in some JBI talks." As a response, he's

written a blog entry on what JBI actually is

< http://radio.weblogs.com/0112098/2005/07/07.html#a530 >.

JBI是提供了一些簡單的API定義， 這些定義包括 Normalized

Message Service , 在一個Router元件，以及一個管理模型用來管理服務

的部署內建，例如  routing engines, BPEL engines, rule systems, transformation engines

JBI提供了一個邏輯的XML消息網絡， 這一網絡能夠很容易的映射到

HTTP, email 和 JMS/MOM ，并很友善地适應遺留系統，二進制地傳輸，

和RPC系統（EJB和CORBA)。 JBI可以看做是對JMS的更高層次的邏輯

抽象，并提供了不同的消息交換方式（ 單步， 請求應答等）

什麼是SCA ，它試圖解決什麼樣的問題？

WSDL 在增強應用之間的可連接配接性以及互操作性方面邁出了一大步。

然而，WSDL隻關注了服務接口，它并不提供描述一個服務所依賴的其它服務，

以及這個服務所需要使用的配置政策和服務之間的依賴關系。

單獨通過WSDL 很難實作服務之間的組合調用。

SCA比WSDL走的更遠的方面是定義了一個服務元件模型以及一個服務組裝模型。服務模型提供了比WSDL更多的功能，它允許服務開發者不單定義服務的接 口而且還可以定義 這個服務和其他服務的依賴關系，以及這些互動（事務，安全，以及可靠 傳輸）之間的政策 還有服務所可能提供的配置功能。

一個SCA模型對等于一個SOA項目，模型允許開發者組裝一組服務元件，解決引用依賴和使用政策。這是一個很大的進步，因為目前的SOA平台需要開發者自己擷取那些私有的服務部署引用，甚至有時要在他們的服務實作中寫hard code.

SCA與JBI的差別

SCA的美麗之處在用它關注的重點隻是SOA開發這 所看到和接觸到的。 SCA并沒有關注用來執行SCA子產品的runtime是如何構架的。 這個runtime可以實作為一個将所有的SCA服務元件編譯成為Java classes的醜陋的單一服務，或者是一組子產品化的引擎（每個元件一個的那種），這些引擎可以通過 一個企業服務總線來進行通訊。

JBI從另一個方面來說就是一組關注建立一個開發的，可擴這的以及标準元件的企業服務總線。 這樣它的核心是和SCA有一些重合的地方。同時兩者之間也存在互補的機制。

說它們互補，為什麼不把他們綁定在一起呢。 這裡有兩方面的原因。

第一個原因 是JBI關注的是如果将一組引擎組裝并運作 于一個JVM中。 相反SCA在另一方面并不将一個子產品限制單個JVM中。 一個SCA子產品可以執行在一個JVM中，同時它也可以很友善的将這些引擎部署在不同的程序甚至是不同的節點上。

第二個原因 是 SCA不但支援Java而且還支援C，在今後也許還會支援C#,php。 而JBI隻是SCA的一個實作方式，而不是唯一的選擇。