內(nèi)蒙古java團(tuán)隊

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

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

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

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

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

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

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

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

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

Stuart Charleton（BEA系統(tǒng)策略咨詢服務(wù)的企業(yè)架構(gòu)師，位于Canada的Toronto）提供了以下的使用例子： 

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

因此，ESB是實現(xiàn)仲裁（mediation）的通信基礎(chǔ)設(shè)施。ESB應(yīng)該有什么樣的拓?fù)浣Y(jié)構(gòu)呢？我認(rèn)為它應(yīng)該是靈活的：你可以將ESB構(gòu)建為中間層的單個且大的代理，也可是很多智能終端。當(dāng)然，拓?fù)浣Y(jié)構(gòu)會影響可管理性，但是只要有配置ESB的中心注冊表/倉庫，那么它將工作很好。這其中的關(guān)鍵點是ESB應(yīng)該由策略而非書寫代碼驅(qū)動。
Burton Group的Anne Thomas Manes也說道： 

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

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

關(guān)于最后的評論，Steve Jones（來自CapGemini）暗示，ESB的問題事實上是3個毫不相關(guān)的問題：集成、構(gòu)建和業(yè)務(wù)。 

……第一個挑戰(zhàn)是利用現(xiàn)有資產(chǎn)發(fā)掘功能（集成），第二個則是構(gòu)建新的應(yīng)用（構(gòu)建），最后則是管理新應(yīng)用間的交互（業(yè)務(wù)）。待會兒我將在我的博客中討論這些。 
 

集成產(chǎn)品有很多非常不同的需求，并且驅(qū)動力來自于人們想在更面向標(biāo)準(zhǔn)的空間中實現(xiàn)交互，而我不太確定混淆這兩個領(lǐng)域為什么有意義。同樣的，構(gòu)建新應(yīng)用（使用過程或面向?qū)ο笳Z言）則需要不同的技術(shù)和方法。 

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

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