轉(zhuǎn)自:http://jnn.blogbus.com/
最近我在做有關(guān)ESB的開發(fā)工作，發(fā)現(xiàn)我們的產(chǎn)品（開源的Celtix http://celtix.objectweb.org） 要支持JBI和SCA兩個(gè)標(biāo)準(zhǔn)。這讓我困惑了好久，JBI和SCA有什么區(qū)別呢？
前幾天好好在網(wǎng)上收羅了一番，現(xiàn)在把收獲到的東西和大家分享一下：
JBI definition http://www.theserverside.com/news/thread.tss?thread_id=35053
SCA 與JBI的區(qū)別 http://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html
上面的鏈接有詳細(xì)的討論，我簡單整理了一下。
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 , 在一個(gè)Router組件，以及一個(gè)管理模型用來管理服務(wù)
的部署集成，例如 routing engines, BPEL engines, rule systems, transformation engines
JBI提供了一個(gè)邏輯的XML消息網(wǎng)絡(luò)， 這一網(wǎng)絡(luò)能夠很容易的映射到
HTTP, email 和 JMS/MOM ，并很方便地適應(yīng)遺留系統(tǒng)，二進(jìn)制地傳輸，
和RPC系統(tǒng)（EJB和CORBA)。 JBI可以看做是對JMS的更高層次的邏輯
抽象，并提供了不同的消息交換方式（ 單步， 請求應(yīng)答等）
什么是SCA ，它試圖解決什么樣的問題？
WSDL 在增強(qiáng)應(yīng)用之間的可連接性以及互操作性方面邁出了一大步。
然而，WSDL只關(guān)注了服務(wù)接口，它并不提供描述一個(gè)服務(wù)所依賴的其它服務(wù)，以及這個(gè)服務(wù)所需要使用的配置策略和服務(wù)之間的依賴關(guān)系。
單獨(dú)通過WSDL 很難實(shí)現(xiàn)服務(wù)之間的組合調(diào)用。
SCA比WSDL走的更遠(yuǎn)的方面是定義了一個(gè)服務(wù)組件模型以及一個(gè)服務(wù)組裝模型。
服務(wù)模型提供了比WSDL更多的功能，它允許服務(wù)開發(fā)者不單定義服務(wù)的接口而且還可以定義 這個(gè)服務(wù)和其他服務(wù)的依賴關(guān)系，以及這些交互（事務(wù)，安全，以及可靠 傳輸）之間的策略 還有服務(wù)所可能提供的配置功能。
一個(gè)SCA模型對等于一個(gè)SOA項(xiàng)目，模型允許開發(fā)者組裝一組服務(wù)組件，解決引用依賴和使用策略。這是一個(gè)很大的進(jìn)步，因?yàn)楫?dāng)前的SOA平臺需要開發(fā)者自己獲取那些私有的服務(wù)部署引用，甚至有時(shí)要在他們的服務(wù)實(shí)現(xiàn)中寫hard code.
SCA與JBI的區(qū)別
SCA的美麗之處在用它關(guān)注的重點(diǎn)只是SOA開發(fā)者所看到和接觸到的。
SCA并沒有關(guān)注用來執(zhí)行SCA模塊的runtime是如何構(gòu)架的。
這個(gè)runtime可以實(shí)現(xiàn)為一個(gè)將所有的SCA服務(wù)組件編譯成為Java classes的丑陋的單一服務(wù)，或者是一組模塊化的引擎（每個(gè)組件一個(gè)的那種），這些引擎可以通過一個(gè)企業(yè)服務(wù)總線來進(jìn)行通訊。
JBI從另一個(gè)方面來說就是一組關(guān)注創(chuàng)建一個(gè)開發(fā)的，可擴(kuò)這的以及標(biāo)準(zhǔn)組件的企業(yè)服務(wù)總線。 這樣它的內(nèi)核是和SCA有一些重合的地方。同時(shí)兩者之間也存在互補(bǔ)的機(jī)制。
說它們互補(bǔ)，為什么不把他們綁定在一起呢。這里有兩方面的原因。
第一個(gè)原因 是JBI關(guān)注的是如果將一組引擎組裝并運(yùn)行 于一個(gè)JVM中。 相反SCA在另一方面并不將一個(gè)模塊約束單個(gè)JVM中。 一個(gè)SCA模塊可以執(zhí)行在一個(gè)JVM中，同時(shí)它也可以很方便的將這些引擎部署在不同的進(jìn)程甚至是不同的節(jié)點(diǎn)上。
第二個(gè)原因 是SCA不但支持Java而且還支持C，在今后也許還會(huì)支持C#,php。 而JBI只是SCA的一個(gè)實(shí)現(xiàn)方式，而不是唯一的選擇。
====================================================
多少年來，Three Tier的架構(gòu)似乎已經(jīng)成為了教科書式的軟件體系范本。它不斷地提高軟件靈活性和高聚合性的，時(shí)至今日，當(dāng)軟件復(fù)雜度更上一個(gè)數(shù)量級的時(shí)候，這種體系也開始孕育又一次重生。這就是最近的Buzz Words: SOA，也即SCA + SDO
受CHRIS在BLOG上所托，稍微關(guān)注了一下這方面的。
其實(shí)SDO已經(jīng)有比較長的歷史了，IBM去年就在從事該規(guī)范相關(guān)的開發(fā)。
而SCA相對來說更新鮮一些，主要是針對在面向服務(wù)的計(jì)算環(huán)境里，組件的實(shí)現(xiàn)方法。同時(shí)，它強(qiáng)調(diào)了這些組件與現(xiàn)有的平臺，組件之間的關(guān)聯(lián)，并描述怎樣通過已有的技術(shù)、平臺甚至于現(xiàn)有的組件來實(shí)現(xiàn)面向服務(wù)組件。另外，在將這些服務(wù)組件實(shí)現(xiàn)以后，它們的接口以及這些接口的語義是怎樣描述的。其實(shí)，新的組件描述應(yīng)該是技術(shù)獨(dú)立、平臺獨(dú)立、語言獨(dú)立的，也就是說它是一個(gè)開放的規(guī)范，這樣就可以讓很多IT廠商在不同的平臺上用不同技術(shù)和語言來參考和實(shí)現(xiàn)這些技術(shù)。
除此之外，面向服務(wù)的組件需要相互之間的交互，這種交互應(yīng)該是松耦合的，也就是說需要打破過去那種緊耦合的現(xiàn)象。因?yàn)椴还苁?NET、J2EE還是更早的CORBA等技術(shù)，它們在支持分布式計(jì)算時(shí)，其組件往往和平臺、語言以及實(shí)現(xiàn)技術(shù)緊密相關(guān)。
過去，如果一個(gè)組件要調(diào)用另外一個(gè)組件的功能，它需要知道后者的接口在什么位置，使用什么協(xié)議和消息格式，這往往與其實(shí)現(xiàn)技術(shù)有直接的關(guān)系，所以技術(shù)、平臺、語言和位置等各種各樣的因素的透明性對于組件之間的交互就是非常重要的一件事情了，而SCA恰恰就規(guī)定了這一部分的內(nèi)容。
另以方面，SDO其實(shí)與SCA是一對具有對應(yīng)關(guān)系的規(guī)范。我早先就說過:軟件=服務(wù)+數(shù)據(jù)。SCA更加關(guān)注業(yè)務(wù)邏輯，而SDO則更側(cè)重于業(yè)務(wù)數(shù)據(jù)。
過去我們所采用的技術(shù)中，不管是.NET也好，J2EE也好，它們都有基于自身平臺下的規(guī)范，比如在J2EE環(huán)境下，我們就會(huì)通過JDBC、Entity Bean這樣的方式訪問數(shù)據(jù)庫或者其它數(shù)據(jù)源;而在.NET下同樣有類似ADO這樣的方式來訪問各種不同的數(shù)據(jù)源。這里面的問題在于，平臺透露了太多的技術(shù)細(xì)節(jié)，程序員需要了解很多相關(guān)的內(nèi)容，比如他需要?jiǎng)?chuàng)建一個(gè)JDBC或ODBC的數(shù)據(jù)源，再利用這些規(guī)范所提供出來的編程接口來想辦法得到數(shù)據(jù)源中的數(shù)據(jù)，為達(dá)成這個(gè)目標(biāo)，程序員還需要去做對象-關(guān)系映射，以實(shí)現(xiàn)對象到關(guān)系數(shù)據(jù)庫或者與之相反的數(shù)據(jù)轉(zhuǎn)換。目前有一些技術(shù)可以用來解決這些問題，比如前段時(shí)間在Java社群中一直都非常流行的Hibernate等，諸如此類的方法和工具很多，他們都是用來協(xié)助程序員處理上述工作的。但無論如何，你都無法逃避地要看到很多這些方法中非常底層的技術(shù)細(xì)節(jié)，而且，程序員需要學(xué)習(xí)所有這些不同的技術(shù)，了解它們適應(yīng)于什么情況，處理各種情況下的不同技術(shù)細(xì)節(jié)。事實(shí)上，程序員需要抽象層次更高的東西，比如業(yè)務(wù)數(shù)據(jù)對象(Business Object)以及它內(nèi)部各種細(xì)粒度數(shù)據(jù)對象之間的關(guān)聯(lián)，這是可以用一致、通用的方式來表示和操作的。有了抽象層次更高的模型，程序員就可以通用的方式來定義和訪問業(yè)務(wù)數(shù)據(jù)，從而以統(tǒng)一的方式來描述和訪問不同的數(shù)據(jù)源，降低對程序員技能的要求，提高生產(chǎn)率，更容易在不同的應(yīng)用環(huán)境交換。
這樣，不管是Java或者C++語言描述下，程序員都不必去了解平臺上的技術(shù)細(xì)節(jié)，用一個(gè)XML Schema描述這樣的通用、簡單的的業(yè)務(wù)數(shù)據(jù)模型，然后在運(yùn)行將對象持久化到你的關(guān)系數(shù)據(jù)庫、XML或者其它數(shù)據(jù)源中。
從技術(shù)上看，SDO規(guī)范做了如下幾件事情:它定義了一個(gè)連接器，可以使用JDBC、ADO等各種不同的方式去和多種數(shù)據(jù)源交互，數(shù)據(jù)源也是多種多樣，不單單局限于關(guān)系數(shù)據(jù)庫，也可以是不同類型的XML文件，甚至是內(nèi)存中的一塊區(qū)域。同時(shí)它還提供諸如連接池、緩存(Cache)、斷開連接時(shí)數(shù)據(jù)訪問(Disconnected Access)等高級特性，提供了跨越B/S,C/S的邊界。
另外，SDO還定義了一個(gè)中介轉(zhuǎn)換器(Mediator)，它與連接器交互，來完成數(shù)據(jù)持久化的工作，這個(gè)協(xié)調(diào)器能夠理解我們定義好的Schema，讓程序員能直接看到一個(gè)直觀的對象圖表(Object Graph)。它根據(jù)業(yè)務(wù)的語義定義一個(gè)完整的Schema，不僅能清晰地定義各種數(shù)據(jù)對象，而且還能有效地描述各種對象之間的聯(lián)系，充分利用了XML強(qiáng)大的自描述能力。通過它，人們可以很方便的操縱數(shù)據(jù)對象。
綜合起來說，SCA/SDO都是基于已有的技術(shù)，它們所要做的就是怎樣在現(xiàn)有技術(shù)的基礎(chǔ)上，為異構(gòu)、分布的松耦合計(jì)算環(huán)境提供一個(gè)統(tǒng)一、開放的組件及其服務(wù)的描述。
IBM在其SCA的實(shí)現(xiàn)中，也就是WPS 6.0所提供的SCA運(yùn)行時(shí)環(huán)境，有多達(dá)八種不同的組件實(shí)現(xiàn)形式可供選擇。我想更理想的實(shí)現(xiàn)應(yīng)該是提供一個(gè)可以擴(kuò)展的接口。即使在語法上、數(shù)據(jù)結(jié)構(gòu)上有很大的不同，甚至是某公司自己語義上的東西，也可以方便地納入SOA的架構(gòu)里。
這樣一個(gè)規(guī)范目前受到了IT技術(shù)主流的技術(shù)廠商的支持，它的建立為基于SOA的下一代計(jì)算環(huán)境下的編程模型打下了一個(gè)堅(jiān)實(shí)的基礎(chǔ)。
與古老的CORBA技術(shù)(請?jiān)试S我用這樣的詞來描述它，呵呵～)想比，兩種技術(shù)的背后都有很一致的哲學(xué)。但是受限于當(dāng)時(shí)的技術(shù)發(fā)展條件，我們回顧歷史的時(shí)候，CORBA在很多細(xì)節(jié)上的處理并不是太好，而且，CORBA是基于面向?qū)ο笏枷氲模c之不同的是SCA基于面向服務(wù)的思想，其實(shí)抽象程度要相比過去的提高很多。
這里我引用一下Gartner的報(bào)告:
- 隨著商業(yè)和技術(shù)的推動(dòng)，SOA將成為將來的發(fā)展趨勢已經(jīng)沒有人懷疑了;
- 2007年，超過50%以上的公司將SOA作為IT戰(zhàn)略來考慮;
- 2008年還沒有將SOA引入到公司的IT實(shí)現(xiàn)中去，那么該公司將成為一只恐龍，也就是說這個(gè)公司很落后了。
目睹這些年軟件的迭代更新，我有時(shí)也在想，是不是這就是軟件自己的“摩爾定律”，所不同的是，用來度量軟件的不是單晶片上可以集成的晶體管數(shù)，而是單個(gè)軟件工程師所能Handle的軟件復(fù)雜度，姑且叫它"logic per brain"吧。