close
| SOA的概念約在2003年中開始受到關注，2004年是孕育期，2005年則進入成長期，到了2006年進入整合期。透過Google Trends，我們可以看出SOA及ESB（Enterprise Service Bus，企業服務匯流排）這幾年來的成長狀況。 圖一中綠底黑色數字代表SOA相關開源專案的創立或發表時間 (當然這裡只列舉一些較受關注的)。我們隱約可以看出，在各個開放源碼的SOA專案如火如荼推出之際，也正是SOA的熱度向上攀升之時。
孕育期 2004年SOA的孕育階段，主要有2個ESB的開放源碼專案： 1.Mule ESB：這可能是開放源碼界最早成立的ESB專案。它的強項是不用更改既有系統，直接透過組態設定，就可連接各服務端點。創立者Ross Mason的說法，他在2001年就開始構思，而於2003年將它轉變成開源專案。
2.XFire：輕量級的SOAP開放源碼框架，支援以POJO和Schema的方式開發Web Services。由於底層透過StAX處理SOAP資訊，性能優越。除了能夠與Spring整合外，還可透過JBI (Java Business Integration)元件，與JBI容器如ServiceMix、PEtALS整合。 成長期 2005年隨著支援SOA實作的各項標準開始出現，開放源碼也開始蓬勃發展，有多個專案在此時出現： 1. ServiceMix：創立於2005年6月。由於它在開發不久就正巧遇上JBI的規範審議，因此 ServiceMix團隊便決定以JBI規範重新打造核心。在JBI發佈1.0-M1版本時，ServiceMix宣稱它是第一個以JBI為基礎開發的開放源碼ESB。 2.LogicBlaze FUSE：這是 ServiceMix 的加強版，提供商業化的支援。 3.Sun Open ESB：昇陽在2005年JavaOne開發者大會結束後，成立的專案，提供JBI的參考實作。 4.IONA Celtix：座落於ObjectWeb開放源碼組織的一套ESB專案，它運用JMS作為底層平臺，包含了JAX-WS2.0的實作，可與JBI及SCA協同運作，並提供API擴充介面。 5.Apache Synapse：由Apache推出的應用程式整合，以中介Web Services為主。 6.Eclipse STP：SOA Tools Platform（STP），簡而言之，就是一個可運用於Eclipse的SOA基礎工具擴充套件。除了可供SOA開發人員直接使用外，它的基礎開發框架支援SOA的軟體設計、配置、組裝、部署、監控，以及SOA相關的管理，可作為其他工具開發廠商的SOA開發環境實作參考。 7.JBoss JEMS：JBoss公司所推出的企業中介軟體套件，幾乎把所有JBoss的產品全放上去了。 8.PEtALS ESB：此專案由ObjectWeb發起，使用JBI容器作為核心元件，特色是支援動態的分散式ESB部署，且具有中央控管的能力。 9.Apache Tuscany：此專案尚在Apache孵育。實作由IBM、BEA等幾家大廠所提議的SCA、SDO（Service Data Object）及DAS（Data Access Services）規範。值得一提的是，昇陽也在2006年7月初加入SCA/SDO國際構件標準組織。 整合期 時序進入2006年，開放源碼的專案開始相互整合，由於開放源碼的SOA專案均遵循標準，整合性佳，而透過不同專案元件間的相互引用，可達到「螞蟻雄兵」的效果，建構出完整的解決方案。在這一年出現的SOA專案有： 1. JBoss ESB：由JBoss公司推出的開放源碼ESB套件。JBoss內部本有一個ESB專案，在2006年6月又收購Rosetta ESB，並開始兩者的合併。 2.Apache CXF：結合XFire及Celtix兩大專案，企圖在效能與標準間取得最好的支援。透過JBI元件，Apache CXF可與JBI容器整合，作為ESB的傳輸層。 3.ChainBuilder ESB：遵從JBI技術規範，採用ServiceMix作為ESB核心元件。特色是包含一個圖形化的服務流程匯編工具，可在Eclipse內使用。 4.NetBeans與NetBeans Enterprise Pack：Netbeans 自從 5.5 版後，即可透過 NetBeans Enterprise Pack 開發及部署以 JBI 為核心的 SOA 服務組件。
開放源碼專案向來有一種逐人氣而居的傾向，也講究品牌認同。Apache可說是開放源碼平臺的金字招牌，始終是其他專案心所嚮往的地方。
筆者認為整體上而言，由ObjectWeb所發展的開放源碼專案，具有技術領先的特質。例如當今正熱的OSGi （Eclipse所採的plug-ins架構），數年前在ObjectWeb就有對應的Oscar專案。其他還有支援AOP（Aspect-oriented Programming）的JAC應用程式伺服器，支援網格運算的ProActive專案。就連支援JBI的PEtALS，也是公認動態性及分散式運算能力最佳的ESB環境。 而著重於發展Java、高素質的元件化專案的CodeHaus，同樣是開放源碼平臺，總體而言，令人有耳目一新、品質精良的感覺。比較著名的專案包括Boo .NET手稿語言、Groovy Java手稿語言、Mule ESB、XFire Web Services套件、Drools規則引擎，以及Jetty應用程式伺服器等。 開放源碼的聯姻，公開標準來做媒 傳統上開放源碼專案給人的印象，就是由開發人員製造出來，給另一群開發人員使用的東西。這樣的東西可能功能簡易，使用介面陽春。但在SOA的世界中，情況可能完全逆轉。此話怎講呢？ 首先，目前業界導入SOA最成功的方式，莫過於透過ESB把企業內的各級系統服務化，再加以整合。當初昇陽為了防止過去EAI（Enterprise Application Integration，企業資訊整合）解決方案遭廠商鎖死，無法遷移平臺的弊病，再度發生於ESB，於是遂在JCP內發起JBI（Java Business Integration，Java商業整合）規範，也就是JSR 208。 基本上，JBI規範了一組元件化的SPI（System Programming Interface），以實作出ESB容器架構。也就是說，只要遵守此規範的ESB容器，理論上各部元件，包括服務引擎及繫結元件，都是可以拆解開、部署到別的ESB容器內。 這事對開放源碼專案有何影響？有「識」之士 （如ServiceMix的創建者James Strachan）立即抓住這個契機，直接以JBI規範打造ESB容器的核心。有如ESB版的Eclipse，各種JBI元件均爭相外掛（Plug In）到ServiceMix。
SOA與開放源碼最速配 至此整個開放源碼SOA社群的不同專案，開始慢慢由競爭走向融合。不同的ESB執行期、傳輸層 （如 SOAP、JMS），以及執行商業邏輯的服務引擎，開始彼此借力使用，互通有無。 例如，ServiceMix的強項在JBI核心環境，那麼它就可與Axis、CXF等Web Services專案互補，將Axis及CXF透過JBI元件介面與ServiceMix核心環境整合。 另外像Mule ESB的強項，在於擁有為數眾多的Provider（如JMS、JDBC、TCP、UDP、Multicast、HTTP、Servlet、SMTP、POP3、File、XMPP等），可與各式系統連接，但它目前並不像ServiceMix一樣具有JBI核心環境。若要筆者為它選擇一個聯姻的對象，建議是來自ObjectWeb的PEtALS。因為PEtALS的JBI容器環境甚佳，具分散部署、集中控管的能力，正好可彌補Mule ESB的不足。 當初不看好JBI或是來不及加入JBI特性的專案，現在也急著想再回頭（或從頭）加入JBI特性。例如Mule ESB已經開始開發Mule-JBI，他們想利用既有Mule架構實作JBI規範。而JBoss ESB開發經理Mark Little 雖認為JBI 只不過是SOA整塊拼圖的一部分，但也視實作JBI為涅槃（離苦得樂之道）。 由於JBI廣為開放源碼接受，讓整個社群變成一個分散式的元件工廠。我們可以把開放源碼社群看作是一家「開放源碼SOA元件無限公司」。只要授權得宜，彼此可以共享程式碼。 開放源碼SOA專案的未來值得期待 開放源碼是一股無法遏止的潮流。根據一項調查，Eclipse在2004年以56.2%拿下使用率最高的Java整合開發環境寶座，離其成立的2001年，也不過3年光景。Eclipse的成功，來自於開放源碼以及可擴充的外掛架構，而這些特色正好與開放源碼SOA專案符合。 開放源碼與商業化軟體廠商，在SOA領域各有強項，何者是適當的選擇，得視企業應用的層面決定。筆者將SOA的應用分成三個面向來看：企業應用系統整合、IT架構與商業運作校準、與產品開發。 SOA整合應用系統，保障既有投資 這是運用SOA架構思維最簡易的方式。通常企業會導入中介軟體ESB，作為協定異質系統訊息的媒介。更進一步，ESB可匯集各服務端點，透過流程匯編的功能，將基礎服務匯編為功能更複雜的業務服務。 將SOA解決方案應用於整合企業應用系統，最有利於保障既有投資。透過引入開放源碼ESB，系統的整體架構可採用漸進的更新手法：逐步將既有應用系統內部的功能轉為服務揭露出來，再一步步透過ESB加以整合。 在整合的過程中若發現缺少某個配方，再到開放源碼社群採藥。例如缺少傳輸層，就加入Axis或XFire作為繫結元件；若想善用POJO提供服務，就加入Spring Framework作為服務引擎；要是效能不佳，那麼就再加入一些實體節點，而這些完全沒有商業軟體授權費的問題。 而開放源碼專案在企業應用整合仍有不足之處。由於各系統在設計之初並沒有經過統一的考量，可能各系統中存在著重複的功能（例如客戶關係管理、企業資源規劃或專案管理系統中，均可能具備連絡人名單管理的功能），因此，僅靠ESB整合後的IT系統，並非最佳化的系統，而且散落於各系統的資訊也難以同步。 因此長遠來看，導入ESB之後，仍要朝下一個目標「IT 架構與商業運作校準」前進，將整個企業的IT架構轉換為SOA模式。 IT 架構與商業運作校準 這是導入SOA架構的終極目標。要將SOA的應用提升到此一層級，通常會依照廠商所提供的方法論規畫與導入。例如建立商業能力模型與IT服務能力模型，由上而下地找出支援企業核心流程所需的服務，作為未來調整與修正的藍圖，然後依此藍圖逐步完成建模與建置。 「IT架構與商業運作校準」是商業化軟體廠商SOA整體解決方案的強項。就許多開放源碼SOA解決方案來說，相對的比較無法找到相關教育訓練或顧問單位。筆者認為，以當前的情勢要在企業內透過開放源碼專案SOA專案達到此一層級，將面臨較大的挑戰。 以SOA架構產品，建置鬆散耦合的模組 對軟體開發廠商而言，在授權條件許可下，我們可將SOA架構概念用於開發自有產品，促使系統更加模組化、產品模組間的耦合更為鬆散。產品內部鬆散耦合的好處，在於開發廠商可以提供客戶更多樣的部署選項。當客戶挑選好需要的模組後，廠商才開始封裝產品。 另外，還必須提供一些機制，讓系統內的功能可以動態開放，以服務的方式呈現，使其他系統能更易於與此產品互動。 應用SOA在產品開發有兩派觀點：畫分元件實作層次與服務流程組裝層次 透過這種方式，元件的實作與服務的開放便成為兩個層次。我們可以依照過去習慣的開發方式，以 POJO+Spring Framework或是EJB實作服務元件，然後將流程匯編的工作交給ESB的BPEL或Script引擎處理。 對於既有程式碼，只需想辦法開放它的服務介面，就可以納入ESB統一管理，如此便可以有效保障既有開發成品及技術投資。此時你可採用Mule ESB或ServiceMix作為主架構，元件化過去的產品，立即得到所有系統整合上的便利性。 將SOA概念作為服務元件的模型 將SOA概念作為服務元件的模型，也就是說，不論是元件的實作與服務的組裝，均採一致的架構。當前支援此套思想最徹底的元件模型，當屬IBM與 BEA等幾家大廠共推的服務元件架構（Service Component Architecture，SCA），而開放源碼的實作則為Apache Tuscany及Fabric3專案。
透過SCA服務元件架構，我們可以很容易地設定服務與元件之間的對應，以及服務與服務間之參引關係。將SCA的概念與模組設定檔比較，當更容易了解意涵。 至於服務元件實作的部分，則採用POJO的作法，相當容易撰寫。值得一提的是，除了Java語言外，SCA還支援了不同的程式語言及程式設計模式。SCA的服務元件及用戶端可用Java、Groovy、BPEL、C++、PHP、Python和Ruby等各種語言，以及POJO、EJB和Spring等各種程式設計模式實作。
|
全站熱搜
留言列表
