轉自:http://jnn.blogbus.com/
最近我在做有關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的一個實現方式，而不是唯一的選擇。
====================================================
多少年來，Three Tier的架構似乎已經成為了教科書式的軟件體系范本。它不斷地提高軟件靈活性和高聚合性的，時至今日，當軟件復雜度更上一個數量級的時候，這種體系也開始孕育又一次重生。這就是最近的Buzz Words: SOA，也即SCA + SDO
受CHRIS在BLOG上所托，稍微關注了一下這方面的。
其實SDO已經有比較長的歷史了，IBM去年就在從事該規范相關的開發。
而SCA相對來說更新鮮一些，主要是針對在面向服務的計算環境里，組件的實現方法。同時，它強調了這些組件與現有的平臺，組件之間的關聯，并描述怎樣通過已有的技術、平臺甚至于現有的組件來實現面向服務組件。另外，在將這些服務組件實現以后，它們的接口以及這些接口的語義是怎樣描述的。其實，新的組件描述應該是技術獨立、平臺獨立、語言獨立的，也就是說它是一個開放的規范，這樣就可以讓很多IT廠商在不同的平臺上用不同技術和語言來參考和實現這些技術。
除此之外，面向服務的組件需要相互之間的交互，這種交互應該是松耦合的，也就是說需要打破過去那種緊耦合的現象。因為不管是.NET、J2EE還是更早的CORBA等技術，它們在支持分布式計算時，其組件往往和平臺、語言以及實現技術緊密相關。
過去，如果一個組件要調用另外一個組件的功能，它需要知道后者的接口在什么位置，使用什么協議和消息格式，這往往與其實現技術有直接的關系，所以技術、平臺、語言和位置等各種各樣的因素的透明性對于組件之間的交互就是非常重要的一件事情了，而SCA恰恰就規定了這一部分的內容。
另以方面，SDO其實與SCA是一對具有對應關系的規范。我早先就說過:軟件=服務+數據。SCA更加關注業務邏輯，而SDO則更側重于業務數據。
過去我們所采用的技術中，不管是.NET也好，J2EE也好，它們都有基于自身平臺下的規范，比如在J2EE環境下，我們就會通過JDBC、Entity Bean這樣的方式訪問數據庫或者其它數據源;而在.NET下同樣有類似ADO這樣的方式來訪問各種不同的數據源。這里面的問題在于，平臺透露了太多的技術細節，程序員需要了解很多相關的內容，比如他需要創建一個JDBC或ODBC的數據源，再利用這些規范所提供出來的編程接口來想辦法得到數據源中的數據，為達成這個目標，程序員還需要去做對象-關系映射，以實現對象到關系數據庫或者與之相反的數據轉換。目前有一些技術可以用來解決這些問題，比如前段時間在Java社群中一直都非常流行的Hibernate等，諸如此類的方法和工具很多，他們都是用來協助程序員處理上述工作的。但無論如何，你都無法逃避地要看到很多這些方法中非常底層的技術細節，而且，程序員需要學習所有這些不同的技術，了解它們適應于什么情況，處理各種情況下的不同技術細節。事實上，程序員需要抽象層次更高的東西，比如業務數據對象(Business Object)以及它內部各種細粒度數據對象之間的關聯，這是可以用一致、通用的方式來表示和操作的。有了抽象層次更高的模型，程序員就可以通用的方式來定義和訪問業務數據，從而以統一的方式來描述和訪問不同的數據源，降低對程序員技能的要求，提高生產率，更容易在不同的應用環境交換。
這樣，不管是Java或者C++語言描述下，程序員都不必去了解平臺上的技術細節，用一個XML Schema描述這樣的通用、簡單的的業務數據模型，然后在運行將對象持久化到你的關系數據庫、XML或者其它數據源中。
從技術上看，SDO規范做了如下幾件事情:它定義了一個連接器，可以使用JDBC、ADO等各種不同的方式去和多種數據源交互，數據源也是多種多樣，不單單局限于關系數據庫，也可以是不同類型的XML文件，甚至是內存中的一塊區域。同時它還提供諸如連接池、緩存(Cache)、斷開連接時數據訪問(Disconnected Access)等高級特性，提供了跨越B/S,C/S的邊界。
另外，SDO還定義了一個中介轉換器(Mediator)，它與連接器交互，來完成數據持久化的工作，這個協調器能夠理解我們定義好的Schema，讓程序員能直接看到一個直觀的對象圖表(Object Graph)。它根據業務的語義定義一個完整的Schema，不僅能清晰地定義各種數據對象，而且還能有效地描述各種對象之間的聯系，充分利用了XML強大的自描述能力。通過它，人們可以很方便的操縱數據對象。
綜合起來說，SCA/SDO都是基于已有的技術，它們所要做的就是怎樣在現有技術的基礎上，為異構、分布的松耦合計算環境提供一個統一、開放的組件及其服務的描述。
IBM在其SCA的實現中，也就是WPS 6.0所提供的SCA運行時環境，有多達八種不同的組件實現形式可供選擇。我想更理想的實現應該是提供一個可以擴展的接口。即使在語法上、數據結構上有很大的不同，甚至是某公司自己語義上的東西，也可以方便地納入SOA的架構里。
這樣一個規范目前受到了IT技術主流的技術廠商的支持，它的建立為基于SOA的下一代計算環境下的編程模型打下了一個堅實的基礎。
與古老的CORBA技術(請允許我用這樣的詞來描述它，呵呵～)想比，兩種技術的背后都有很一致的哲學。但是受限于當時的技術發展條件，我們回顧歷史的時候，CORBA在很多細節上的處理并不是太好，而且，CORBA是基于面向對象思想的，與之不同的是SCA基于面向服務的思想，其實抽象程度要相比過去的提高很多。
這里我引用一下Gartner的報告:
- 隨著商業和技術的推動，SOA將成為將來的發展趨勢已經沒有人懷疑了;
- 2007年，超過50%以上的公司將SOA作為IT戰略來考慮;
- 2008年還沒有將SOA引入到公司的IT實現中去，那么該公司將成為一只恐龍，也就是說這個公司很落后了。
目睹這些年軟件的迭代更新，我有時也在想，是不是這就是軟件自己的“摩爾定律”，所不同的是，用來度量軟件的不是單晶片上可以集成的晶體管數，而是單個軟件工程師所能Handle的軟件復雜度，姑且叫它"logic per brain"吧。