IBM MessageBroker筆記系列（一）
前言
SOA已經在中國喊了幾年，連象牙塔的大學生都知道了，但實施的案例並不多，而作爲SOA基礎設施的企業服務總線ESB，在國內的應用更是稀少，主要都是銀行和電信等大牌企業在使用。我算非常好彩，打工所在的公司恰好要爲客戶開發一個基於MB和WAS的平臺，讓我有很多機會接觸到MB的應用。現在國內MB的資料非常少，主要是IBM的紅皮書，可惜全部都是英文的，看起來頗費力，效率也不高；出版物我所知的只有一本，是陳宇翔先生所著的《精通Websphere Message Broker》【中國水利水電出版社】，也是目前手邊唯一的一本參考書。因此希望將這段時間的一些使用心得記下來，作爲一個從未接觸過SOA和MB（甚至沒用過websphere產品）的菜鳥，面對這個上百萬人民幣的龐然大物，應該怎樣下手
書評
先來說說這段時間翻閱的一些MB的書籍，包括紙質和電子版，首先是上文說到的《精通Websphere Message Broker》這本書。本來這種書給人的第一反應就是：一本紅皮書的翻譯，無非就是從IBM的各個紅皮書裏面摘抄文字，翻譯好之後綜合一下的“大雜燴”。老實說這本書裏面的確有很多翻譯的內容，比如MB toolkit中自帶的一些教程，以及MB Information center裏面的部分實例，書的後半部分都是附錄，包括函數庫、命令庫，等等。但是不可否認的是，IBM的紅皮書、InfoCenter本身就是相當好的教程庫，而這本書用到其中的內容也翻譯的流暢，所以也是方便了國內讀者。而且，作者本身也的確有一些MB的使用經驗，書中也有他自己的內容。所以，這本書作爲入門的話，實在是比較辛苦，因爲沒有考慮太多初學者的難處，內容的編排也不太合理，但是作爲一本參考書卻是不錯的選擇。在如今沒什麼資料的情況下，最好咬牙堅持看下去。
再說說IBM提供的電子資源，包括紅皮書和網上資料，以及InfoCenter。只要你買了MB的產品，IBM自然會提供一堆紅皮書給你，當然你也可以慢慢從網上下載，這些紅皮書很多寫的不錯，但是要從頭看太痛苦，作參考比較好。此外如果你購買MB的培訓，那麼培訓機構也會給你一些pdf材料（其實都是IBM出品的），這些材料相對易懂，適合入門。再有就是developerWorks，IBM的官方技術網站，裏面提供最新最全的資料，有空多去看看，也可以訂閱它的郵件。最後是InfoCenter，其實說白了是網頁版的手冊，可以在線看也可以下載，相對其他來說，難度介於中等，而且不像網站的資源那麼零散，所以也是很好的提高階段的學習資料。
ESB產品
如果你還不清楚ESB的概念，和IBM的相關產品，可以去IBM網上查查資料,作爲一個菜鳥我沒法全面評論當前的ESB產品，只能記錄一下自己的所見所聞（就是跟IBM和BEA公司打交道的時候聽到的一些內容）。撇開兩者的應用服務器不談（這方面的口水戰已經夠多了，國內用BEA的相對多，容易上手適合快速開發，性價比很高），SOA和ESB方面，IBM無疑是走在前面的，這個可以從兩者的產品線看出來。BEA的ESB產品只有一款AquaLogicBus，IBM卻已經開始劃分各類市場、推出不同檔次的產品了（但這個也是BEA宣傳的好處之一，買一個就能到處用，見仁見智了）；其二，BEA自己的銷售都對AquaLogic不甚瞭解，而且在國內尚無成熟應用，這點是很多企業最關注的，沒有成熟應用意味着沒有好的技術支持，出了問題不知道找誰解決，甚至從沒有人遇過這種問題；而IBM這兩年在SOA的推廣方面做得比較好，廣告也做得多，在國內已經有一些成功案例，技術支持也更加完善，我們在廣州就能直接聯繫到工程師，而不必等北京、上海，甚至國外的支持。
MB在對異構環境的支持方面，做得也比AquaLogicBus好，可以支持幾十種通信協議和平臺，而且天生和IBM自家的大型機等結合的比較好，AquaLogicBus支持的就相對比較少，主要是基於java平臺的SOA流行協議，比如web service，給人感覺更像是websphere ESB的競爭對手。但是BEA的產品向來給人的感覺是除了在IBM的平臺，其他平臺上都比IBM的同類產品性價比要高，不知道AquaLogicBus是不是也一樣表現優秀，這個就需要專業的測試了。
另外很重要的一點，就是BEA的消息中間件做得不如IBM的MQ強大，而MB又是依託於MQ纔能有如此強大的功能，這個是BEA的銷售也不得不承認的。儘管Web service是當前SOA的主流，但是性能方面卻是不敢恭維，在企業內部實施SOA，如果服務組件都用web service連接，雖然更加通用、更加廉價易用，但是往往會有性能瓶頸，關鍵地方還得靠消息中間件。
最後呢，就是BEA工作人員對於自家的產品，底氣明顯不足，一方面是不熟悉，另一方面也是國內用的少，也側面反映了對於這類重量級產品、而且關乎整個系統性能的底層部件，人們還是傾向於選擇IBM，將來SOA應用普及了，AquaLogicBus肯定也會遍地開花，就像現在的weblogic一樣。只是目前來看，還是選擇MB更讓人放心。
還有一個不得不提到的有力競爭者是來自開源社區的JBOSS ESB，這個產品我沒了解過，但是現在Reahat收購了JBOSS，在JBOSS AS和ESB上也下了相當大力氣，誓要在SOA市場與IBM和BEA分一杯羹。很看好JBOSS的潛力，只是開源產品在中國連個服務中心都沒有，暫時只能供高手們自己研究着玩了。
IBM Message Broker筆記系列（二）
趕在這周結束前，再寫一篇
MB概述
MB的全稱是message broker，即“消息代理”。“消息”一詞前幾年比較火，消息中間件也賣的很火，當時似乎J2EE的產品都要跟“消息”、“中間件”扯上點關係，以彰顯潮流。我覺得初學者只需記住“消息”的異步性即可，也就是“消息”和傳統的網絡連接、遠程方法調用等的最大區別，就是你一旦發出消息以後，不用再管它的死活，中間件會處理一切事務，出了問題也會通知你，這樣可以更好的分離業務邏輯。把消息當成郵件的話，那麼傳統網絡連接就是由你去送信，而中間件則好比郵局，它來提供送信服務，並且可以跨國境、跨語言，完全不用你操心（相當於中間件可以連接異構平臺），使用者只需等在家門口收信。
在說“代理”之前，先講一下MQ的基本概念。MQ即message queue，消息隊列，也就是IBM的主打消息中間件產品，IBM幾乎所有SOA相關的產品，都是構建於MQ之上的，沒有MQ強大的消息傳輸能力，那麼IBM很多產品都做不起來。在這裏不贅述MQ的功能，初學者只需把MQ當成一個非常可靠的傳輸通道即可，你只要往裏面放東西，MQ就會把消息傳到目的地。
那有了強大的MQ還要“代理”幹什麼呢？如果你用過MQ，或者類似的產品如apache的開源JMS產品“ActiveMQ”，就會發現，儘管用MQ不必考慮網絡連接、平臺異構，但是你在配置的時候、以及使用MQ編程的時候，都要指定目的地，比如設置IP地址。這樣的程序依舊存在很大耦合性，萬一某個組件的IP變了，所有跟他相關的組件都得改動，輕則修改配置文件、重則重寫代碼。這時“代理”的作用就開始凸顯了。
所有組件的MQ隊列都可以直接連接到MB上，MB相當於一個公共服務中心。MB接收所有消息，然後自動分析其中的內容，找到相應的目的地，進行路由轉發，好比你在寫信時，只需寫明收信人的姓名、身份證，哪怕收信人搬到天涯海角，只要他在MB郵局中登記了，那MB就可以把信交給他，這樣進一步地分離了業務和底層通信，我只需要知道業務概念上的“他”，就可以把消息交給他。此外，MB還可以進行消息轉換，這就像是自動翻譯信件，我現在可以用中文寫封信給本拉登，我不需要知道他具體藏在哪裏，信件就會自動翻譯成阿富汗的文字，送到本拉登手裏。
所以，代理的兩個核心功能就是：“消息路由”和“消息格式轉換”。MB本質上也是一個服務總線，所有的服務組件接入到MB中，服務將消息塞給MB，MB來決定怎麼轉發，這樣讓服務愈加成爲一個獨立的實體，和其他服務的耦合性進一步降低，從而達到SOA的境界。
MB初覽
說了那麼多大道理，終於開始講到MB的具體內容了。下面的圖片摘自IBM的紅皮書，是MB的總體架構，我粗略的描述一下。
可以看到，MB裏面有兩大塊內容，一個是toolkit，也就是開發環境，後面我們會講到；還有一個是broker domain，即代理域。代理域裏面有兩個核心部件，一個是配置管理器configuration manager，一個是代理broker。
配置管理器其實很像MQ的隊列管理器，或者是WAS的deployment manager，都是起到一個管理作用，在MB裏當然是管理衆多的broker了。我們平時對broker的管理、維護操作，其實都是通過配置管理器完成的。
代理broker是真正體現MB設計思想的地方，上面的圖片中有像流程圖一樣的東西，即message flow，是消息的流程圖（從什麼地方流進來，再從什麼地方流出去）；還有message set，即消息集，說白了是描述消息長什麼樣子，它的結構、內容是怎樣的。其實，message flow對應了上文所說的“消息路由”，而message set則對應“消息格式轉換”，你肯定要清楚兩種消息的格式，才能定義互相轉換的規則。
MB的外圍是各種類型的應用程序，他們接入MB的方式可以多種多樣，可以是Webservice，也可以是數據庫、文件、HTTP連接，等等，不一定侷限於MQ
圓柱體代表的則是數據庫了，這是盡IT人皆知的。因爲MB的很多信息，包括配置信息、以及broker的運行時信息都要通過數據庫保存。broker本身也可以操作數據庫，你可以在流程的某個節點上增刪查改某個數據庫
下圖是WMBT（websphere mb toolkit）的界面
可以看到，WMBT是基於eclipse的，所以大部分java開發者應該能很快上手。開發MB程序和開發J2EE程序差不多，也是先新建一個項目，然後編輯，最後部署。
1號區域是一個消息流，可以看到非常直觀：從MQ讀入——計算（轉換成webservice格式）——發送http請求到web service的url——計算（轉換回MQ消息格式）——放入MQ
2號區域是節點選擇面板，MB自帶了幾十種節點給我們選擇，同時我們也可以自己創建節點
3號區域是屬性面板，當你選擇某個節點時，可以在其中編輯節點的屬性
4號區域是域連接面板，開發好的消息流和消息格式，必須首先在MBT中連接到對應的配置管理器，再將打包好的流程部署到對應的broker中，這個過程也可以由命令行完成
5號區域則類似eclipse的項目集合，裏面是所有的MB項目
總結
還是打個比方。首先，我們把MB看做一個功能超級強大的路由器，它支持多種接入方式，也就是MB路由器上的端口有很多種，MQ是比較常用的一種方式，所以MQ就像常用的RJ45接口的5類雙絞線。但同時MB還支持JMS、SCADA等各類接入標準。在MB內部，我們管理員定義好路由規則（編寫消息流）。其次，從MQ過來的信號，可以轉換成其他網絡協議的信號（消息格式轉換），這類似於網橋功能，可以跨越不同網絡。同時，MB的性能非常好，可以進行大數據量交換，這一點又很像是交換機。最後，MB可以理解業務邏輯，它的路由不僅像路由器那樣針對消息頭進行路由，還可以根據消息的業務內容進行路由，酷似應用網關。
IBM Message Broker筆記系列（三）
安裝配置
準備工作
MB的運行依賴於MQ，所以首先要安裝MQ，MQ的具體安裝過程略，並且以後假設你已經有關於MQ的基礎知識，比如隊列管理器、隊列、通道，等等。
安裝好MQ後，創建一個隊列管理器（簡稱QM），名爲TESTQM（MQ裏面的對象是區分大小寫的，爲了避免不必要的麻煩，這裏統一用大寫，以下劃線分隔），這個隊列管理器是MB運行的基礎，當你用MB的腳本創建配置管理器、代理和執行組時，都要指定QM的名字
然後創建運行時數據庫，名爲TESTDB，MB自帶了derby，你也可以選擇DB2，注意此處的數據庫是指MB自身運行所需的數據庫，目前6.1版本只能用derby或者DB2。創建的方法，可以用MB的腳本命令：mqsicreatedb，也可以用對應數據庫自身的腳本命令或圖形界面來創建。
關於MB的數據庫：
配置管理器只能用derby，而代理可以用多種數據庫，只是不同數據庫的創建命令各自不同（包括在不同平臺上也有差異，具體參考紅皮書）；代理的數據庫可以共用，配置管理器也可以和某個代理共用一個derby數據庫；使用mqsicreatedb創建數據庫時，如果你已經安裝了DB2，則默認創建一個DB2數據庫，否則derby
以上是爲MB的運行創造運行時環境，接下來開始創建MB的實例
首先當然是要安裝MB了，過程挺簡單的，略去不表。安裝完成後，會在“開始菜單”中有個“命令控制檯”，如下圖：
單擊它，進入MB的一個命令控制檯環境，其實和普通的windows命令控制檯沒什麼區別，主要在於它幫你設好了相關的環境變量，你就可以在裏面直接輸入MB的命令腳本了
前文提到過，MB的配置管理器是用來統一管理MB的各個運行時組件的，因此首先要創建一個配置管理器
mqsicreateconfigmgr –i user –a password –q TESTQM
指定用戶名、密碼和隊列管理器，用戶名密碼是你登陸本地機器時輸入的，必須要有足夠的權限（具體權限就不清楚了，我直接用管理員帳號，深入討論請參考MB的紅皮書）
你會發現這裏沒有指定數據庫的名稱，因爲配置管理器在創建時會自動新建一個derby數據庫，而且只能用derby數據庫，用戶無法改動
配置管理器的名稱也沒有指定，在windows下是會創建默認名稱的：ConfigMgr
然後是創建代理，名爲TESTBROKER
mqsicreatebroker TESTBROKER –i user –a password –q TESTQM –n TESTDB
大部分都和創建配置管理器一樣，只是多了一個選項，用於指定數據庫，再次提醒，必須是derby或DB2，二選一。
最後，使用“mqsistart組件名”來啓動配置管理器和代理
配置MB toolkit
WMBT本身的安裝沒什麼特殊要求，這裏就不囉嗦了
接下來的關鍵是在WMBT裏面連接到剛纔創建的配置管理器，其作用就好像你在Eclipse中要配置好應用服務器的實例，才能把你的J2EE項目直接以圖形界面的方式部署，而不必自己敲命令
如圖，文件->新建->域連接
在彈出的窗口中，填入相關參數
這裏只需填入隊列管理器的名稱、域名、端口，注意是隊列管理器而不是配置管理器（其實你在創建配置管理器時也沒有指定端口，因爲它用的就是所在的隊列管理器的端口）
此外對於SVRCONN通道名，SYSTEM.BKR.CONFIG是在你創建配置管理器時自動生成的，可以在“MQ 資源管理器”中，通過“顯示系統對象”來查看，你也可以自己建一個服務器連接通道，然後在這裏輸入該通道的名字
一切正常的話，就能看到左下角的“域”窗口中，多了一個新的域連接，裏面以樹形結構顯示了你剛纔創建的代理（前提是你的代理基於derby數據庫，如果基於DB2，則需要在域連接那裏顯式增加“代理引用”），現在你可以右鍵單擊TESTBROKER，然後創建執行組。等你開發好MB項目後，打個包，拖到執行組裏面，就可以部署了。
IBM MessageBroker筆記系列（四）
前面講了那麼多MB的原理和配置，這一篇blog開始正式講講我個人學MB的感受。“假如時間可以重來”，我會怎樣利用手頭的資源，以最快的速度入手。
體驗MB
在安裝完WMBT之後，會出現“歡迎”（這個也是eclipse環境安裝後都會有的東西，你也可以在“幫助”->“歡迎”裏面找到），裏面有不少很淺顯的例子，讓你對MB是如何工作的有個感性認識。強烈建議把裏面的“入門”部分看完。
學習開發
看完“入門”後，重點就應該放在“樣例”中。在樣例庫裏面，有數十個基礎的樣例，每個樣例都針對某類節點，比如消息映射、JMS、數據庫操作、Webservice調用，等等。那麼多的例子，當然不可能一下子看完，而且對於一張白紙的新手，裏面有些基礎知識還不懂，我的建議是：結合之前提到的那本書《精通Websphere Message Broker》，看完一方面的內容，比如數據庫操作，你就可以打開“樣例庫”，將裏面的數據庫樣例導入至WMBT，然後看看其中的ESQL代碼、相關節點的設置，等等。一開始會比較枯燥，而且讓這些樣例跑起來也不是件容易的事情，但堅持下去就會慢慢體會到其中的樂趣了。
掌握Debug利器
一般來說，WMBT會自動幫你配置好樣例程序運行所需的環境（比如創建隊列管理器、數據庫，等等），然後將樣例部署到MB的執行組中。這一切都是自動完成的，但有時候出於各種原因，試運行樣例的時候不能得到預期的結果。首先排除掉打包和部署時的錯誤，因爲樣例程序的源代碼通常是沒有問題的，那麼餘下的問題就只能靠debug來解決了。另一方面，當你看了書之後，對InputRoot、Environment、ExceptionList這些東西的結構、細節肯定會很好奇，但是書中提到的很少很零散，最好的方法就是在debug模式下，讓消息流掛起在某一點，然後你再慢慢瀏覽其中的各類變量，很多東西都不言自明瞭。用IBM工程師的話說，就是“沒有debug就根本沒法學會MB”。爲什麼？相關資料太少了，去google有時候還不如直接問MB自己，所以也是很考驗你的自學能力的。
配置debug環境
這些內容在《精通》那本書中都有講到，只是比較粗略，我在這裏補充我個人的經驗。
首先右鍵單擊某個執行組，“屬性”，在“JVM調試端口”中輸入一個tcp端口號，不要和其他程序衝突就行，假設9090。再次右鍵執行組，“調試”->“啓用調試9090”。然後，切記，重啓執行組所在的broker
重啓後，把bar文件部署到該執行組，然後進入“debug”視圖，找到下圖右下角的那個按鈕：
如果是該按鈕是紅色的，說明debug守護程序沒有啓動；如果是綠色的，鼠標移過去，會顯示“debug守護程序正在監聽XX端口”，需要注意的是，這裏的端口可不是之前在執行組設置的端口，剛好相反，必須和之前的9090不同。單擊旁邊的下拉箭頭，可以啓動或者更改守護程序的端口，這裏改爲9099，不必重啓。
接下來，就和一般的eclipse調試一樣了，在綠色的小昆蟲按鈕設置debug參數。新建一個debug，注意這裏的“java調試端口”則必須與執行組的一致，你也可以“選擇執行組….”，系統會根據你選擇的執行組，自動設置端口
然後，在“源”選項卡中，添加你要調試的項目。確定之後，就可以運行debug了。
What next？
debug配置成功後，就開始慢慢研究那些樣例吧，按照之前我說的思路，“書本+樣例”，按照每個人自己的學習習慣和項目開發的需要，將你要學習的樣例，一步步調試過去，看看每條ESQL語句的結果，很快的你就知道其中的運行機理了。
小結
由於MB不能像java那樣，輸出東西到控制檯，只能輸出到日誌文件，而且還得寫一堆語句，或者配置trace節點，很麻煩，所以傳統的在程序中插入輸出語句的方式在這裏沒太大意義。很多情況下，要依靠debug來觀察消息流執行過程中消息的變化，來決定bug的所在。
IBM MessageBroker筆記系列（五）
學習資源
專門整理一下最近用到的一些學習資源，並稍作評論
一、《精通Websphere Message Broker》
其實對這本書，我是愛恨交加。一方面，它是僅有的一本中文的紙質圖書，也是我翻得最多的一本參考書；另一方面，它也就是參考書，作爲入門的圖書太難了，編排也不怎麼樣。但是總的來說，開發MB還是少不了它呀，當你要查某個節點的用法、某個ESQL函數的參數，大部分人還是傾向於翻書而不是翻一堆英文資料吧
二、Websphere Message Broker InfoCenter
這個東西的使用頻率是僅次於上面那本書的，比起書來說，有哪些好處呢？首先是內容量大而且全，幾乎你要找的所有信息都能在裏面找到。此外，電子資源的一大好處是可以搜索、可以用金山詞霸，對於一些書上沒有的或者你根本不知道躲在哪個角落的信息，用這個最方便了。
但是不足之處也顯而易見，首先是全英文，看起來比較費力；另外是對着屏幕上一頁頁的英文看半天，個人感覺對眼睛很不好，很費精力。
三、IBM技術支持
IBM的服務分爲收費與免費兩種，當你購買了相關產品後，就能獲得相關的技術支持，一般是指派一兩個售後工程師，你可以隨時聯繫他們，包括手機和電郵。當你在開發中遇到問題時，大可不必客氣地狂問他們問題。能不能給你個滿意的答覆就看情況了，因爲有些問題不面對面交流是無法描述清楚的，而要他們過來你這邊通常需要預約（IBM的工程師都很忙，貌似事情特別多，三天兩頭開會、培訓學習什麼的）。
而且，作爲專業服務隊伍的一大特點，就是隻負責他熟悉的產品，假如你的問題是“MB和spring裏面某個東西通過MQ互聯失敗”，那他們首先會嘗試解決MB這邊的問題，如果不行，那就不好意思了，“spring不是IBM的，同時也不是我熟悉的，你去找spring的廠商吧，或者還可以給你一個MQ工程師的聯繫方式”。其實很多這些問題都是要聯調的各方一起解決的，只是，如果你真要這麼做，先掏服務費吧，因爲這種問題涉及到具體項目開發，IBM可不是慈善機構。
還有一種情況，就是IBM的工程師也不曾遇過的問題，比如某些產品的新特性連他們都沒有被培訓過，那就比較痛苦了，所以要找其他方法，總不能幹等到他們學習完了再來指導你吧。
四、MQSeries論壇
這個論壇特別好！囊括了IBM MQSeries的所有產品，裏面有專門的WMB區，很多高手在裏面回答問題，我甚至覺得，真想深入研究MB，平時可以多去那裏逛逛。上次關於webservice的一個問題，IBM的技術支持都不清楚（因爲是6.1版本的新特性），最後還是這裏的高手解答的。
這是國外的一個論壇，發帖看帖之餘，還能練習英文，何樂而不爲呢
五、IBM 網上資源
這個的範圍比較廣了，從紅皮書到developerWorks社區，裏面有很多你想要的東西，只是dw社區的文章中英文混雜，找起來比較費力，個人還是把這裏當成學習的地方而不是緊急時候的參考資料。閒暇之餘在這裏瀏覽那些IBM專家發的文章，不僅圖文並茂、版面工整，文章質量高，水平也由淺及深，各種層面的都有，實在做得很不錯，建議我們這些菜鳥或者技術狂去訂閱dw的郵件吧，經常會發送“新手入門”之類的電子雜誌。
小結
暫時用到想到的就這些了，MB的確不好學，不然IBM也不會把培訓和服務費收這麼貴了，可見IBM真是很狡猾，把軟件做得難用又不肯出一些系統的基礎教材，擺明是要宰你一筆，呵呵。如果你也對MB有研究，歡迎一起探討，交流更多好用的資源（可以省錢）。
IBM MessageBroker筆記系列（六）
前面幾篇筆記，都是討論MB是什麼、怎麼配置、怎麼debug，以及一些學習資源和心得，接下來的幾篇會針對MB開發中一些常見的問題，分門別類進行歸納總結，包括數據庫、WebService、ESQL語法細節，等等。這些細節問題都是我本人在這兩個月的開發過程中遇到的，相信對很多新人都有借鑑作用。
配置MB的用戶數據庫
前面已經講了在創建MB運行時實例時，配置數據庫的基本過程了，但那裏所指的數據庫是MB自己運行時需要的數據庫，用來存放諸如broker、執行組、消息流等的信息，而現在開發的企業應用程序，幾乎沒有不用到數據庫來存放業務數據的，所以這裏主要講述如何配置“用戶數據庫”，也即你的應用程序使用的數據庫。
下面以MB 6.1 + Oracle 10g爲例，介紹配置過程
一、 ODBC數據源
MB是通過ODBC來操作數據庫的，因此首先要配置好操作系統本身的ODBC數據源。Windows中配置ODBC很容易，在此不贅述細節。需要注意的是，選擇Oracle數據源驅動時，一定要選擇下圖所示的MB自帶的Oracle驅動
我在創建ODBC時，一開始沒有在本機安裝Oracle，結果ODBC無法使用，報告“由於系統錯誤126，驅動程序無法加載”，問了IBM的技術支持也沒有答案，後來乾脆在本機安裝了一個Oracle（不必運行），問題就解決了，估計MB自帶的Oracle驅動還是要調用Oracle本身的一些庫的。我對Oracle本身基本不懂，具體用到了哪些庫也不清楚，就先這麼用着了。
二、數據庫設置
這裏順手提一下Oracle本身的設置。當你新建了Oracle的ODBC數據源後，會發現數據源設置裏面，沒有IP和端口設置。我在網上搜了一下，最簡單的方法是直接修改Oracle的tnsnames.ora文件，這個文件位於： $oracle_root/product/10.1.0/db_1/NETWORK/ADMIN/tnsnames.ora 路徑下，可以用記事本打開編輯。裏面本身已經有樣例了，參照着改很容易
三、消息流節點
MB中能和數據庫打交道的節點有很多，包括filter、compute，和專門的數據庫節點，如下圖：
基本上，凡是屬性裏面可以設置“數據源”的節點，都可以操作數據庫。使用方法很簡單，直接在“數據源”屬性中填入操作系統的相應ODBC數據源名稱即可。
四、代理broker的設置
這是最後一處要設置的地方。前面的tns文件解決了ip和端口的問題，但是數據源本身的用戶名和密碼在消息流中並沒有提及，其實這是通過MB的一個命令來設置的，格式如下：
mqsisetdbparms brokerName -n dataSourceName[-u dataSourceUserId] -p dataSourcePassword
具體用法可以輸入 mqsisetdbparms /h 獲得參考
配置完以上內容後，運行消息流應該不會有數據庫連接的異常了。假如配置不正確，會在運行到使用了“數據源”的節點處拋出ODBC的一些異常
在WMBT中創建數據庫項目
以上做的工作可以確保消息流能夠正確操作用戶數據庫，但是當你在WMBT中編寫SQL語句時，會出現很多警告，內容一般是“無法解析數據庫表引用：某字段”。雖然不影響運行，但看着總是不太爽。
出現警告的原因很簡單，你沒有告訴WMBT你需要用到的數據庫表的結構是什麼，所以WMBT很盡職地告訴你可能有問題，我們只需引入數據庫的定義，即可消除這些警告。
首先，打開“數據庫資源管理器”視圖，新建一個JDBC連接，和其他EclipseIDE類似，配置好相關參數即可。
在WMBT中新建一個“數據庫定義”，嚮導會讓你順便創建一個“數據庫設計項目”，你可以通過剛剛創建的JDBC連接，選擇一個數據庫，即可。
這時你會發現ESQL代碼中那些煩人的提示已經消失了。
在ESQL中編寫SQL語句
ESQL中使用SQL和一般的SQL語句基本一致，除了在指定哪個數據表的時候，要用類似下面的語法：
SELECT FROM Database.SchemaName.TableName
其中的“Database”是關鍵字，一定要有的，表示從數據庫中讀取，這是因爲ESQL中不單可以操作數據庫，還可以對邏輯樹、數組對象使用select、delete等SQL語法，“Database”起到標識的作用。
給出這樣一條語句：
set LocalEnvironment.temp[] = select * fromDatabase.TEST.example
假設example有id和info兩個字段，共三條記錄，那麼執行後的結果是LocalEnvironment 樹下面產生三個temp元素，每個元素都包含一個id和info子元素，對應數據庫的記錄。
select返回的都是數組類型，因此不能setLocalEnvironment.temp = select ….，那樣會在打包時報錯，一定要標明是數組
此外，像上面那樣直接書寫SQL語句並賦值給一個數組變量，MB會在編譯和執行期間檢查SQL語法是否合格，這個特性雖然很有用，但有時候也會適得其反，比如要在Oracle使用序列來實現主鍵自增時，insert語句要寫成：
insert into example (id,info) VALUES (SEQ_EXAMPLE.nextval , ‘xxxxx’)
這裏SEQ_EXAMPLE是序列的名稱。而在MB裏面這樣會保存，提示找不到SEQ_EXAMPLE這個對象的定義。解決方法是使用ESQL的PASSTHRU函數，這個函數直接將SQL語句發送給數據庫去解析執行，就可以繞開MB的檢查。
IBM MessageBroker筆記系列（七）
這篇是針對WebService的一些使用技巧
入門
MB對WebService的支持其實不是它的強項，它的長處在於MQ，MB就是基於MQ的，所謂“消息代理”，感覺就是在消息中間件基礎上增加了“代理”功能。MB的前身是MQ Integrator，所以從字面意思上來看，也是“message -> integrator -> broker”，越來越複雜的功能。據說，WebsphereESB對於Java和webservice的支持更加完善，不過我也沒有用過。
扯了那麼多，回到主題。在MB V6.0中，對WebService的支持還是比較弱的，以單純的http節點，加上程序員在compute節點中手工操作消息樹，包括對SOAP包進行封包（envelop）和解包（extract）都要自力更生，難度比較大，且不夠直觀簡練，給人感覺是MB對webservice支持不夠，不得已而爲之。到了V6.1，情況終於有了較大的改觀，MB提供專門的webservice節點了。
所以，如果你還在看《精通WMB》，那麼webservice那一章可以先放下了，去WMBT的“樣本庫”，看看webservice的教程，會發現不僅僅有專門的SOAP節點，還對IBM的WSRR也有專門的支持，甚至還提供異步的SOAP節點。因此在MB中使用webservice，第一步推薦先去學這些樣例。特別留意使用http和soap節點時，前後的compute節點的ESQL代碼的差異，體會SOAP節點的方便。
技巧
看完SOAP節點的樣例之後，會發現裏面的那個子流，其實也挺複雜的，好像不比http節點簡單
http節點
SOAP節點
其實，Envelope和Extract節點是MB6.1纔有的，沒有他們，http節點構造webservcie會變得很囉嗦；另外，以上的流程圖，是可以通過嚮導的方式生成的，這一點非常方便。
首先在消息集項目中，“從WSDL文件”新建一個消息定義；然後將這個WSDL文件拖到某個消息流的編輯界面中，自動彈出一個嚮導，簡單地一步步走，就能生成以上的消息流。
動態設置webservice地址
在以上生成的消息流中，HTTP節點和SOAP節點都有一個屬性，用於指定webservice的請求地址，但這是寫死在節點中的。如果要在運行過程中動態設置呢？比如根據消息內容，選擇合適的URL地址進行webservice調用。
其實很簡單，只需在SOAP或HTTP節點之前的某個compute節點中，在LocalEnvironment中設置一個相應的值即可
HTTP節點：
SETOutputLocalEnvironment.Destination.HTTP.RequestURL = ‘webservice地址’
SOAP節點：
set OutputLocalEnvironment.Destination.SOAP.Request.Transport.HTTP.WebServiceURL= ‘webservice地址’
注意，切記把compute節點的“計算方式”設置爲“消息和LocalEnvironment”，總之至少要包括LocalEnvironment，否則設置了等於沒設置，compute節點不會將LocalEnvironment往下傳
當然，以上步驟也可以在Filter、Database這些節點做，那樣就沒有Input和OutputLocalEnvironment之分了
IBM MessageBroker筆記系列（八）
本來這一篇要寫ESQL的一些語法細節的，但是過幾天就要去客戶那裏部署系統了，上週也花了一個禮拜時間，一邊學Linux，一邊學怎麼在linux上部署MB。所以這一篇先討論如何在linux上安裝、配置WMB
先說一下硬件和操作系統環境：
機器：IBM的某型號刀片機，4G內存
操作系統：RED HAT LINUX 64bit企業版
業務數據庫：Oracle 10g
WMB6.1，安裝在WMQ6之上，使用DB2 9作爲代理數據庫
以上軟件都是安裝在同一臺刀片機上
另外，WMBT6.1安裝在我自己的windows機器上，用於開發MB程序，並遠程部署到服務器上
按理說參考資料應該是放在最後面的，只是我的這些安裝心得都是來自這些參考資料，爲防止我的個人經驗誤導讀者的安裝過程，所以先列出以下資料。有空慢慢看的話，還是應該以這些官方資料爲準
《messagebroker_Configuration_Administration_and_Security》
這本是權威了，除了對應的版本有些舊（WMB 6.0），整體內容還是很詳細的，幾乎所有平臺上的MB安裝、配置都有詳細的介紹。只是內容多得讓人看起來眼暈。
MB info center
內容和上面那本書差不多，比較精煉，但如果配置出了問題，未必能找到詳細的解答
最後，強烈建議，如果是linux菜鳥（像我這種），趕緊補習一些linux的基本知識，比如環境變量怎麼設置
其實安裝過程還是比較簡單的，先安裝MQ，再安裝MB。MQ比較麻煩一點，要用rpm，而MB則帶有一個Eclipse的安裝界面，和windows上和相似，跟着嚮導走就行了。安裝好之後，會發現db2也隨着MB一起裝好了
默認安裝路徑（注意大小寫）：
MB：/opt/ibm/mqsi
DB2：/opt/ibm/db2
紅皮書上已經有詳細說明，我就偷個懶，copy並解釋一下
1. Log on as root.
2. Create a database instance. Use thecommands shown here for guidance for the different platforms.
a. On AIX:
/usr/lpp/db2_08_01/instance/db2icrt -ufence_userID username
b. On Linux, Solaris, or HP-UX:
/opt/IBM/db2/V8.1/instance/db2icrt -ufence_userID username
其實，fence_userID 和username我也不太清楚是什麼，你可以參考紅皮書，或者找個db2高手問問。反正我當時使用root創建是不行的，一定要選擇其他帳號，比如你自己的用戶名
3. Log on as username
4. Create a database (in this examplecalled WBRKBKDB) using the following commands (on some platforms, an explicitpath name is required). You must insert a space between the starting period andthe tilde character in the first command shown here:
. ~/sqllib/db2profile
db2start
db2 create database WBRKBKDB
db2 connect to WBRKBKDB
db2 bind ~/sqllib/bnd/@db2cli.lst grantpublic CLIPKG 5
重點說明的是：. ~/sqllib/db2profile 這句命令，前面要有一個“.”和空格，否則沒用。執行了這條命令後，如果你對db2命令不熟悉，可以直接敲入“db2cc”，啓動db2的圖形管理界面，在裏面創建數據庫，省去了敲命令的麻煩
最後一步，在某些平臺上需要修改db2的DBHEAP屬性，至少900，才能滿足MB運行的需要，否則會造成性能低下。
由於在64位機器上跑MB，所以ODBC DSN是要32位還是64位是很頭疼的問題，因爲不同硬件平臺、操作系統的組合都有不同的要求。比如，在windows上是肯定沒有64bit支持的，而在某些操作系統（貌似是AIX），即使你全部用64bit的產品，也要配置32bit的ODBC。具體的可以參考紅皮書，裏面有詳細的列表，在這裏我只針對我使用的平臺介紹配置過程，在此特別聲明，未必適用於讀者的環境
總體思路：linux的ODBC是通過一個配置文件來描述的，在該配置文件中寫入相應的信息，然後在環境變量中設置 ODBCINI=“配置文件的絕對路徑”
編輯ODBC配置文件
1. 從你的MB安裝目錄下的ODBC64/V5.2，拷貝一份樣例配置文件：odbc64.ini，到某個目錄（比如mqm用戶的根目錄）
2. 修改該文件。在這裏我只保留DB2和ORACLE的DSN，其他的統統刪了
3. 修改你的odbc64.ini的權限：
Ensure that the odbc64.ini file has fileownership of mqm:mqbrkrs and has the same permissions as the supplied samplefile.
4. 修改ODBCINI環境變量指向你的odbc64.ini
5. 修改linux的庫路徑：LD_LIBRARY_PATH，指向db2和oracle的32位和64位odbc鏈接庫的路徑，比如我的配置如下：
LD_LIBRARY_PATH=$ORACLE_BASE/lib32:$DB2_BASE/lib32:$DB2_BASE/lib64:${LD_LIBRARY_PATH}
6. 如前所述，我對使用32還是64bit的DSN也是有點混亂，乾脆就把下面兩個環境變量也加上，以防萬一：
# for MB 64bit execution group
MQSI_LIBPATH64=/opt/ibm/db2/V9.1/lib64:${MQSI_LILPATH64}
# 32bit database lib may be needed
MQSI_LILPATH32=/opt/ibm/db2/V9.1/lib32:${MQSI_LILPATH32}
7. 最後是修改odbc64.ini文件的內容，具體的看書吧，下面是我的例子：
補充幾點注意的地方：
1. DB2的driver是不用路徑的，只寫驅動名字即可
2. DB2的Database屬性（即是數據庫的名字），要和DSN的名字一樣（即是方括號中的內容）
3. 沒事不要打開trace，會很慢
準備工作
打開一個終端，運行命令之前，先輸入：
. /opt/ibm/mqsi/6.1/bin/mqsiprofile
和前面的db2命令一樣，開頭要有“.”和“空格”
你可以把這句話加到linux用戶根目錄的“.bashrc”文件，那樣每次打開終端都會自動執行這個腳本，以設置一些環境變量，否則你是無法使用MB命令的。
確保MQ和DB2都在運行
可以通過dspmq查看MQ組件的運行狀態，如果隊列管理器沒有啓動，則通過strmqm命令啓動之。
按照前面介紹的方法，利用db2cc圖形界面查看數據庫是否運行，否則啓動之；也可以用db2start命令，記得要切換用戶到你創建db2時使用的帳號，比如：
su db2usr –c “db2start”
創建配置管理器
mqsicreateconfigmgr ConfigMgr -i root -axxxxx -q QM
創建代理
mqsicreatebroker BRK1 -i root -a xxxxx -qQM -n BRK1_DB -u db2usr -p xxxxx
創建代理時，要指定代理數據庫的DSN名稱，同時指定連接ODBC的數據庫用戶名密碼
如果一切ok，創建好代理後，在db2數據庫中會看到多了很多表，那基本上就沒問題了
如果出問題，通常都是數據庫連接，對照紅皮書檢查你的ODBC配置（這個過程很痛苦），以及訪問數據庫的用戶名、是否擁有足夠權限。實在不行，找IBM的支持吧…..
以上是連接代理數據庫，如果要連接用戶的oracle數據庫，請參考我之前寫的第六篇筆記，利用這條命令：
mqsisetdbparms brokerName -n dataSourceName[-u dataSourceUserId] -p dataSourcePassword
最後用mqsistart啓動一下，一切ok的話，就算完成萬里長征第一步了。
單純安裝好MB還是不夠的，你還要用WMBT開發、部署和調試消息流，有誰喜歡坐在風扇轟鳴、充滿輻射的機房裏coding呢？所以接下來講述如何配置WMB和WMBT，使得開發者可以遠程連接MB並進行調試
在此之前，可以參考這篇文章，實現遠程管理你的MQ
http://blog.csdn.NET/Justin4wd/archive/2008/07/16/2661131.aspx
首先在MQ中建立監聽器和服務器連接通道，具體請參考我的第三篇筆記
http://blog.csdn.net/wangchengsi/archive/2008/07/08/2625598.aspx
如果MB和WMBT是在同一臺機器，這樣做已經足夠了，但如果是遠程連接，直接連接會報告以下錯誤，則還需要在MB那裏配置ACL（訪問權限列表）
從上圖可以獲得你的機器名和用戶名
在linux打開一個終端，輸入以下命令
mqsicreateaclentry 配置管理器 -u 用戶名 -m 機器名 -x F –p
-x F表示訪問程度，F表示完全訪問
-p表示訪問Proxy，即ConfigManagerProxy，相當於可以訪問所有資源，比如代理
再次從toolkit連接MB，就可以了
之後，開發、部署、調試的過程都和本地的機器一樣，讀者可以看我之前寫的關於調試功能的配置
注意，6.0以前的MB需要安裝RAC（Rational Agent Controller）才能遠程調試，6.1開始已經不用了
IBM MessageBroker筆記系列（九）
這篇是純粹的“coding心得”，撇開MB那些囉嗦的配置不談，專門講學習ESQL的痛苦經歷，有些內容可能前面的筆記有介紹過，這裏做一個全面的彙總。雖然有些編程的tips已經忘記了，以後如果想起來還會繼續補充。
ESQL的語法和數據庫的存儲過程語句很像，雖然我從未寫過存儲過程，但是平心而論，ESQL的基本語法和概念還是很好理解的，畢竟，ESQL沒有類、對象、多態這些OOP的東西，也沒有指針、位移操作這些C的概念；沒有C的函數指針、指針的指針、內存分配這種讓新手頭暈的術語，也不像Java那樣各類框架滿天飛，開足馬力都學不過來。所以，ESQL還是很好入門的。但是，切記，只是“入門”而已。你看懂那些示例的ESQL很容易，無非是邏輯樹的增刪改；消息流也是那麼一目瞭然，消息從一個節點出來，進入另一個節點，不知不覺一個“業務流”就完成了，so simple，naïve！我一開始也是這麼覺得的，但真正動手的時候，才發覺ESQL代碼中，危機四伏！下面一一列舉
ESQL的基本類型很少，無非是數字、字符串、邏輯、時間，還有引用。數字類型包括int、float和decimal（就是double，高精度小數），一般很少會考慮三者的差別，把它們與java的等同起來，其實不然，如果隨便亂用，會冒出很多無聊而又浪費時間的bug
數據庫查詢
在使用oracle的時候，通常都會用Number類型作爲主鍵id等數字類型字段，可是你知道用select語句取Number到ESQL中是什麼嗎？是decimal。由於ESQL裏面，消息樹中的字段類型是隱式的、可變的（類似PHP），也就是你可以隨便賦任何值給某個消息節點。按理說這種腳本語言的特性可以方便編程，是好事。不過請先看完下面的描述。
數據庫插入
這個問題是最近才發現的，在64位的linux上，MB使用64位數據源訪問oracle，在一條insert語句上屢屢失敗，而這條insert語句之前在32位windows平臺上卻很正常的執行。拋出的異常提示：“oracle：String data, right truncated”，在網上搜了一下大部分人都說是數據太長，只有dw論壇上有人說可能是64bit數據源的關係，但具體原因也不清楚。請了IBM的支持來搞了半天也沒任何結果，絕望之際我乾脆用排除法，每次修改一兩個字段爲很簡單的常數（那樣總不會出問題了），在排除到最後一個字段時，才發現把一個decimal的數據插進去會有問題，如果換成float就ok了！這個問題前後浪費了我兩天，當時忍不住說了幾句髒話，一個簡單的問題搞得這麼噁心，錯誤提示也純粹誤導用戶。天知道以後換成其他平臺會不會又這樣呢？
函數調用
ESQL是弱類型的？是的，某種程度上是弱類型的，可是遇到函數調用的時候，它的類型強度簡直勝過java——你不能把一個int作爲參數傳遞給聲明爲double的參數，那樣會拋出異常。問題是有時候你根本不知道某個消息樹節點啥時變成了int或者是float或是double，就像上文說到的數據庫查詢結果。請打開debug，慢慢找吧，總會有柳暗花明的一刻
估計MB爲了照顧比較“原始”的消息格式，即非XML、而是CWF或者TDS格式的消息，ESQL的字符串類型不僅僅有字符類型“char”，還有字節類型“BLOB”和比特類型“BIT”，的確是大大方便了比特流的處理。關於字符串，發現的問題不多，下面列出幾點需要稍加註意之處。
字符串連接“||”
使用“||”連接字符串時，記得每個被連接的變量都不能爲null，否則連接後的結果就變成null了，可以用“變量 is not null”來判斷
BLOB類型
BLOB類型在ESQL中的表示方式爲X'ABCD'，實際上是一種BCD碼，每個字符表示一個十六進制，即半個字節。注意這裏要是偶數個長度，否則在打包或者部署時會報錯
和一般編程語言不同的是ESQL有時間類型的變量，這很大程度上是因爲MB裏面支持很多XML的特性，而時間類型也是標準XML中包含的，例如xsd:dateTime等等。我沒學過高級的XML，自然對這些名目繁多的時間類型之間的差別不甚瞭解，所以簡單地列出幾點比較常用的特性：
消息定義中的時間類型
消息定義文件裏頭也可以聲明某個節點類型爲timestamp（消息定義文件本質上就是XML SCHEMA文件，自然支持xsd:命名空間），不過在實踐中發現從MQ讀入的一個XML字符串，解析爲timestamp類型時，經常有一些格式上的問題而導致解析失敗，後來乾脆把timestamp全部替換爲string了，IBM的技術支持也是這麼“推薦”的，估計是他們也找不出原因所在
計算花費的時間
JAVA裏面很常用的就是通過計算系統時間之差，來得到一段代碼的運行時間毫秒數，然後用時間類可以進行格式轉換，ESQL同樣可以做到，而且更加簡單。比如要計算一個消息流的運行時間，那麼在消息流開頭用 CURRENT_TIME得到起始時間，保存在環境樹中的T1節點；然後在消息流結尾，再次用 CURRENT_TIME得到結束時間T2，兩個時間值相減，再用下面這段代碼將其轉換成毫秒數
SET OutputRoot.MRM.process_time = CAST((T2-Environment.Variables.T1) SECOND AS FLOAT) *1000;
很遺憾的，ESQL最小隻支持“秒”的時間間隔（“時間間隔”INTERVAL也是一種時間類型），不過得到的float值通常是小數位很長的，包含了毫秒信息，譬如0.2352436，因此乘以1000也完全夠用
問過IBM的人好幾次，自己也去查了不少資料，一直沒有發現ESQL中有足夠理想的全局變量或者全局常量。我們知道，ESQL的代碼層次從高到低依次是：schema->module->function or procedure，越是局部的變量，優先級越高，這一點和普通編程語言一樣。所以，沒有變量的聲明可以超越schema這一級，包括所謂的外部變量external，因此，在不同schema的消息流之間不能共享全局變量的，這個限制有時候很麻煩，比如所有消息流都要訪問同一個數據源、或者Oracle的schema，或者是你自己定義的全局常量，那你就只能在每個schema中設置了，還好schema不會很多，或者你在消息流開始的時候，從文件、數據庫等地方讀取配置參數也是一種選擇。
對於定義好的全局變量，可以用{ }進行變量值的替換，從而實現動態功能，比如 OutputBody.{myvar}.value，花括號的值會在運行期間指定。但是這樣一來ESQL的編輯器就無法判斷這個節點是否存在，會給出“無法解析該引用”的警告，這不影響使用。
剛纔說到的在schema作用域中定義的全局變量，在其他schema不能引用。但是在schema中定義的全局函數或者過程，則可以在其他schema中引用，只要在定義schema時使用PATH將其他schema導入即可，或者在調用函數時指定完整路徑，如 CALL com.xxx.GLOBAL_FUNCTION。很多人一開始會對全局函數寄予厚望，因爲可以減少代碼的重複，增加複用度，實則符合聖人們的教誨。只可惜呢，全局函數中不能使用通常在節點中的Root、ExceptionList、Environment等邏輯樹，所以我在定義全局函數時，第一個參數通常都是REFERENCE類型，用來把Environment等邏輯樹傳進去。
ESQL裏面有數組類型，但你不能DECLARE一個數組變量；有ROW類型，同時有個ROW函數專門用來產生一個ROW變量，還有個LIST函數用來產生數組。
先談談數組，數組是什麼大家都知道了，在ESQL裏面，由於不能聲明一個數組，所以我習慣把數組保存在Environment或者LocalEnvironment中。因爲消息樹的每個節點都可以往下增加子結點，所以每個消息樹的中間節點其實都是數組，我們說 set LocalEnvironment.Variables.temp = xxx ，實際上就是 setLocalEnvironment.Variables.temp[1] = xxx
至於ROW類型，《精通WMB》上說是個XML單行數據，執行這條ESQL語句：set LocalEnvironment.root = ROW('aa' AS a, 'bb' AS b)，（注意root旁邊沒有方括號[ ]）生成的XML片段如下：
<root>
<a>aa</a>
<b>bb</b>
</root>
然而，ROW其實是對應與數據庫的一行數據，僅此而已。上面的root節點相當於一行，a和b則是該行數據的字段，就這麼簡單。所以，執行select語句時，返回的就是一個ROW的數組
LIST函數是產生數組用的，例如：setLocalEnvironment.Var.root[ ] =LIST( 'aa', 'bb')，（root旁邊這次有方括號[]）產生如下XML：
<Var>
<root>aa</root>
<root>bb</root>
</Var>
詳細內容，請參考老陳的《精通WMB》後面的附錄P321（我也是最近才無意中翻到ROW和LIST）
今天聽IBM的工程師介紹了MQ和MB的特性，以及他們的區別與聯繫，覺得很通俗易懂，特此記錄，方便將來的初學者可以更快的把握這兩者的特點。
首先從概念上來說，MQ是消息中間件，MB是ESB產品
MQ負責在兩個系統之間傳遞消息，這兩個系統可以是異構的，處於不同硬件、不同操作系統、用不同語言編寫，只需要簡單的調用幾個MQ的API，就可以互相通訊，你不必考慮底層系統和網絡的複雜性。MQ作爲IBM的一個拳頭產品，雖然功能看上去很簡單，就是個消息隊列，但他卻是IBM中間件的核心，也是相比其他廠商（比如BEA）的一個優勢。MQ不僅有很高的性能，而且對各種平臺的支持非常好，幾乎你能想到的硬件和操作系統平臺以及編程語言，MQ都有專門的API支持。但MQ的功能僅限於消息隊列，至於應用A發給應用B的消息格式是怎樣的、能不能被應用B解析，MQ管不了，他只是盡力將消息發到目的地（MQ能夠應付多種異常情況，例如網絡阻塞、臨時中斷等等）。此外，如果應用的數目多了，那互相之間都要建立MQ連接，網絡拓撲就成了蜘蛛網了（就好像是最初的電話系統）
因此，我們將網絡的星型拓撲引入系統架構中，把一對一的MQ換成一箇中心節點，即ESB，MB即是IBM的ESB產品。MB處於系統的中心，起到一個總線的作用，所有應用都直接連接到MB，而不是應用之間直接互聯，這樣的好處不言而喻，可以極大的降低應用之間的耦合性。由此引出MB的兩大核心功能：消息路由和數據轉換
因爲各個應用都插入到MB上，所以應用A只管把消息丟給MB，MB自動根據消息字段、以及業務邏輯，判斷要把消息交給誰，這就像路由器一樣，根據數據包的頭把包路由到相應地址。MB內部的業務邏輯由開發人員設定，當然利用MB的Toolkit，編寫業務邏輯也非常簡單：拖一些節點，用箭頭把它們連起來，就像是畫流程圖一樣，非常形象簡單。再用MB的腳本語言（類似sql的腳本）實現邏輯判斷，通俗地說就是判斷要走哪個邏輯分支（if...else.....）。
不過各個應用是怎樣與MB連接的呢？MB提供了三種方式：MQ、文件和web service
MQ方式即是利用MQ將MB與應用互聯；文件方式則是指定某個目錄，MB會自動監視那個文件目錄，一旦文件有改變則認爲是新的消息到來，MB自動讀取指定文件的內容；而web service就不用解釋了，直接利用web service進行通訊。MB支持這些互聯方式也是爲了最大化兼容性，特別是對於那些遺留系統或是不支持主流通訊方式的系統
最後說說一個比較偏門的ESB產品：websphere ESB。聽過的人可能不多，因爲IBM在中國推廣的比較少，這個WESB很像是MB的精簡版，只支持JMS、WS等少數幾種J2EE的通訊方式，所以是爲J2EE專門準備的。不像MB，支持數十種平臺和通訊方式，例如FTP，甚至很多你根本沒聽說過的很古老的通信協議。這兩者的性能相差不少，價格也有三四倍的差距。更要命的是，原先在WESB上開發的東西，是不能遷移到MB使用的，IBM似乎鐵了心要狠狠宰我們，唯一的方法是再買一個MB，然後用MQ把WESB和MB連接起來，各跑各的
漏了一個DataPower，這東西我只是略有了解，它的賣點在於硬件支持XML，所以性能比較好，此外還支持一下web service安全方面的東東。因此，WESB是最小功能集，而MB與datapower功能上有一定重疊，如XML