java企业应用最终往往运行在某种应用服务器中，比如tomcat，jboss等。部署的单元是war, jar 或者 ear文件，开始的时候，我们可能会将多个应用放到一个单元里来开发管理和部署。随着应用的增多，为了能够让每个应用能够独立的运行不受干扰，也为了开发工作能很好的安排，往往会将各应用分开，于是会有多个war, jar,或ear文件。试想一下，假设你有订单系统，产品系统，客服系统，等，如果这些应用都被放在同一个部署单元里，当需要更新客服系统时，会短暂的导致订单系统不能正常工作，而这种情况往往是不能被接受的。另外，如果客服系统非常繁忙，由于部署在同一台物理服务器上，共享硬件资源，订单系统会受到干扰，而这也不是我们想要的。将单独的应用单独打包，单独部署成为必然。那么就面临着让这些应用通信，将它们集成的问题。
与java和php之间集成相比，java与java之间的集成，不仅可以使用共享数据库，soap，或基于http的简单的文档交换，还可以使用jms，rmi等多种方案。其中jms是j2ee众多的标准中最为成功的协议之一，很少有人针对它发表过不满意见。我们在工作中就采用了jms。和http相比，它有如下优势:
为java量身定做的
jms不仅可以传输普通的字符串，还可以直接传输java对象，并和java的其它服务结合起来，接口api也符合java的使用习惯。如果用http，我们还得要考虑如何把对象序列化等问题，比较麻烦。
使用长连接
http主要用在客户端和服务器交互上，为了能让服务器支持大量的客户端，http往往都以一种无状态和短连接的方式工作。而jms主要用在java应用之间的交互，不需要支持那么多的客户端，用长连接更加适合。典型的http服务器，可能同时要给数千数万人提供服务，如果服务器和每个客户端保持一个连接，那对服务器来说，显然是一个非常大的负担。所以，通常客户端和http的一次交互完成后，连接就断开，而下次访问时，还得要重新建立连接。jms服务器面对的客户端一般只有几个，至多几十个，和每个客户端保持连接的开销是可以接受的。典型的企业可能有如下系统：订单系统，产品系统，结算系统，等等，这些系统，每个都和集中的jms服务器保持一个连接，总连接数也是很少的，所以可以保持长连接。这客户端和jms服务器通信的时候，不必每次都建立连接，减少了网络操作，提升了性能。
异步
http操作的过程是同步的，如果要使用异步的方式工作，需要程序员再做些编码工作。而jms天生就以异步的方式来工作的，不必做过多的编码。消息的生产者一旦把消息发送出去，就可以立刻返回不必等待消息的消费结果，后续的消息消费可以自动的异步执行。将不必要立刻执行的动作异步执行，可以大大降低系统的响应时间。
可靠的消息传递
在使用http通信的过程中，如果发生了网络异常，是否要做重发，以及如何重发，会是一件很痛苦的事情。jms提供了persitent的传递模式，在这种模式时，客户端代理在发送消息之前，会先把消息持久，如果发生网络异常，客户端代理会自动处理重发，而不需要应用程序关心。jms消息的唯一编号，可以有效的阻止一个消息被重复处理的问题。
在java应用集成时，jms比http更适合。成熟的jms服务器软件很多，除了ibm的mq，jboss mq, apache activemq 都是很不错的选择。