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的程序也是级连配置方案的一部分.
