相對商業SOA動輒需要投入6到7位數的成本，開源SOA產品的一大賣點就是低廉的價格。然而，這些低成本、功能豐富的平臺通常都是并非針對商業用戶所開發的企業服務總線(ESB)，需要更多的技術專業人員去進行調整。

　　在開源ESB中，Apache ServiceMix、Iona Fuse ESB、JBoss ESB、MuleESB，以及WSO2ESB都是目前的主流，但在進行選擇前，必須先考慮到其功能配置是否能對你公司SOA實施有所幫助，還是平添障礙。

　　ESB是一種基于標準的SOA中樞，它能夠通過服務界面連接應用。通過信息合并、Web服務、XML以及數據傳輸和管理，ESB能可靠連接、調整并控制服務之間的通訊與互動。

　　涉及到技術集成方面，開源ESB提供了與其它商業應用相類似的成效。開源ESB不僅經過完善的測試，在網上建立正式的資料文檔，同時也針對JDBC、SOAP、FTP、HTTP、POP3、TCP、UDP，甚至AS/400等遺留系統帶有一系列的配適器。

　　然而，在階段性實施SOA的過程中，將商業需求與IT基礎架構相結合尤為重要，而這正是開源ESB所無法提供的(至少從目前來看)。雖然IT人員能夠適應XML和Java，但商業人員在開源環境下工作總會面臨著各種困難。商業分析師往往都要視覺化查看流程狀態，對流程運行進行實時變更，或調整服務等級協議，并替換低效的服務。在這方面，商業產品所具備的靈活性帶來了即插即用的架構和對現有服務的再使用。

　　只有當用戶有足夠的XML和Java專業經驗來使用它們時，開源ESB才能提供直觀的成效。比如某公司需要一套系統來接受、驗證和處理網上訂單。在MuleESB里，終端、連接器和路由器都是由XML所定義。在Spring和Mule中，要創建JavaBean和兩個配置文件來接受訂單信息，但文件內容與XML之間的對話，以及驗證訂單數量的正確性，都需要進行額外的Java編碼。然后通過XML來配置Web服務適配器，去處理訂單。

　　因此在某種情況下，商業ESB是最理想的選擇，因為商業分析師能夠在無需額外編碼的前提下，視覺化查看流程狀態。而對于開源產品來說，額外的編程要求和技術專家的支持明顯帶來了不少障礙。

　　測試是一種從開源產品中獲得經驗的有效途徑。只要Web服務被創建，開發人員就能建立小規模用戶群去進行測試，在早期活動(比如SOA試運行階段)中尤其如此。在這方面，Jmeter和SoapUI都提供了相仿的功能，匹配大多數的商業產品，足以完整測試SOA試運行項目。

　　治理上的欠缺

　　相比其它部署模型，SOA要求更多的制度規范，否則公司內的復合應用和Web服務就會過剩，從而降低服務應有的效率。雖然在ESB上的開源產品不在少數，但在SOA治理方面，市場上目前只有MuleGalaxy一種開源產品。不過這并非壞事，因為整個開源社區都會專注于開發并調驗這一個平臺，滿足與其它商業產品相匹配的要求。

　　MuleGalaxy提供了Web管理控制臺工具，如XML、XSD和WSDL文件可以被添加到注冊表中。IT團隊可以運用并加強策略，而用戶也可以管理生命周期和關聯性，并運行報表。該平臺支持自動發現服務，提交到Atom發布界面。此外，它也有類似于商業產品的功能，因此在選擇治理工具時，MuleGalaxy也是一個理想考慮對象。

　　MuleESB特別提供了額外的工具，以訂閱付費的模式來監控、管理、使用和操作。對于那些需要高可用性、高績效和技術支持的公司，可以考慮這一優勢。另外，幾乎所有的開源項目都能獲得開源社區的支持，雖然對企業來說這種方式可能較為低效。

　　與SOA相關的大部分開源產品的成本都會隨著時間、技術等因素的演化而逐步降低。為了有效實施開源ESB，IT團隊必須要準備好去學習框架、組件模型、XML腳本模型，并在Spring和Java上有一定的工作經驗。對于具備專業人才和充裕時間的公司而言，良好的治理和測試功能，靈活的可升級性與可擴展性，讓開源產品成為高成本的商業產品之外的又一選擇。