有些人认为使用SOAP over JMS是能够松散耦合异步共享服务的完美组合，我曾经和这些人谈过。但是，当我揪根问底的时候，这些人总是说JMS是“线上传输”协议，类似于HTTP。并非如此！

　　问题：为什么这是一个问题？

　　回答：直接了当地说，这是因为互操作性。

　　HTTP是标准的“线上传输”协议。HTTP同时属于OSI模型（第7层）和互联网协议集（第4或5层）的应用程序层。SOAP是“标准的”（或至少是W3C推荐的）传输不可知协议，它使用的有效负载是XML。

　　由于SOAP和HTTP的标准和技术不可知的本质，产生了很多使用不同语言并在不同的操作系统上运行的平台和工具包，只需同时符合这两个标准（或至少是这些标准的WS-I版），就能使用SOAP over HTTP进行互操作。

　　但是JMS并不是“线上传输”协议。它是Java API，要求客户端应用程序使用驻留该服务的JMS Server供应商所提供的JMS提供者库（JAR）。这类似于特定的供应商数据库要求Java应用程序使用JDBC驱动程序，才能与该数据库交互。JMS提供者库内实际使用的“线上传输”协议并没有定义（例如，它可以是IIOP，也可以是高速的非标准供应商特定的协议）。

　　因此，在大多数情况下，可以和特定供应商的JMS Server交互的惟一应用程序类型是其他基于Java的应用程序。情况变得糟糕起来。例如，如果JMS server供应商是IBM WebSphere，而服务使用者运行在Oracle的Application Server内，首先即使要使IBM的JMS客户端提供者库与Oracle的Application Server一起工作，也会出现问题，这是因为JMS实施发生抵触。一些JMS Server供应商也提供了一两个非基于Java的JMS库（例如，C++或.NET），但是其功能和范围往往有限，并且往往仅支持特定版本的特定平台和操作系统。

　　换而言之，使用SOAP over JMS时互操作性的重担由JMS server供应商的支持负责，需要其提供所有可能的服务使用者环境，而不是由服务客户端的主机环境支持负责提供标准。供应商不能升级成对所有编程语言、应用程序服务器和操作系统（包括不同版本）提供JMS支持，因此互操作性将受到很大打击。即使使用者应用程序可以使用JMS提供者，也必须先向服务使用者提供提供者库，才能调用服务，我认为这不是松散耦合。

　　因此，企业的一种设计选择是使用SOAP over JMS作为企业的异类混合系统互操作的默认机制，但我认为这从根本上就有缺点。

　　必须声明我不是说消息中间件（Message Oriented Middleware，MOM）在SOA框架中没有任何地位。实际上，事实正好相反。要实现异步消息传递、保证交互、仅交付一次和发布/订阅机制之类的功能，MOM是SOA构造的重要组成部分。这就是为什么很多供应商的ESB平台是使用底层的面向消息中间件构建的。但是，我说的是JMS不应该成为向远程服务客户端公开共享服务的首选API。使用ESB之类的中间件，带有异步接口的服务可以通过SOAP over HTTP接口公开，例如，ESB通过该接口执行面向同步调用协议的使用者和底层的内部异步消息传输机制（其内部可能使用JMS，也可能没使用）之间的切换。

　　借助现有的正确组织和管理，我相信决定除SOAP/HTTP或另一个更“开放”的协议外通过SOAP/JMS公开共享服务是正当的，其中有一些有效的例外环境（例如，高性能需求）。但是，可能最好以例外的例外为基础看待这些决定，因为对一个服务支持两种访问方法的开销不会因为配置、维护和测试成本的增加而需要额外的开销。

　　HTTP是不是SOAP的完美传输，尤其是异步服务？并非如此！但是，如果使用者不能首先调用这些服务，情况就会变得糟糕。

　　我是不是反对JMS？也不是！它是我喜爱的JavaEE API之一。但此处我并非讨论JavaEE。而是讨论SOA。

原文出处：http://dev2dev.bea.com/blog/pdone/archive/2007/03/using_soap_over.html