2001年08月28日 Java 消息服务: 终于有了标准 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的程序也是级连配置方案的一部分.