內蒙古java團隊

激活SOA的全部潛力還需五年。即使用企業服務總線（Enterprise Service Bus，ESB）是實現ESB全部潛力4步中的第三步。模型中的步驟如下： 

使用XML，以更標準的方式使用應用程序接口。 
捕獲一些業務過程，并將它們轉化成為Web服務。 
引入并全面使用企業服務總線。 
產生業務過程執行語言（Business Process Execution Language，BPEL），它可由業務過程建模工具完成。BPEL可以改變應用程序的行為，而無需修改軟件。 
Rippert先生在采訪中表示，盡管很多組織擁有ESB，但是它并沒有被完全利用。他進一步的表示，大多數公司仍處于階段1。與這個ESB所處位置的論斷相對比的是，Burton Group的分析師Anne Thomas Manes的敘述，其發表于近期面向服務架構Yahoo Group的討論中。Anne說： 

......如果缺少我推薦啟動SOA的“基本組件”，ESB將不會列在我的清單中。事實上，我并不鼓勵人們由ESB開始。ESB并不會鼓勵好的SOA行為。ESB本質上是集成系統，而非SOA系統。SOA是用于拆卸應用豎井（application silos），而集成系統則是修補這些豎井。
引用她的書，她接著提及的基本組件包括： 

一個或多個服務平臺（如，.NET，Java EE應用服務器等） 
SOA管理解決方案 
注冊表 
如果服務要被暴露在防火墻之外，那么需要XML網關 
引用組員早期的帖子，她說道： 

“......ESB特別適合橋接傳統應用，因此，在服務基礎設施中，它是一個有用的組件。很多ESB也支持可靠消息傳遞、異步消息傳遞和發布/訂閱交換模式。這些能力都非常有用，但是，在SOA項目的初始階段可能不會發揮多大的用途。（每個組織有很多不選用這些能力的項目。）在SOA項目的后期，你還可能需要一個編制（orchestration）引擎，并且大多數的ESB都會提供一個。即便如此，ESB也絕對不是組織啟動SOA的起點。所有這些能力你一開始并不需要。因此，ESB應該在后期購買。”
這似乎符合Rippert先生的觀點，即盡管很多組織擁有ESB，但是它并沒有被完全利用。Manes女士的評論同樣有助于定義ESB的范圍，通過暗示許多ESB支持的特性，它確定了一組適當的能力。 

根據維基百科的ESB定義，ESB有如下特性： 

它是面向服務架構的實現。 
它通常是操作系統和編程語言無關的；它應能在Java和.Net應用程序之間工作。 
它使用XML（可擴展標識語言）作為標準通信語言。 
它支持Web服務標準。 
它支持消息傳遞（同步、異步、點對點、發布-訂閱）。 
它包含基于標準的適配器（如J2C/JCA），用于集成傳統系統。 
它包含對服務編制（orchestration）和編排（choreography）的支持。 
它包含智能、基于內容的路由服務（itenerary路由）。 
它包含標準安全模型，用于ESB的認證、授權和審計。 
它包含轉換服務（通常是使用XSLT），在發送應用和接收應用之間轉換格式，簡化數據格式和值的轉換。 
它包含基于模式（schema）的驗證，用于發送和接收消息。 
它可以統一應用業務規則，充實其它來源的消息，分拆和組合多個消息，以及處理異常。 
它可以條件路由，或基于非集中策略的消息轉換，即不需要集中規則引擎。 
它可監視不同SLA（服務級別合約）的消息響應門限，以及在SLA中定義的其它特性。 
它（常常）簡化“服務類別”，向更高或更低優先級用戶做出適當的響應。 
它支持隊列，在應用臨時不可用時用來保存消息。 
它由（地理）分布式環境中的選擇性部署應用適配器組成。 
看起來，共識之一是ESB是與編制（orchestration）和業務過程管理（Business Process Management）截然不同的單獨一類產品。此外，對于ESB到底是產品還是模式還有很大的爭議。 

在本系列的第二部分，InfoQ調查了ESB的使用目的 - ESB的使用案例和需求是什么？ 

Sonic公司的Dave Chappell開啟前文中的討論，部分1暗示了Sonic軟件公司可能事實上正試圖標準化基于UML的模式集，實質上，它們定義了ESB的參考架構。 

Stuart Charleton（BEA系統策略咨詢服務的企業架構師，位于Canada的Toronto）提供了以下的使用例子： 

消費者使用基于HTTP/S的認證，生產者使用WS-Security。 
消費者使用HTTP/RSS，生產者使用WebSphere MQ或JMS。 
消費者使用HTTP/REST和URI，生產者使用SOAP/WSDL。 
消費者有一組證書，生產者有另一組（鍵鏈映射）。 
一端使用FTP站點作為“服務接口”，而另一端文件被拆分成JMS消息。 
在路由到目的地之前，消息需要被充實，這樣就可以執行callout來收集額外信息。 
生產者要求協議獨立的負載均衡和/或故障轉移。 
消息需要被存儲轉發，在不可靠服務上改進可靠性。 
同時，作為這些主題的補充，Paul Fremantle（WSO2的共同創建者和技術副總裁）增加道： 

因此，ESB是實現仲裁（mediation）的通信基礎設施。ESB應該有什么樣的拓撲結構呢？我認為它應該是靈活的：你可以將ESB構建為中間層的單個且大的代理，也可是很多智能終端。當然，拓撲結構會影響可管理性，但是只要有配置ESB的中心注冊表/倉庫，那么它將工作很好。這其中的關鍵點是ESB應該由策略而非書寫代碼驅動。
Burton Group的Anne Thomas Manes也說道： 

“......ESB特別適合橋接傳統應用，因此，在服務基礎設施中，它是一個有用的組件。很多ESB也支持可靠消息傳遞、異步消息傳遞和發布/訂閱交換模式。這些能力都非常有用，但是，在SOA項目的初始階段可能不會發揮多大的用途。（每個組織有很多不選用這些能力的項目。）在SOA項目的后期，你還可能需要一個編制（orchestration）引擎，并且大多數的ESB都會提供一個。即便如此，ESB也絕對不是組織啟動SOA的起點。所有這些能力你一開始并不需要。因此，ESB應該在后期購買。”
以上強調將ESB作為橋接傳統應用的手段。Network Computing的近期研究中：調查一組回答者，讓他們使用“從強烈同意到強烈反對”的標準，為一組關于ESB技術的表述評分。回答者強烈同意的前4個表述是： 

ESB必須給企業數據源（SAP、Peoplesoft、Oracle、SQL Server）提供適配器。 
ESB必須至少支持基礎的業務過程管理。 
ESB實現需要支持開放標準（JMS、Web服務）。 
ESB必須與現有的企業應用集成（EAI）和面向消息產品平滑集成。 
這暗示著傳統數據源（如ERP和EAI系統）是ESB的重要接口，并且它們應該將那些應用層作為基于標準的消息暴露。有趣的發現是，終端用戶似乎同意"至少基礎的"業務過程管理是ESB“必須支持的”。 

關于最后的評論，Steve Jones（來自CapGemini）暗示，ESB的問題事實上是3個毫不相關的問題：集成、構建和業務。 

……第一個挑戰是利用現有資產發掘功能（集成），第二個則是構建新的應用（構建），最后則是管理新應用間的交互（業務）。待會兒我將在我的博客中討論這些。 
 

集成產品有很多非常不同的需求，并且驅動力來自于人們想在更面向標準的空間中實現交互，而我不太確定混淆這兩個領域為什么有意義。同樣的，構建新應用（使用過程或面向對象語言）則需要不同的技術和方法。 

集成總線以其能力作為衡量標準，而業務服務總線則在于簡單性和應用開發解決方案的靈活性。并且無論何種合理規模的業務也不會有一勞永逸的解決方案。 
ESB綜述的第二部分期望能幫助定義用戶要求的使用案例，尤其是當他們需要ESB時。共識是：業務過程工具與ESB是不同的，加上ESB包含來自最終用戶的完全相反的興趣，這也暗示著可能將不同種類的產品合并為成了一個。 

欲了解這個討論，請關注適合于ESB的使用案例。