Java 消息服務: 終于有了標準

2019-11-18 14:18:09

字體：大中小

來源：轉載

供稿：網友

　　IT界終于有了一個使用中的正式的,獨立于銷售商的,面向消息的中間件(MOM)標準了--java消息服務(JMS).JMS的成功有兩個原因:Java運動向銷售商施加了壓力,使得它們不得不遵循JMS,而且JMS標準是以一種非常廣泛的方式制定的,它幾乎不對任何人構成歧視.

在九十年代,為MOM標準工作的組織包括國際標準化組織(International Standards Organization),開放式應用組織(Open applications Group),Open組織(即原先的X/Open組織),和對象治理組織(Object Management Group).它們的工作沒有取得明顯的成效因為很少有銷售商根據這些組織的標準生產軟件,而很少的用戶公司關心這些標準.相反的是,JMS吸引了幾乎所有MOM銷售商的廣泛支持以及Java開發者不斷增多的使用,非凡是在1999年九月JMS 1.0.2發布以后(最初的JMS標準 v.1.0是在1998年八月發布的).

JMS主要是一個應用程序編程界面(API)的標準,描述了接口,類,和所有的通訊語法.JMS最初被認為是Java程序使用現存的MOM產品(非特定Java語言的)的通用API,這些產品包括IBM公司的MQSeries和TIBCO公司的Rendezvous.因為這個原因,它被設計來擴展兩種流行的消息形式--點對點以及廣播和注冊(publish-and-subscribe).但是,最先實現JMS標準的銷售商是新建立的公司,它們非凡的是被JMS標準產生的市場機遇吸引的,而不同于以前的獨立于編程語言的MOM銷售商.

新的符合JMS的MOM產品是由一些獨立銷售商和Java應用服務器程序銷售商(例如, BEA Systems, HP/Bluestone 和 Sun/iplanet)提供的.獨立JMS MOM銷售商和產品的例子如下:

Fiorano公司的FioranoMQ

IIT Software公司的SwiftMQ

Sonic Software公司的SonicMQ

Softwired公司的iBus

大多數獨立于編程語言的MOM銷售商現在也都提供JMS實用開發程序,要么是作為它們主要的MOM產品(例如IBM公司的MQSeries)上使用的原始API的替代品,或是作為一個獨立的產品(例如 TIBCO 公司的 TIB/EnterPRise for JMS),或者作為一個部分獨立的產品集合(例如Talarian公司的 Workbench for JMS).JMS近來被加入到了 Java 2 企業版(J2EE) 平臺標準和相關的企業JavaBeans (EJB) v.2.0 標準里.

一些銷售商只遵循早先的JMS標準,而其他一些銷售商則取得了J2EE v.1.3 beta 版技術的授權而且已經正在遵循更嚴格和完全的標準進行開發(參看Sun公司對一系列作為在兩個層次上與JMS兼容的產品的JMS API認證列表).一個主要MOM銷售商中值得注重的例外是微軟公司,它沒有提供對JMS的支持因為它對所有Java產品的反對態度.

JMS規定了MOM的一個相對豐富的形式.它支持多種單向(異步)消息發送方式和雙向(請求/應答)方式.消息發送可以是快速的但是沒有那么可靠,或是慢一點兒但是更可靠,在這種情況下"僅有一次"的發送方式被持久性的,基于磁盤的緩沖隊列保證了.JMS甚至引入了一種以前非同平常的特點--"持久注冊,"它答應一個應用程序暫時離線一段時間而后在它再次上線的時候繼續后來的消息發送循環.

因為它首先是一個API標準,JMS與可移植的聯系比互連性的聯系更緊密.一個按照JMS標準開發的程序能夠從一個JMS風格的MOM產品輕易的過度到另一個JMS風格的MOM產品.但是,企業實際上很少將應用程序產品在不同的MOM之間移植.就象所有的標準一樣,JMS還有一些細節沒有規定,所以JMS產品在一些方面是不兼容的.銷售商們的產品在諸如安全性,通過集束實現的可伸縮性,安裝的靈活性和認證方面是各不相同的.這意味著新的MOM中需要做一些調整.

JMS標準真正的好處在于:

提高開發者的技能(減少培訓費用).

答應對一個MOM的開發和對另一個(例如更昂貴的)MOM的復用.

答應一個應用程序包能夠相對輕易的在一個擁有廣泛種類的MOM環境中被使用.

JMS沒有定義一個線路協議或是直接確保兩個不同的JMS風格的MOM產品之間對話級的互連性.因此,一個消息必須由和發送者一樣的MOM產品接收.例如,假如發送者通過SonicMQ發送一個消息,那么接收者也必須使用SonicMQ 來接收這個消息.(這對Fiorano, IBM, IIT, Softwired, Talarian, TIBCO和其它所有銷售商的MOM產品來說是一個事實).然而,JMS確實在一定程度上幫助了軟件實現互連性,因為它定義了消息本身的一般結構并提供了大多數消息發送語法的通用性.它使得在兩個JMS MOM產品間編寫一個網關比在兩個其它級連的MOM產品間編寫一個網關要輕易.(假如你想知道更多的技術細節,請看由Richard Monson-Haefel 和 David A Chappell編寫的Java Message Service, OReilly & Associates于2001年出版.)

底線任何MOM產品都應該是Java服務程序,這也意味著所有MOM產品都應該實現JMS.在這個標準中并沒有什么重大的錯誤或是遺忘之處,而且它的被廣泛采用為用戶企業和第三方應用程序提供者帶來了好處.但是,開發者不應該總是使用JMS API.雖然它對大多數Java應用程序來說是最合適的MOM界面,但是一些特定的大程序,性能要求高的程序(大約占所有Java MOM應用程序的5%）使用語言無關的MOM的原始API將會變得更加可伸縮和實用，這些MOM包括IBM公司的 MQSeries, Talarian公司的 SmartSockets 或是 TIBCO公司的 Rendezvous.這是因為目前這些非凡產品的底層的特點,而不是因為JMS標準自身有什么限制.

使用其它語言(比方說C, C++, COBOL, C#, 或 Visual Basic)編寫的程序一般最適合非JMS 的MOM API.一些以JMS為中心的MOM現在也提供可選的C++, COM和其它類型的綁定,所以采用混合編程語言和中間件平臺的應用程序有時也會發現使用JMS是有用的,即使這時非Java的程序也是級連配置方案的一部分.

上一篇：Resin的使用和安裝（4）

下一篇：java 寫的文件瀏覽器