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