在企業(yè)服務(wù)總線應(yīng)用解決方案系列的前面三篇文章中，作者對ESB的技術(shù)特征，ESB在WAS6 SIBus上的實現(xiàn)，以及在WBI MB5上的實現(xiàn)分別作了較為詳細的論述，相信大家都對ESB已經(jīng)有了一定程度的理解?？偠灾珽SB是SOA體系架構(gòu)中的信息流動與交換的基礎(chǔ)。ESB的參與主體是服務(wù)，總線提供了服務(wù)間消息的識別，轉(zhuǎn)換與路由的載體。但是，看起來，讀者可能還會有一定的疑惑，ESB首先是一種概念，實現(xiàn)的方案又很靈活，最終支持ESB的產(chǎn)品也很多，那么，前面介紹過的ESB實施方案與具體技術(shù)各自適用的場合有什么特點？基于不同實施方案的ESB又是如何互聯(lián)的呢？本文將對上述問題加以總結(jié)。
到目前為止，IBM專門支持ESB實施的主要有3種產(chǎn)品，WAS6 SIBUS，WAS ESB，和WBI Message Broker。這里按照他們出現(xiàn)的先后順序簡單地介紹一下他們的使用場合：
1） WBI Message Broker
最早提出Message Broker(或它的前身Event Broker)的主要目的，是針對中間件平臺不同消息格式的自動轉(zhuǎn)換與路由，支持Web Service(SOAP), MQ, JMS 等不同中間件平臺的消息互聯(lián)以及與現(xiàn)有系統(tǒng)的消息集成。因此，雖然Message Broker一開始主要是針對EAI的一種集成方案，你仍然可以從中看出Message Broker的設(shè)計初衷與我們現(xiàn)在的ESB的思想是基本一致的。盡管Message Broker出現(xiàn)的時候還沒有明確的ESB概念，但是，隨后IBM在SOA上投入了巨大的努力，作為SOA基礎(chǔ)架構(gòu)的ESB，也得到了非常的關(guān)注。Message Broker逐漸發(fā)展成為專門的ESB實施工具，而且依托完善的MQ消息平臺，它對ESB的支持是重量級的，是目前構(gòu)建ESB最強大的產(chǎn)品。確實，理論上大多數(shù)常見類型的消息都可以通過WBI Message Broker加入到SOA的實施場景中。而且，更重要的是Message Broker是真正適合復雜企業(yè)環(huán)境的ESB實施方式，它的成熟性與性能都是幾個方案中最好的。唯一的不足是，如果應(yīng)用在不很復雜的企業(yè)應(yīng)用環(huán)境中，會略顯笨重。而它使用的ESQL語言，由于不是基于開放標準的，也會對使用者的學習曲線有一定影響。
2） WAS6 SIBus
我們前面已經(jīng)提及SOA架構(gòu)與面向消息的中間件之間密不可分的關(guān)系。為了更好的支持SOA， IBM重新開發(fā)了內(nèi)嵌在WAS應(yīng)用服務(wù)器中的消息服務(wù)實現(xiàn)。因此，從WAS6 以后的內(nèi)嵌消息引擎不再是原來的MQ的簡版，而是一種功能更強的更穩(wěn)定的消息平臺- WPM(WebSphere Platform Messaging)。它是一個純JAVA的實現(xiàn)，符合JMS的規(guī)范，而且提供了很多擴展。能夠很好的同時支持面向服務(wù)和面向消息兩種編程模式。因此，能夠?qū)⒎?wù)與消息很好的整合在一起。SIBus是一種依托WAS6 應(yīng)用服務(wù)器平臺的ESB實現(xiàn)，支持Web Service, JMS 和MQ的消息互聯(lián)與轉(zhuǎn)換。它的應(yīng)用場景應(yīng)該是基于WAS的環(huán)境中，面向Web service與JMS類型的企業(yè)服務(wù)。它的問題主要是開發(fā)的難度比較大，由于沒有很好的開發(fā)工具的支持，開發(fā)者需要有較豐富的J2EE/EJB的開發(fā)經(jīng)驗，而且還需要通曉WAS6 SIBus的相關(guān)API與配置，這無疑限制了SIBus的進一步發(fā)展。
3） WAS ESB
WebSphere ESB是 IBM 正式發(fā)布的獨立ESB產(chǎn)品。它目前所能覆蓋的平臺只有WAS?？雌饋砼cSIBus有些相似，但實際上它發(fā)布的目的主要是補充WBI Message Broker。我們前面講過，WBI Message Broker實施的場景是復雜的企業(yè)IT架構(gòu)，但是一般規(guī)模的企業(yè)可能對采用這種昂貴的解決方案有所顧慮。那么在這種環(huán)境下，小規(guī)模的ESB解決方案，WAS ESB是性價比更好的選擇。但是，WAS ESB將更傾向于提供只涉及Web服務(wù)的總線，這與Message Broker的廣泛適用性有一定差距。WAS ESB對SIBus，如果單從體系結(jié)構(gòu)的角度他們都基于WAS的WPM，象一對孿生兄弟。他們最重要的區(qū)別在于WAS ESB提供了基于SCA的開發(fā)模式和完備的開發(fā)工具，并且提供了預(yù)先定義的元中介(Mediation Bean)。這樣用戶通過工具WID (WebSphere Integration Developer），可以采用拖拽/配置的方式簡單地開發(fā)中介的信息流, 實現(xiàn)ESB不再是復雜的任務(wù)。而SCA（Services Component Architecture）組件對用戶屏蔽了底層的實現(xiàn)細節(jié)，WPM或SIBus中介句柄(Mediation Handler)對用戶來說是不可見的。關(guān)于WAS ESB中的SCA開發(fā)模式，筆者將另外撰文，這里不再贅述。總而言之， WAS ESB可以被視為ESB實施的簡化版，適用于不需要Message Broker復雜性的相對簡單的環(huán)境。它相比SIBus而言，具有開發(fā)界面友好的優(yōu)勢，但由于采用SCA封裝底層的服務(wù)，可以想見在它的早期版本可能會帶來性能上的一定損失。
這是一張關(guān)于WAS ESB與WBI Message Broker關(guān)系的預(yù)測圖，希望大家能從中得到感性的認識。針對不同的場景和開發(fā)者的技術(shù)經(jīng)驗，采用更合理的設(shè)計方案。
根據(jù)我們前面的講解，無論采用哪一種ESB解決方案，ESB的各個總線之間應(yīng)該是可以互聯(lián)的。至少采用IBM產(chǎn)品所開發(fā)的ESB總線都因該能夠順利地集成在一起，這樣ESB的設(shè)想才能成立。用戶在SOA和ESB上的投資能得到有效的保護，這也是SOA倡導的核心思想-重用。單純用SIBus或Message Broker構(gòu)建的同類ESB總線，它們之間的交互方式我們在這里就不再討論了，歡迎大家閱讀WAS的信息中心（infocenter）找到答案，技術(shù)上的實現(xiàn)并不困難。比較難辦的是SIBus(或WAS ESB)與WBI Message Broker如何實現(xiàn)互聯(lián)。下面我們將就這一問題加以討論。
在本系列文章的第二和第三部分中，我們已經(jīng)分別介紹了兩個實例，這里我們將在他們的基礎(chǔ)上延伸出一個新的案例場景，實現(xiàn)SIBus的總線與Message Broker 總線的互聯(lián)。本樣例首先包含一個的零部件價格查詢模塊，某制造企業(yè)所需要的零配件可能來自各個廠商，也有可能是自己制造的，同時，它所制造的零件也可能被它的內(nèi)部用戶或者外部用戶來查詢。由于零件的價格變化比較頻繁，所以這些價格的查詢需要是即時的價格。這一零件價格查詢的樣例已經(jīng)在本系列的第二部分中以WAS6 的SIBus的方式上實現(xiàn)。同時，在這家企業(yè)的訂單請求處理系統(tǒng)中，企業(yè)中的訂單管理系統(tǒng)接收到客戶的訂單請求后，首先到庫存管理系統(tǒng)中檢查當前庫存能否滿足訂單的要求，如果不能滿足則需要到生產(chǎn)制造系統(tǒng)中去安排生產(chǎn)，最后向用戶發(fā)出訂單確認。在本系列的第三部分中，訂單系統(tǒng)在WBI Message Broker上實現(xiàn)。我們現(xiàn)在設(shè)計這樣一個場景，用戶在查詢訂單價格的時候，可以直接選擇，當某零件是自己制造的且?guī)齑鏋榱愕臅r候，向訂單子系統(tǒng)直接發(fā)出訂單請求。這是一個單向的服務(wù)調(diào)用，訂單的生產(chǎn)狀態(tài)被放到一個隊列中供查詢。
這樣一個案例涉及兩個ESB總線的互聯(lián)。實質(zhì)上我們要考慮的是兩個ESB底層消息中間件如何進行不同格式的消息轉(zhuǎn)換以及不同體系的消息目的地地址如何相互定位。
我們在Message Broker中實現(xiàn)了一個消息流，其中集成了兩個生產(chǎn)系統(tǒng)暴露出的訂單請求的Web服務(wù)。一個是公司內(nèi)部的甲地的制造企業(yè)的生產(chǎn)產(chǎn)品的Web服務(wù)接口，而另外一個則是公司內(nèi)部的乙地的制造企業(yè)的訂單請求的Web服務(wù)接口。而產(chǎn)品的訂單請求具體是到甲廠還是乙廠生產(chǎn)，則取決下訂單時所攜帶的路由信息。
Message Broker的消息流處理的是MQ的隊列的消息，因此SIBus與Message Broker的互聯(lián)實質(zhì)上只是SIBus與MQ的互聯(lián)。SIBus只會與WBI Message Broker的消息流的入隊列和出隊列交互。SIBus將訂單請求放到Message Broker的入隊列中，而Message Broker會將消息處理完后放到出隊列中。因此在我們這個場景中，我們需要做的就是在用戶查詢自己的零件的價格時，如果該零件的庫存量為零，就需要通過SIBus向Message Broker部署的消息流的入隊列發(fā)送一條消息。并且通過讀寫Message Broker處理完放入到其MQ出隊列中的消息查詢所下訂單的狀態(tài)。
Websphere 6支持服務(wù)集成總線（SIBus）與Websphere MQ的互聯(lián)，通過兩者的互聯(lián)，可以實現(xiàn)消息在SIBUS與MQ平臺之間信息流的互通，而用戶則無需考慮其中的消息格式的轉(zhuǎn)換和尋址。
實現(xiàn)SIBus與MQ互聯(lián)，需要做的主要工作是在SIBus和MQ中配置與對方通信的相應(yīng)配置。由于SIBus與MQ是兩個單獨的產(chǎn)品，所以它們之間的通信需要在配置時使用相同的名稱來達到識別的目的。
在SIBus上需要定義外部總線，消息引擎的MQ鏈接等。其中的消息引擎的MQ鏈接是關(guān)鍵之處，其發(fā)送方通道的配置告訴SIBus如何找到Websphere MQ的隊列管理器，而接受方通道則是從MQ接受消息。
在Websphere MQ中的配置相對來說則更易理解，因為MQ中的配置其實就是與遠程隊列管理器的配置一樣。在MQ看來，SIBus上的消息引擎似乎就是一個遠程主機上的MQ隊列管理器，通過在MQ上定義發(fā)送方通道和傳輸隊列，就可以實現(xiàn)兩者的連接。如果需要從MQ上發(fā)送一個消息到達SIBus上只需在MQ上定義一個遠程隊列。遠程隊列的作用就是將消息映射回SIBus上定義的本地隊列中。
下面分別介紹在SIBus與MQ中需要做的配置，以及在配置完成后如何定義隊列使的消息可以實現(xiàn)在SIBus和MQ之間自由發(fā)送。詳細的配置步驟會在樣例下載中有安裝文檔說明，這里只是介紹重要的概念。
1）首先需要在SIBus中定義外部總線，需要注意的是必須將"路由定義類型"選為"直接，MQ鏈接"，這說明了外部總線的類型。當需要在Websphere中互聯(lián)SIBus時就需要定義外部總線。這里我們雖然不是SIBus之間的互聯(lián)，但是為了和Websphere之外的MQ連接，也需要定義外部總線。在外部總線上我們可以定義屬于其的外部目標，而這個外部目標將扮演MQ中的隊列在SIBus中的代理。下面我們在配置消息傳遞引擎上的MQ鏈接時，需要使用這個外部總線名。
2）定義消息傳遞引擎，把服務(wù)器作為總線成員添加后，總線上就會有對應(yīng)的消息傳遞引擎。消息傳遞引擎會實際負責與MQ通信的處理。我們需要在消息傳遞引擎中創(chuàng)建"Websphere MQ鏈接"來設(shè)置其與MQ互聯(lián)的參數(shù)。
選擇"LOCALBUS"的"其他屬性"=>"消息傳遞引擎"。單擊引擎名，選擇"其他屬性"=>"Websphere MQ鏈接"，一共有四個步驟需要完成。分別詳細說明如下。
步驟1、鏈接名稱設(shè)置為"BusToMQ",外部總線選擇"FOREIGN_BUS",隊列管理器名稱"QM_TheBus"，單擊"下一步"。
鏈接名稱是一個可選的參數(shù)，可以自由命名。但是外部總線名稱必須選擇在此之前創(chuàng)建的外部總線，例中為"FOREIGN_BUS"。隊列管理器的名稱也很重要，前面說過，消息傳遞引擎在MQ看來就類似一個遠程的MQ,而MQ與SIBus的通信方式與普通的遠程主機上的MQ的通信的配置并沒有什么不同。既然消息傳遞引擎模擬MQ，那么我們就需要定義隊列管理器的名稱。例中為QM_TheBus,這個名稱在后面MQ的配置仍然會發(fā)揮作用。它必須與MQ中定義的發(fā)送方通道的傳輸隊列的名稱一致。它也是在MQ中定義一個遠程隊列時所映射到的SIBus上的本地隊列的隊列管理器的名稱。
步驟2：發(fā)送方通道 WebSphere MQ 鏈接屬性。發(fā)送方通道和接收方通道成對地起作用。該通道將成為用于將消息從總線發(fā)送到 WebSphere MQ 的連接。它需要與我們的MQ的隊列管理器所使用的名稱、主機名和端口相匹配，以接收來自總線的消息。缺省情況下，隊列管理器使用端口 1414 接收傳入的消息。由于我們的樣例中MQ與SIBus存在于同一臺主機上，因此主機名為localhost。這也是Message Broker所部署的消息流所在的主機名。
需要注意的是這里定義的發(fā)送方MQ通道名必須與后面MQ配置中定義的接受方通道名一致。在沒有啟用安全性的情況下，傳輸鏈選擇如圖所示的OutboundBasicMQLink
步驟3：接受方通道的名稱必須與MQ中定義的發(fā)送方通道的名稱設(shè)置一致，輸入"MQToBus"。
步驟4：其他所有的選項都使用缺省選項，保存之。
MQ中的配置主要是兩個通道，一個是用來接受SIBus的消息傳遞引擎發(fā)送過來的接受方通道，其名稱必須與SIBus中消息傳遞引擎的發(fā)送方通道名稱一致。另外一個是用來向消息傳遞引擎發(fā)送消息的發(fā)送方通道，需要首先定義一個傳輸隊列，并且設(shè)置遠程主機的地址和端口。
1） 創(chuàng)建傳輸隊列
在Websphere MQ資源管理器的隊列中新建一個本地隊列，名稱設(shè)置為"QM_TheBus"，使用類型選擇為"傳輸"。
2） 定義MQ發(fā)送方通道
在Websphere MQ資源管理器中選擇高級=>通道，選擇新建發(fā)送方通道。
3）定義接受方通道
同樣在高級=>通道中新建一個通道，這次選擇接受方通道。將通道名稱設(shè)置成SIBus中定義的發(fā)送方通道的名稱"busToMQ",傳輸協(xié)議選擇"TCP/IP"。
現(xiàn)在SIBus與MQ互聯(lián)必需的兩者之間的配置已經(jīng)完成了。為了使訂單請求能夠從SIBus上到達MQ，我們需要在SIBus上定義一個遠程目標（Foreign Destination）。這個遠程目標是Message Broker的MQ入隊列在SIBus上的代理。發(fā)送到SIBus上的這個遠程目標的消息將會通過SIBus上的消息傳遞引擎和MQ的接受方通道最終達到MQ的隊列管理器上的隊列中。訂單消息到達這個隊列后，因為是Message Broker部署的消息流的入隊列，Message Broker會取走這個消息，隨后做處理，處理后的消息會存放在Message Broker定義的出隊列中。例中MQ的隊列管理器為WBRK_QM.。
1） 在總線的"其他屬性"=>"目標"，點擊進入，選擇新建，目標類型選擇"外部"。
2） 設(shè)置屬性
Message Broker處理結(jié)束的訂單狀態(tài)的消息到達MQ出隊列后，我們需要將它發(fā)送到SIBus上。為了完成這個任務(wù)，需要分別在SIBus上定義隊列目標和在MQ上定義遠程隊列。SIBus上的隊列目標的創(chuàng)建與外部目標的創(chuàng)建過程類似，只是目標類型必須選擇"隊列"而不是"外部"。SIBus上的隊列（例中為LocalQueue）創(chuàng)建成功后，我們就可以在MQ的隊列管理器（例中為WBRK_QM）定義一個遠程隊列映射到SIBus上的隊列目標LocalQueue。為了與Message Broker消息流的處理集成起來，這里在MQ中定義的遠程隊列也必須同時是在Message Broker中的消息流的出隊列。
1)在WebSphere MQ隊列管理器中選擇 WBRK_QM隊列管理器，擴展Queue，右鍵選擇New=>Remote Queue Definition
2）輸入或設(shè)置以下值
前面講述的是如何在兩個不同的策略實現(xiàn)的ESB上做尋址，但是當消息到達Message Broker實現(xiàn)的總線時，為了能夠調(diào)用Message Broker的消息流中集成的制造廠的訂單請求Web服務(wù)接口，我們需要對消息的格式進行轉(zhuǎn)換。
Message Broker中對于消息的處理有很好的語言支持，也就是ESQL，通過它我們可以很方便的根據(jù)MQ的消息體中的內(nèi)容，構(gòu)造新的SOAP消息。在Web服務(wù)返回后，我們需要根據(jù)返回的SOAP消息體構(gòu)建新的MQ消息。
消息的轉(zhuǎn)換的處理流程如下圖所示。上方的消息流程是完成路由到甲或乙制造廠的功能。最下方的消息流是訂單請求路由到乙制造廠的處理流程。BJMQ2Http計算節(jié)點完成MQ的消息到HttpRequest1集成的乙制造廠的Web服務(wù)的SOAP請求消息的轉(zhuǎn)換，而BJhttp2mq則完成的是對SOAP返回消息到MQ消息的轉(zhuǎn)換。
在開發(fā)從MQ消息請求制造廠的訂單請求Web服務(wù)時，需要注意的幾個問題是
1） MQ的消息頭
為了能將Web服務(wù)的返回的SOAP消息重新構(gòu)造成MQ的消息，我們需要在MQ的消息轉(zhuǎn)換成SOAP消息保留MQ的頭消息。在ESQL中通過將MQ的頭消息保存到環(huán)境中可以達到這個目的。
SET Environment.MySavedMQMD = InputRoot.MQMD;
2） Message Broker中如何集成Web服務(wù)的調(diào)用
在Message Broker中提供了一組內(nèi)嵌的節(jié)點可以集成Web服務(wù)的調(diào)用，HttpRequest節(jié)點就是一個用來配置集成Web服務(wù)請求的節(jié)點。在HttpRequest節(jié)點的屬性中可以設(shè)置甲或乙制造廠的訂單請求的Web服務(wù)的URL，如下圖所示：
3） 在ESQL中使用XMLNS域處理消息格式的轉(zhuǎn)換
在我們的場景中為了實現(xiàn)自解析而不需要定義消息集的目的，我們設(shè)定了HttpRequest和消息流中的MQ的域是XMLNS。XMLNS域?qū)臻g的XML格式消息可以實現(xiàn)自解析。這里的轉(zhuǎn)換工作我們使用ESQL語言完成，構(gòu)建消息的過程必須參照特定的Web服務(wù)的SOAP的請求的描述。使用ESQL語言處理XMLNS域的消息與普通的XML域的不同，主要在命名空間的處理上。自解析的XML消息在Message Broker中會解析成一顆消息樹，但是在SOAP的請求消息中會有很多的命名空間，這是我們需要處理的額外內(nèi)容。這些命名空間通常包括 " 到這里，SIBus與WBI Message Broker的集成工作已經(jīng)完成。在我們的場景中，不同策略實現(xiàn)的ESB的互聯(lián)發(fā)生在當用戶查詢自己生產(chǎn)的零件的價格并且發(fā)現(xiàn)零件庫存為零。這時會往SIBus上的外部目標寫入訂單請求消息。通過互聯(lián)配置，訂單請求消息會到達MQ的隊列中。 Message Broker的消息流根據(jù)消息的內(nèi)容路由到甲或乙兩個不同的制造廠。Message Broker的消息流會將MQ的消息轉(zhuǎn)換成SOAP的請求消息后，請求甲或乙兩個不同制造廠的提供的訂單請求接口。而訂單請求的狀態(tài)返回也是SOAP的返回消息，再轉(zhuǎn)換成MQ的消息后，將會放到MQ的出隊列中。而MQ出隊列的消息通過互聯(lián)的配置又路由回了SIBus中。 回顧一下我們所做的主要工作在于如何在SIBus和MQ中配置與對方的通信，因為是相互獨立的軟件，所以經(jīng)常遇到必須將某些名稱設(shè)置為一致的情況，這是讀者在實際配置時必須要注意的一點。由于篇幅的關(guān)系，隨文可以下載的樣例中包含了更加詳細的配置說明過程。
