SOA的開源大勢(終)開放源碼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等各種程式設計模式實作。

《作者簡介》謝鎮澤
現任UniMiner產品開發經理，從事Java分散式系統開發多年，曾任2006年JavaTwo專業技術大會「SOA之原則、設計與實務」場次講師

相關閱讀：
SOA的開源大勢(1)開放源碼SOA專案低調進入應用階段
SOA的開源大勢(2)開源SOA專案的遷徙與合併