JBI与SCA的区别
http://jnn.blogbus.com/logs/2010052.html
版權聲明:轉載時請以超鏈接形式標明文章原始出處和作者信息及本聲明
http://jnn.blogbus.com/logs/2010052.html
最近我在做有關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的一個實現方式,而不是唯一的選擇。
?
總結
以上是生活随笔為你收集整理的JBI与SCA的区别的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: SCA (Service Compone
- 下一篇: ServiceMix中文教程