數據庫操作
配置MB的用戶數據庫
前面已經講了在創建MB運行時實例時,配置數據庫的基本過程了,但那裏所指的數據庫是MB自己運行時需要的數據庫,用來存放諸如broker、執行組、消息流等的信息,而現在開發的企業應用程序,幾乎沒有不用到數據庫來存放業務數據的,所以這裏主要講述如何配置“用戶數據庫”,也即你的應用程序使用的數據庫。
下面以MB 6.1 + Oracle
一、 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/
三、 消息流節點
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 * from Database.TEST.example
假設example有id和info兩個字段,共三條記錄,那麼執行後的結果是LocalEnvironment 樹下面產生三個temp元素,每個元素都包含一個id和info子元素,對應數據庫的記錄。
select返回的都是數組類型,因此不能set LocalEnvironment.temp = select ….,那樣會在打包時報錯,一定要標明是數組
此外,像上面那樣直接書寫SQL語句並賦值給一個數組變量,MB會在編譯和執行期間檢查SQL語法是否合格,這個特性雖然很有用,但有時候也會適得其反,比如要在Oracle使用序列來實現主鍵自增時,insert語句要寫成:
insert into example (id,info) VALUES ( SEQ_EXAMPLE.nextval , ‘xxxxx’)
這篇是針對WebService的一些使用技巧
入門
MB對WebService的支持其實不是它的強項,它的長處在於MQ,MB就是基於MQ的,所謂“消息代理”,感覺就是在消息中間件基礎上增加了“代理”功能。MB的前身是MQ Integrator,所以從字面意思上來看,也是“message -> integrator -> broker”,越來越複雜的功能。據說,Websphere ESB對於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節點:
SET OutputLocalEnvironment.Destination.HTTP.RequestURL = ‘webservice地址’
-
SOAP節點:
set OutputLocalEnvironment.Destination.SOAP.Request.Transport.HTTP.WebServiceURL = ‘webservice地址’
注意,切記把compute節點的“計算方式”設置爲“消息和LocalEnvironment”,總之至少要包括LocalEnvironment,否則設置了等於沒設置,compute節點不會將LocalEnvironment往下傳
本來這一篇要寫ESQL的一些語法細節的,但是過幾天就要去客戶那裏部署系統了,上週也花了一個禮拜時間,一邊學linux,一邊學怎麼在linux上部署MB。所以這一篇先討論如何在linux上安裝、配置WMB
準備
先說一下硬件和操作系統環境:
機器:IBM的某型號刀片機,
操作系統:RED HAT LINUX 64bit企業版
業務數據庫:Oracle
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 the commands shown here for guidance for the different platforms.
a. On AIX:
/usr/lpp/db2_08_01/instance/db2icrt -u fence_userID username
b. On Linux, Solaris, or HP-UX:
/opt/IBM/db2/V8.1/instance/db2icrt -u fence_userID username
其實,fence_userID 和username我也不太清楚是什麼,你可以參考紅皮書,或者找個db2高手問問。反正我當時使用root創建是不行的,一定要選擇其他帳號,比如你自己的用戶名
3. Log on as username
4. Create a database (in this example called WBRKBKDB) using the following commands (on some platforms, an explicit path name is required). You must insert a space between the starting period and the 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 grant public CLIPKG 5
重點說明的是:. ~/sqllib/db2profile 這句命令,前面要有一個“.”和空格,否則沒用。執行了這條命令後,如果你對db2命令不熟悉,可以直接敲入“db2cc”,啓動db2的圖形管理界面,在裏面創建數據庫,省去了敲命令的麻煩
最後一步,在某些平臺上需要修改db2的DBHEAP屬性,至少900,才能滿足MB運行的需要,否則會造成性能低下。
配置ODBC連接
由於在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 file ownership of mqm:mqbrkrs and has the same permissions as the supplied sample file.
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,會很慢
創建MB的運行實例
準備工作
打開一個終端,運行命令之前,先輸入:
. /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 -a xxxxx -q QM
創建代理
mqsicreatebroker BRK1 -i root -a xxxxx -q QM -n BRK1_DB -u db2usr -p xxxxx
創建代理時,要指定代理數據庫的DSN名稱,同時指定連接ODBC的數據庫用戶名密碼
如果一切ok,創建好代理後,在db2數據庫中會看到多了很多表,那基本上就沒問題了
如果出問題,通常都是數據庫連接,對照紅皮書檢查你的ODBC配置(這個過程很痛苦),以及訪問數據庫的用戶名、是否擁有足夠權限。實在不行,找IBM的支持吧…..
以上是連接代理數據庫,如果要連接用戶的oracle數據庫,請參考我之前寫的第六篇筆記,利用這條命令:
mqsisetdbparms brokerName -n dataSourceName [-u dataSourceUserId] -p dataSourcePassword
最後用mqsistart啓動一下,一切ok的話,就算完成萬里長征第一步了。
WMBT遠程開發、調試
單純安裝好MB還是不夠的,你還要用WMBT開發、部署和調試消息流,有誰喜歡坐在風扇轟鳴、充滿輻射的機房裏coding呢?所以接下來講述如何配置WMB和WMBT,使得開發者可以遠程連接MB並進行調試
在此之前,可以參考這篇文章,實現遠程管理你的MQ
http://blog.csdn.net/Justin4wd/archive/
首先在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等邏輯樹傳進去。
數組、ROW和LIST
ESQL裏面有數組類型,但你不能DECLARE一個數組變量;有ROW類型,同時有個ROW函數專門用來產生一個ROW變量,還有個LIST函數用來產生數組。
先談談數組,數組是什麼大家都知道了,在ESQL裏面,由於不能聲明一個數組,所以我習慣把數組保存在Environment或者LocalEnvironment中。因爲消息樹的每個節點都可以往下增加子結點,所以每個消息樹的中間節點其實都是數組,我們說 set LocalEnvironment.Variables.temp = xxx ,實際上就是 set LocalEnvironment.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函數是產生數組用的,例如:set LocalEnvironment.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