SOA攜手開源軟件 IT行業的未來趨勢
目前最為前沿的IT行業趨勢，第一是面向服務的體系結構(SOA)，第二就是開源軟件。而把SOA與開源軟件的優點相結合，不僅可以降低客戶的IT成本，同時還能敏捷地應對不斷變化的業務需求。
在現有的軟件開發項目里面，一直存在一個沒有辦法解決的問題:業務功能的理解和技術功能的理解是由同一個人負責的，也就是讓同一個人或同一些人完成業務與技術領域的銜接。實際環境中想要找到一個這樣的人是非常不容易的，而如果沒有這個人，軟件開發項目基本就離失敗不遠了，這是IT領域的老問題，也是面向服務的體系結構SOA(Service-Oriented Architecture)要解決的主要問題之一。
SOA限制IT部門考慮采用最佳的組織與能力的組合，從而獲得Web服務、SOA以及BPM技術的全部優勢。就好象一個汽車公司一樣，它不一定有能力發明制造輪胎、發動機、音響等全套的汽車零件。它的音響可能是從A公司批量購買的，它的剎車系統可能是B公司提供的，汽車公司利用了其他零件供應商的服務，來為最終的汽車用戶服務。
在SOA架構中也是這樣，技術人員必須能夠適應從做全部工作到做部分工作，并與他人共同完成整個工作的轉變。與對象或者過程相比，服務的開發應面向一個更為寬廣的環境，因為它被重用的機會更大。實際上，定義可重用的服務也許是SOA中最重要的方面，也是SOA現在如此流行的重要原因。
OSOA規范三架馬車
為了響應客戶需求，IBM、BEA、Oracle、SAP、Primeton等公司正在合作制定用于構建SOA系統的規范，為開發人員提供構造基于SOA應用程序的更簡單更強大方法。目前，制定規范的工作交由這些公司組成的OSOA(Open Service Oriented Architecture)協作組織負責，另外OSOA還負責在Apache推出開源的SCA/SDO實現，用來更快的催化市場的發展。
OSOA目前正在起草一系列的規范，并以免版稅的許可方式提供給業界使用。OSOA的業界伙伴們現在主要在兩個項目上協同工作，分別是SCA(Service Component Architecture，服務構件架構)和SDO(Service Data Objects，服務數據對象)，這兩個項目就象OSOA的兩架馬車一樣，為SOA架構立下了汗馬功勞。根據筆者掌握的最新情報，OSOA正在準備啟動第三架馬車:DAS(Service Data Objects，服務數據對象)。
1.SCA
早在2005年11月，OSOA就發布了SCA 0.9規范草稿。SCA是一種全新的、跟語言無關的編程模型，這種面向服務構件的編程模型可以大大簡化客戶的編程，提高應用的靈活性，將會對現有軟件開發方式產生顛覆性的影響。
2.SDO
SDO致力于為應用系統中處理數據提供統一的方式，而不論數據的來源、格式是什么樣的。SCA和SDO都可以獨自使用，沒有規定說在同一個應用程序中必須同時使用兩種技術。然而SCA和SDO可以結合起來一起使用，從而為采用面向服務的架構搭建應用系統提供一種強有力的、靈活的方式。
3.DAS
DAS是與SDO密切相關的。DAS提供了一種對數據庫和對服務來說統一的數據處理方式，它也提供了相應的機制，用來實現當數據同其來源分離時的處理。DAS設計用于簡化和統一應用程序處理數據的方式。通過使用DAS，應用程序編程人員可以采用統一的方式訪問和操作來自異類數據源的數據，包括關系數據庫、XML數據源、Web服務以及企業信息系統。
開源SOA四將軍
SOA作為新生事物，它的開源實現并不多。就筆者在行業內的了解，目前共有下面四個開源SOA項目，就如同戰場上的將軍一樣，為SOA陣營攻城略地，開拓了不少疆土。
1.大將軍Tuscany
Tuscany是Apache軟件基金會的孵化項目，由在Apache軟件基金會占有重要份量的IBM和BEA主導。Tuscany原本是意大利行政區名，一般中文翻譯為托斯卡納區，這里被借用作為項目名稱。Tuscany的主要目標是為用戶提供一組SOA基礎設施，其中包括Java和C++實現的SCA/SDO/DAS標準。
2.驃騎將軍STP
STP(SOA Tools Platform)項目是Eclipse基金會的重要項目。STP的目標是為技術人員提供一個靈活可擴展的框架，技術人員能夠在這個框架的基礎之上圍繞SOA方便地進行設計、配置、組裝、布署、監控和管理等工作。STP提供相關工具來支持開發人員使用面向服務的體系結構進行解決方案構建，而面向服務的體系結構則使用服務組件體系結構作為其核心模型。
3.左車騎將軍SOA PHP
PECL(PHP Extension Community Library)庫在PHP社區是無人不知無人不曉，不過知道PECL庫新納入的SOA PHP項目的人卻并不多見。SOA PHP項目的主要目標是用PHP來實現SOA中的SCA/SDO標準，這對PHP社區的同志們真是個莫大的福音。
4.右車騎將軍牛頓(Newton)
Newton是一個分布式的運行時框架，用來對企業級環境下復雜的SOA系統做動態的實例化和可持續管理。Newton利用SCA系統描述，對OSGi的組件做動態的布署，由此實現對分布式的異構數據源的監控和管理。
#p#
Tuscany開源架構分析
從以上可以看出，世界上兩大開源軟件基金會(Apache軟件基金會和Eclipse基金會)還有其他的不同社區都已經開始了SOA開源軟件的研發進程。下面將主要討論Tuscany開源項目架構和它在SOA標準化進程中的影響。
1.Tuscany的問題域
問題域是一個軟件產品解決方案的首要目標。BEA Systems CTO辦公室的Jim Marino告訴我們，Tuscany的問題域用一句話概括，就是解決怎么樣來構造和組裝服務的問題。
服務是表示一個業務功能的代碼單元，它可以被客戶端在本地或者遠程定位并構造。服務可以布署在不同的運行環境中，比如可以是J2EE Server，也可以是J2SE客戶端、可以是Servlet容器，也可以是OSGi容器等。
服務可以用不同的程序語言來編寫，然后在異構環境中被組裝。這里的服務和Web Service中的服務有很大區別。Web Service中的服務是用低層級的協議來約束系統間的互操作，而Tuscany中的服務是從高層級的業務組合來屏蔽Web Service中的服務所考慮的問題。Tuscany可以使用Web Service中的技術，但并不限制于它，應該說Tuscany對外封裝了WS-*和RMI等服務調用細節。
用一句話概括就是Web Service描述了服務間的協議，但并沒有描述服務間的關系，而后者正是Tuscany所要做的主要工作之一。
2.Tuscany的Service Network架構
以上面確定的問題域為中心，Tuscany為我們解決了很多現有的技術架構問題。我們用現有的技術架構，在平常的開發中總會碰到如下一些問題:
◆大規模軟件系統的開發和配置的復雜性。
◆缺乏動態性，比如對目標功能服務點的動態切換，這一直是軟件業的一大核心問題。
◆異構環境下的模塊功能不能復制。
◆很難構建一個可平滑地對用戶規模伸縮的系統。比如1999年，Ebay網絡在用戶數急增的情況下，曾經宕機20小時，導致股價下跌9%，損失慘重。
在這樣的情況下，Tuscany在SOA基礎上設計為Service NetWork架構。SCA用來組裝一個服務網絡，而SDO表達了服務網絡內流動的數據，DAS則對這些流動的數據進行統一格式的存儲。
Tuscany的異構Service NetWork架構如圖1所示。從圖中可以看出，在Service NetWork中，業務邏輯是包含在Component(組件)中。Component對外提供服務，一個Component可以引用其他Component提供的服務，還可以依賴于其他Component提供的服務。Component之間的引用或者依賴關系，可以用一定的Policy(策略)表達，比如事務策略、可靠性策略等。
Tuscany的Service NetWork就好比一桌滿漢全席，而Service NetWork中的Component就好比滿漢全席中的108道菜。我們要自己去做一個好吃的菜是很難的，而如果有不同的廚師掌握了不同的菜的手藝，我們就可以自己來從108道菜中挑選我們自己愛吃的菜了。在SOA的軟件開發環境下，顯然“由一個廚師來決定消費者口味”的時代將很快結束。
Tuscany的Service NetWork中的Component是可大可小的，服務可以在本地也可以在遠端。對Java而言，服務實現可以在單個JVM中也可以在多JVM中。還有非常重要的一點，Component是自包含的，Component中還可以包括另外的Component，甚至可以包括本Component。實際上，Service NetWor本身也作為一個Component對待。
3.Tuscany的業務調用流程
在上面的架構下，Tuscany的服務可以用各種各樣的語言來實現，并分布在各種各樣的環境中。它的業務調用流程如下，我們用114撥號進行比對分析:
◆客戶向Tuscany服務發起調用。就好象我們撥打“號碼百事通”一樣，使用的是中國電信的統一服務。
◆Tuscany的綁定功能模塊負責把調用分發到不同的傳輸功能實現。比如“號碼百事通”的座席或者后臺程序會根據您的選擇，把您要問的問題轉發到不同的業務后端去。
◆對應的傳輸功能實現把調用進行傳輸，傳輸方式可能是SOAP/HTTP、JMS、RMI或者AMQP等。比如“號碼百事通”和“攜程網”的通信方式，還有和“螞蟻搬家”的通信方式可能是不同的。
◆Tuscany綁定功能服務模塊收到調用請求，把它轉發給對應的目標服務。“攜程網”收到請求后，把客戶想訂什么酒店轉發到不同的酒店集團。
◆目標服務執行服務功能。不同的酒店集團確認是否還有空房等。
看起來好象和Web Service等差別不大。不過要注意，這里的第五步不需要判斷是否需要返回信息。是否需要返回信息是不同的服務功能已經確定好的，由Tuscany已經實現。
4.Tuscany的內核分析
Tuscany采用微內核加擴展插件的結構。它的工程本身加上全部依賴工程只有4M代碼，而它的可擴展插件都是一個獨立的SCA Component。實際上，它的內核中的bootstrap就是由一系列的Component組成的。 Tuscany對外提供一個非侵入的編程模型，具有自動化配置功能，并且這些配置都是有缺省值的。就如同富捷軟件集團總裁周強說的一樣，Tuscany和射雕英雄傳中的周伯通一樣，已經學會了“左右手互搏”的武功，它的內核和插件就如同自己的左手和右手一樣，互相競爭功能，互相彌補缺憾，恰到好處。
Tuscany的內核被控制在30K行代碼之內。它提供擴展點來提供功能，而且這些功能都是在運行期動態加入的。Tuscany允許多樣化的技術選擇，比如它不會限制你用什么Web Service實現。
Tuscany的內核組成如圖2所示，從圖中可以看出，Tuscany主要由五大部分組成:
◆一個Ioc(Inversion of Control)的單JVM的織入引擎;
◆組件狀態管理容器;
◆策略布署框架;
◆數據訪問服務;
◆依賴管理和SPI管理容器。
5.Tuscany與其他項目的異同
從上面的內核分析可以看出，Tuscany與我們平常知道的項目是完全不同的。Tuscany是基于SCA而實現的，它通過組裝的方法來表達自己的Service NetWork架構概念。它可以用各種各樣的語言比如Java、C++、BPEL來構造組件，并能和已經存在的各種編程模型進行集成，它還提供了一個用來表達服務關聯關系的策略模型。
Tuscany可以布署在J2EE Server上，也可以使用J2EE中的很多技術，Tuscany中的Components也可以用J2EE中的EJB或者JAX-WS實現。不過，Tuscany提供的功能和J2EE是不相同的。Tuscany可以用多種語言實現，包括C++、BPEL和PHP等。和J2EE相比，Tuscany對業務子系統間的通信做了更好的抽象，在J2EE中，必須確定系統哪里需要一個Web Service或EJB;但Tuscany可以容許你在后面才決定這里是一個Web Service或者是一個POJO。Tuscany中的服務還可以是輕量級的實現。
Tuscany所做的事情和JBI(Java Business Integration)也不相同。對于中間件供應商而言，JBI是在NMR(Normalized Message Router)的基礎上，把SPI(Server Provider Interface)標準化了。Tuscany沒有NMR的概念，而是使用點對點的織入模型，用來起到“服務交換機”的作用。和SPI一樣，Tuscany也有一個擴展模型，但它主要是針對服務開發者和服務組裝者而設置。
Tuscany目前已經發展成為了SOA的試金石，在OSOA等開放組織的帶領下，它將為我們發現更多的金礦，相信隨著OSOA的不斷發展，Tuscany這樣的開源SOA產品將取得更輝煌的成功。
【編輯推薦】
