引言
ESB作為SOA的基礎(chǔ)設(shè)施，在構(gòu)建SOA的過程中起著舉足輕重的作用，本文是ESB系列文章中的第二篇。在第一篇文章中，作者對ESB的基礎(chǔ)知識進行了詳細(xì)的介紹，本文將著重對IBM最新的應(yīng)用服務(wù)器WebSphere 6中對ESB的支持進行實例化的介紹，希望通過具體的例子讓讀者更快，更方便的利用WebSphere 6的提供的基礎(chǔ)設(shè)施向SOA(Service Oriented Architecture)進行遷移。
為了使本文更具有普遍性，在本文的樣例中，作者模擬了一般可能出現(xiàn)的場景并給出了具體的討論和實現(xiàn)。通過本文，讀者最終可以自己利用WebSphere 6的SIBus實現(xiàn)ESB, 而本文所有的源代碼和腳本將會提供給讀者作為詳細(xì)的參考。同時，本文中涉及的許多概念和基本操作流程本文所列的參考資料中都有詳細(xì)介紹，本文就不再詳細(xì)解釋了。
1. 應(yīng)用樣例簡介
本樣例是一個簡化了的零部件價格查詢模塊，通常，一個制造企業(yè)所需要的零配件可能來自各個廠商，也有可能是自己制造的，同時，它所制造的零件也可能被它的內(nèi)部用戶或者外部用戶來查詢。由于零件的價格變化比較頻繁，所以這些價格的查詢需要是即時的價格。下面是這個樣例的Use case圖：
2. 利用WebSphere 6中的SIBus實現(xiàn)ESB
在本樣例中，零部件的供應(yīng)廠商的變化是頻繁的，各個廠商的報價系統(tǒng)有可能是多種多樣的，而且本模塊還需要為企業(yè)內(nèi)，企業(yè)外的客戶進行服務(wù)，如何構(gòu)造一個靈活的，可擴展的體系結(jié)構(gòu)來適應(yīng)復(fù)雜變化的環(huán)境已達到隨需應(yīng)變的需求？SOA是解決這個問題的好方法！
首先，我們需要用WSDL來定義零部件價格查詢的服務(wù)，這個WSDL文件相當(dāng)于一個契約(Contract)，它定義了這個服務(wù)的具體交互方式，所有的服務(wù)請求者和服務(wù)提供者都遵循這個契約，但是具體服務(wù)的實現(xiàn)方式，交互協(xié)議并不需要緊耦合在WSDL中，而且作為SOA的目標(biāo)之一，使用者是無需知道服務(wù)者的端點地址和綁定方式的。
接著，我們需要把這個服務(wù)架構(gòu)在ESB上。在SOA中，ESB是不可缺少的，核心的基礎(chǔ)設(shè)施，因為服務(wù)將最終在其上進行整合。WebSphere 6中全新的Service Integration Bus(SIBus)組件是實現(xiàn)ESB概念良好的選擇，它的提出是為了更明確的為服務(wù)集成，服務(wù)整合提供支持，關(guān)于SIBus中的一些基本概念和它的配置、管理，用戶可以從WAS6 Info Center得到幫助，本文將注重如何利用SIBus來實現(xiàn)ESB的基本功能。
首先我們來看看在SIBus上，我們怎么架構(gòu)這個應(yīng)用，為了使讀者有個整體的把握，我們先來看看整體的架構(gòu)圖：
下面就讓我們來看看SIBus為實現(xiàn)ESB都做了哪些基礎(chǔ)工作，每個基礎(chǔ)工作又都為我們的樣例應(yīng)用提供了怎樣的支持：
- 整合內(nèi)部和外部服務(wù)
從這個框架中，我們可以看到，不管是外部服務(wù)還是內(nèi)部服務(wù)，我們都把它們抽象成與端點地址和綁定方式無關(guān)的，統(tǒng)一的一個入口點: 服務(wù)目標(biāo)(Service Destination)，由它來在SIBus中代表零件查詢這個服務(wù)。各個具體的服務(wù)提供者在SIBus中抽象成端口目標(biāo)(Port Destination)，由它來代表一個具體的綁定方式和服務(wù)訪問點。SIBus為端口目標(biāo)提供了多種綁定方式的支持，從而使它可以以HTTP(S), (Secure)JMS的方式的傳輸Web Service請求，對WS-Security和JAX-RPC Handler的配置都可以在端口目標(biāo)級別進行，以適應(yīng)各個服務(wù)提供者不同的要求。這樣一個整合的過程在SIBus中是通過新建一個出站服務(wù)的方式來完成(Outbound)。
- 對外發(fā)布內(nèi)部的服務(wù)
對外部用戶，我們把對服務(wù)目標(biāo)的訪問通過綁定在某個End Point Listener上來間接的提供，這樣一個過程在SIBus中是通過新建一個入站服務(wù)的方式來完成(Inbound)。這樣做的好處是統(tǒng)一了外部用戶的訪問點，方便了我們的管理，更好的安全性和更方便的性能調(diào)優(yōu)。當(dāng)外部用戶需要訪問某個入站服務(wù)的時候，他可以通過入站服務(wù)發(fā)布的WSDL來獲得具體的訪問地址和綁定方式。
- 企業(yè)內(nèi)部對內(nèi)部服務(wù)直接的訪問
對于企業(yè)內(nèi)部的用戶，我們讓他們通過API Attach的方式來訪問我們抽象出的出站服務(wù)。這種API Attach的方式使企業(yè)內(nèi)部客戶可以通過標(biāo)準(zhǔn)JSR 109規(guī)定的方法來直接訪問出站服務(wù)所對應(yīng)的服務(wù)目標(biāo)，SIBus為此提供了專有的綁定，這種方式比通過End Point Listeners的方式有著更高的效率，從而更適合內(nèi)部用戶使用。
- 消息靈活的中介
SIBus提供了消息中介的基礎(chǔ)框架和編程模型，用戶可以在SIBus上定制各種消息處理機制，SIBus為消息中介提供足夠的信息讓它來進行各種有效的工作。在本文的樣例中，我們使用了消息中介來解決了下面兩個問題：
- 外部的服務(wù)并不一定完全和內(nèi)部的需求所匹配。在本樣例中，我們的外部服務(wù)所暴露的接口方法名字和我們內(nèi)部服務(wù)不一樣，為了解決這個問題，我們開發(fā)了相應(yīng)的消息中介并將這個消息中介綁定在相應(yīng)的端口目標(biāo)上來實現(xiàn)消息格式的轉(zhuǎn)換。
- 服務(wù)選擇的問題，在本文樣例中，我們有多個服務(wù)提供者存在，服務(wù)目標(biāo)代表著其身后許多的端口目標(biāo)及其相關(guān)的服務(wù)，我們?nèi)匀煌ㄟ^開放相應(yīng)的消息中介來幫助我們實現(xiàn)我們需要的選擇邏輯。
- 對ESB高級特性的支持
SIBus還為ESB提供了和J2EE緊密融合的安全機制，事務(wù)的傳輸機制，消息的QoS服務(wù)，還有和MQ消息系統(tǒng)的直接互連，雖然這些在本文樣例中沒有涉及，但在后面的文章中，我們將專門介紹這些高級特性。
|
|
3. 在SIBus上實現(xiàn)樣例應(yīng)用
為了實現(xiàn)本文的樣例，我們需要定義好零部件查詢服務(wù)WSDL，然后實現(xiàn)內(nèi)部服務(wù)，開發(fā)需要的消息中介，發(fā)布這個應(yīng)用，接著需要對內(nèi)外部服務(wù)進行整合，最后把整合后的服務(wù)發(fā)布出去。為了本文樣例的演示，還需要開發(fā)模擬的外部服務(wù)，模擬的內(nèi)部客戶和外部客戶來使整個流程運轉(zhuǎn)起來，下面我們就詳細(xì)介紹各個部分的實現(xiàn)方法和關(guān)鍵點：
1．實現(xiàn)內(nèi)部服務(wù)
首先，對內(nèi)部服務(wù)，我們按照J(rèn)SR 109的方式定義為Web Service。JSR 109規(guī)范定義的服務(wù)有兩種基本方式，在Web Module中的Java Bean的方式和在EJB Module中的EJB方式，本文的樣例中對外部服務(wù)采用了第一種方式來實現(xiàn)，對內(nèi)部服務(wù)采用了第二種方式來實現(xiàn)，這為的是給讀者提供全面的參考，同時也更符合實際的場景。
內(nèi)部服務(wù)的具體實現(xiàn)可以參考樣例中InsideService_JAR模塊。這里需要指出的是當(dāng)使用Java2WSDL來產(chǎn)生ejb綁定的WSDL的時候，WebSphere 6引入了新的EJB的綁定方式，這為的是省去SOAP方式的序列化和反序列化的過程，直接通過RMI-IIOP來進行更高效的通信，下面就是內(nèi)部服務(wù)WSDL中綁定部分的定義：
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://partsinfo.com"
xmlns:generic="http://www.ibm.com/ns/2003/06/wsdl/mp"
xmlns:ejb="http://www.ibm.com/ns/2003/06/wsdl/mp/ejb"
xmlns:impl="http://partsinfo.com" …>
……
<wsdl:binding name="PartsInfoEjbBinding" type="impl:PartsInfo">
<ejb:binding/>
<wsdl:operation name="getPartPrice">
<ejb:operation methodName="getPartPrice"/>
<wsdl:input name="getPartPriceRequest">
</wsdl:input>
<wsdl:output name="getPartPriceResponse">
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="PartsInfoService">
<wsdl:port binding="impl:PartsInfoEjbBinding"
name="PartsInfo_SEIEjb">
<generic:address location=
"wsejb:/com.insidecompany.PartsInfoHome?jndiName=……"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
|
請注意這里的EJB綁定方式和它的端點地址的表達方式，這種綁定和WSIF的EJB綁定是不一樣的，WSIF在WebSphere 6中已經(jīng)不再被建議使用。讀者可以參考Info Center獲得Multi-protocol JAX-RPC詳細(xì)的信息和Java2WSDL的具體語法。
2．實現(xiàn)外部服務(wù)
對外部服務(wù)，我們用一個Web模塊來模擬，它是一個按照J(rèn)SR 109方式定義在Web Module中的以Java Bean方式實現(xiàn)的Web Service，具體實現(xiàn)可以參考樣例中的OutsideService_WAR模塊。需要注意的是：外部服務(wù)WSDL接口定義的方法和內(nèi)部服務(wù)是不一樣的，外部服務(wù)WSDL定義的服務(wù)方法是：getPartPriceOfOutService，內(nèi)部服務(wù)WSDL定義的方法是: getPartPrice。
3．實現(xiàn)對消息的路由和格式轉(zhuǎn)換
SIBus的消息中介框架是我們實現(xiàn)消息路由和格式轉(zhuǎn)換的基礎(chǔ)，開發(fā)者可以利用Rational Application Developer來開發(fā)，部署各種消息中介。我們這里將簡要的介紹一下實現(xiàn)的關(guān)鍵，具體細(xì)節(jié)請參考Mediation_JAR模塊中的QueryDispatcher類和Adaptor類：
- 消息的路由：
在本文樣例中，我們將根據(jù)零件的編號的前綴來決定它屬于哪個零部件廠商，從而把價格查詢請求轉(zhuǎn)發(fā)到該零部件廠商的服務(wù)所對應(yīng)的端口目標(biāo)上。具體的選擇規(guī)則我們是通過配置目標(biāo)上下文屬性的方式來提供給消息中介的，詳細(xì)情況可以請參考4.3中的說明。那么選擇好了目的地后，怎么路由消息到那個目的地，而不是原來缺省的地址呢？我們來看看SIBus是怎樣處理消息的分發(fā)的：
在SIBus中，消息的路徑是直接放在消息中的，路徑分為前進路徑和返回路徑，每個路徑都是一個SIBus上目標(biāo)地址(Destination)的列表，消息傳送引擎所做的工作就是從前進路徑列表中取出第一個地址，然后把消息轉(zhuǎn)發(fā)到這個地址所對應(yīng)的目標(biāo)。所以如果想更改消息的前進路徑，我們只需把路徑列表取出來，然后更改這個列表就可以了。下面的代碼演示了如何把把消息轉(zhuǎn)發(fā)到已選出的端口目標(biāo)portDestination上。
……
List frp = msg.getForwardRoutingPath(); //取得前進路徑列表
SIDestinationAddress destination = //根據(jù)portDestination生成SIBus的目標(biāo)地址類
SIDestinationAddressFactory
.getInstance()
.createSIDestinationAddress(
portDestination,
false);
frp.add(0, destination); //把目標(biāo)地址插在第一個位置
msg.setForwardRoutingPath(frp); //把前進路徑放回消息體
……
|
- 消息的格式轉(zhuǎn)換：
在本文樣例中，外部零件廠商的服務(wù)接口和內(nèi)部零件廠商的接口并不一樣，所以我們需要在對外部服務(wù)請求發(fā)出去之前進行一定的消息格式轉(zhuǎn)換，把消息轉(zhuǎn)換成外部服務(wù)的格式才行，當(dāng)然，這種轉(zhuǎn)換必須在邏輯上是可行的才可以實現(xiàn)。我們先來看看SIBus中的消息格式：
在SIBus中，各種消息格式將統(tǒng)一在SDO(Service Data Object)接口之上，我們只需通過SDO接口就可以對數(shù)據(jù)進行各種操作，包括格式轉(zhuǎn)換，而無需使用各種不同形式的API，這無疑將大大減輕了開發(fā)者的負(fù)擔(dān)。回到本例，我們需要對消息格式進行轉(zhuǎn)換，具體的說就是需要變換操作的名稱，從getPartPrice轉(zhuǎn)到getPartPriceOfOutService，下面是本文樣例中如何對消息格式進行變換的關(guān)鍵代碼：
……
if("getPartPrice".equals(operationName)){ //對前進消息進行中介
String serviceDestination="dest:ESB_SHOWOFF:http://partsinfo.com:PartsInfoService";
String graphFormat="SOAP:"+serviceDestination+",
http://partsinfo.com,PartsInfoService,PartsInfo";
String requestValue=info.getDataObject("body").getString("itemID");
DataGraph graphNew=SdoRepositoryCache.instance().createDataGraph(serviceDestination);
DataObject root=graphNew.createRootObject(graph.getRootObject().getType());
info=null;
info=root.createDataObject("info");
info.setString("operationName", "getPartPriceOfOutService");
info.setString("messageName", "getPartPriceOfOutServiceRequest");
info.setString("messageType", "input");
DataObject body=info.createDataObject("body", //生成新的數(shù)據(jù)類型
"http://partsinfo.com","getPartPriceOfOutServiceRequest");
body.setString("itemID",requestValue);
……
|
需要注意的是:
- 我們對前進的消息進行消息變換的時候，對返回的消息也要進行反向的消息變換才能使服務(wù)請求者得到所期望的結(jié)果。
- 我們需要一些WebSphere內(nèi)部的接口（SdoRepositoryCache）來生成新格式的DataGraph，因為所有的數(shù)據(jù)類型都是在SIBus中的SdoRepository定義的。
- 用戶需要熟悉這些內(nèi)部接口和SDO的API，不過，本文樣例給出了很好的參考，基本解決了數(shù)據(jù)格式變換會碰到的問題。
4．整合內(nèi)部、外部服務(wù)
現(xiàn)在，內(nèi)部服務(wù)，外部服務(wù)都有了，消息處理中介也有了。下面我們就要通過新建一個出站服務(wù)來把他們整合在一起。我們需要給出站服務(wù)提供一個完整WSDL定義，來表示可以通過出站服務(wù)的數(shù)據(jù)類型，對本文樣例來說，它需要涵蓋內(nèi)部和外部所有數(shù)據(jù)類型的定義，具體定義可以參考InsideClient_WAR模塊中的PartsInfo.wsdl。我們在這個WSDL中定義了三個可以使用的端口：PartsInfo，PartsInfo_SEIEjb和PartsInfo_SIB，也就是有三個服務(wù)提供者可以選擇，他們分別對應(yīng)HTTP，wsejb和sib類型的綁定。同時，在新建出站服務(wù)的時候，我們可以同時把服務(wù)選擇消息中介綁定到出站服務(wù)目標(biāo)上，而消息轉(zhuǎn)換的消息中介則需要在完成新建出站服務(wù)后手工綁定到外部服務(wù)所對應(yīng)的端口目標(biāo)上。我們可以通過管理控制臺或者wsadmin命令行的方式配置出站服務(wù)，詳細(xì)的腳本和參數(shù)請參考附件中的腳本ConfigSamples.jacl，最終配置結(jié)果在管理控制臺中顯示如下：
5．把SIBus上的服務(wù)發(fā)布到企業(yè)外
最后一步，我們需要把企業(yè)內(nèi)部的服務(wù)發(fā)布出去，讓外部的客戶能夠訪問到我們的服務(wù)。我們可以通過新建一個入站服務(wù)來把SIBus內(nèi)部的服務(wù)目標(biāo)通過HTTP(S)或者(Secure)JMS Listener為外部用戶提供統(tǒng)一的訪問入口點。
新建入站服務(wù)的時候，我們需要提供一個模板WSDL來定義這個入站服務(wù)可以接收的服務(wù)請求，在這個模板WSDL中，我們只需定義我們需要向外部提供服務(wù)的端口類型就可以了，綁定類型和端點地址都不需要提供，實際上這些都是由Endpoint Listeners來具體決定的，我們一般稱這種WSDL為non-bound WSDL，具體內(nèi)容請參考InsideClient_WAR模塊中的PartsInfo_Templet.wsdl。配置入站服務(wù)的參數(shù)請參考附件中的腳本ConfigSamples.jacl，最終配置結(jié)果在管理控制臺中顯示如下：
4. 本文樣例的一些說明
在本文的樣例中，我們在一個企業(yè)應(yīng)用（WAS6ESB.ear）中模擬了各種角色，下表總結(jié)了這個應(yīng)用的各個部分的和它們所扮演的具體角色，具體的部署后的結(jié)構(gòu)圖可以參考前面的整體架構(gòu)圖：
這個應(yīng)用是基于Ant來構(gòu)建的，讀者也可以使用WebSphere Server Toolkit或者Rational Application Developer來輔助開發(fā)。打包文件中已經(jīng)包含了Build好的結(jié)果，各種腳本在Scripts目錄下，對具體腳本的功能請參考目錄下的ReadMe.txt。
在部署的過程中，以下幾點是需要注意和說明的地方：
1． WebSphere 6安裝好后缺省是沒有SIBus環(huán)境的，所以首先要建好SIBus，配置好Endpoint Listeners，讀者可以用管理控制臺來實現(xiàn)，也可以用作者提供的腳本來自動配置（WasSetupSIBus.bat），不過讀者需要更改一下腳本中相關(guān)的目錄信息。建好SIBus后還需要重啟一下才能使它生效，要不然應(yīng)用會報找不到引擎的錯誤。
2． 安裝企業(yè)應(yīng)用WAS6ESB.ear的時候可以使用腳本InstallWAS6ESBApp.jacl來自動進行，出站，入站和消息中介的配置，讀者可以使用腳本ConfigSamples.jacl來自動進行，用戶也可以自己通過控制臺來完成，使用控制臺時需要的參數(shù)可以參考腳本中的相關(guān)信息。
3． 目標(biāo)上的上下文配置信息可以被靈活的利用來給消息中介提供幫助，本文樣例中，我們就是通過在服務(wù)目標(biāo)上加上上下文屬性來決定服務(wù)的選擇規(guī)則。我們加入了下列屬性值：
這里，我們用屬性的名稱來代表零件標(biāo)號的前綴，屬性的值代表外部服務(wù)所對應(yīng)的端口目標(biāo)的名字，DispatcherMediation根據(jù)這些上下文屬性來選擇服務(wù)。這樣做的好處是當(dāng)有新的服務(wù)提供者加入的時候，我們只要增加一個端口目標(biāo)并在服務(wù)目標(biāo)上下文屬性中加上規(guī)則就可以了。不過，WebSphere 6中沒有提供腳本配置目標(biāo)上下文屬性的方法，所以這些屬性需要手工加入。
4． SIBus為我們提供了靈活的運行時配置的支持，我們可以在應(yīng)用部署以后動態(tài)更改端口目標(biāo)中的端點地址和綁定空間，在本文樣例中，我們就可以利用這個功能在新建完出站服務(wù)后更改各個端口目標(biāo)的端點地址設(shè)置綁定方法而無需修改已有的應(yīng)用和出站服務(wù)的配置，這個配置過程叫做Retarget。
5． 在SIBus中，所有流動的數(shù)據(jù)必須是有類型的，也就是必須有Schema來明確定義的，所以當(dāng)我們需要更改消息格式的時候，需要把外部的服務(wù)的數(shù)據(jù)類型在新建出站服務(wù)的過程中的WSDL中有明確的定義，具體情況請參考新建出站服務(wù)過程中使用的WSDL文件。
6． 在內(nèi)部客戶端，我們提供了wsejb和sib兩種綁定方式的動態(tài)DII調(diào)用的實現(xiàn)，因為這些都是私有的綁定方式，所以需要加一些特有的屬性。DII方式比較靈活，不需要用WSDL2Java工具生成各種靜態(tài)的輔助類，而靜態(tài)方式的代碼比較簡單，用戶不需要知道具體綁定和地址的細(xì)節(jié)，關(guān)于wsejb靜態(tài)綁定的方式讀者可以參考WebSphere 6本身的例子，本文樣例中就不再贅述了，sib沒有靜態(tài)綁定的支持。
7． 外部客戶端應(yīng)用可以用任何標(biāo)準(zhǔn)的JAX-PRC客戶端來模擬，對服務(wù)的具體WSDL可以從如下地址獲得：http://localhost:9080/sibws/wsdl/ESB_SHOWOFF/PartsInfoInboundService，ESB_SHOWOFF和PartsInfoInboundService分別是Bus的名字和入站服務(wù)的名稱，SIBus同時還提供發(fā)布相應(yīng)的入站服務(wù)的WSDL到zip文件或者UDDI的功能，用戶可以從管理控制臺獲得相關(guān)信息。客戶端實現(xiàn)可以參考本文樣例中的testWebService.java。
8． 內(nèi)部客戶端可以通過訪問:http://localhost:9080/InsideClient/getPartPrice.jsp來測試，輸入查詢零件的編號，如果編號以outside開頭，表明是外部零件，其他的都認(rèn)為是內(nèi)部零件。服務(wù)將返回編號中的數(shù)字，比如: 輸入outside300，將返回零件價格300。輸入inside400，將返回400。
9． 樣例中提供的三個端口目標(biāo)中，SIB類型的端口目標(biāo)只是起參考作用，真正使用的時候需要綁定一定的消息中介來做路由，因為sib綁定現(xiàn)階段只支持發(fā)送請求到服務(wù)目標(biāo)。
5. SIBus展望
作為新一代實現(xiàn)ESB的核心組件，SIBus自身有著很多的先天優(yōu)勢，以長遠(yuǎn)的眼光來看，它將是架構(gòu)SOA理想的基礎(chǔ)設(shè)施，它的優(yōu)勢體現(xiàn)在：
- 更方便的整合和部署：現(xiàn)在我們只需要WebSphere應(yīng)用服務(wù)器就可以逐步向SOA進行遷移，而以往我們需要很多不同的產(chǎn)品來實現(xiàn)同樣的目標(biāo)。
- 更靈活消息中介：通過和J2EE編程模型更緊密地融合（消息中介本質(zhì)上是Stateless Session Bean），我們可以更方便，更靈活地開發(fā)消息中介模塊來實現(xiàn)基于消息內(nèi)容的動態(tài)路由(Routing)，消息的重構(gòu)(Transformer)和動態(tài)的消息多點分發(fā)(Distributing)等功能，本文的樣例對前兩種ESB中典型的Pattern都提供了實現(xiàn)方法。
- 同應(yīng)用服務(wù)器更緊密的集成：SIBus是純Java實現(xiàn)，緊密集成在WebSphere Runtime中，從而更容易管理和配置，并且因為它基于WPM（WPM是Websphere 6中缺省的消息服務(wù)提供者），各種消息服務(wù)的高級特性都將自然的被支持。
- 良好的可擴展性和可服務(wù)性：因為SIBus在設(shè)計的時候充分考慮了企業(yè)范圍內(nèi)的部署，并充分利用了WebSphere本身的可擴展性和可服務(wù)性，所以它呈現(xiàn)在人們面前的是一個充分互連和充分容錯的，對上層用戶透明的總線，關(guān)于在企業(yè)級進行部署這方面更詳細(xì)的內(nèi)容，我們將在這個系列中的另一篇文章中專門進行介紹。
- 更多可以選擇的SOA資產(chǎn)：在實現(xiàn)SOA的時候，因為有了SIBus，我們有了更多，更靈活的選擇，很多典型的ESB Pattern將直接提供基于SIBus的Transform，這將大大提高開發(fā)者的效率。
6. 結(jié)束語
本文介紹了利用WebSphere 6中的SIBus實現(xiàn)ESB的基本步驟和方法，并提供了一個詳細(xì)樣例來幫助讀者更快的進入角色，WebSphere 6中的SIBus還有著很多高級特性這里沒有介紹，我們將在本系列以后的文章中一一介紹。而本系列的下一篇文章將介紹經(jīng)典的，基于WebSphere 5，MQ系列的組件來實現(xiàn)ESB的方法，這些方法都是經(jīng)過實際項目驗證過的，有著充分的企業(yè)級應(yīng)用的背景，所以在現(xiàn)階段WebSphere 6的SIBus環(huán)境還沒有被大規(guī)模應(yīng)用的情況下，了解這些內(nèi)容同樣也有著重要的意義，歡迎大家閱讀。