像传统的RPC（远程过程调用）框架解决了两个应用之前通信的问题，但是却引申出了另外一个问题：耦合性强，调用时依赖于两边的应用。
以上就是RPC的远程调用模型。很容易看出来，两者通过网络连接，one调用two，并等待着two执行一系列的操作步骤，等two执行完成之后才能将结果返回给one。这是一种阻塞式的远程调用，这样强耦合的特点容易导致一个结果，就是当two应用执行了很久的计算的时候，one就直接挂死在那里，后面的事情都做不了。这样放在现实应用中，很容易带给用户灾难般的体验。
上述这种情况，带来的高耦合在维护时也很麻烦，当需要转移two应用的时候，one应用只能停止请求，这样每次需要转移一边的应用的时候，两边应用都要跟着受影响，会很费劲。
所以，在碰到上述问题的时候，需要一种新的解决方案，来异步处理请求，并降低两个应用之间的耦合。下面看看这个技术的一个非常典型的典型的代表JMS。
JMS是java消息服务（是目前java消息服务的一个统一的技术标准），它的思想是通过消息中间件（MOM）来接收以及发送消息。通过引入消息中间件，进行异步通信，很好的缓解了同步时两者调用中产生延时（A应用等待B处理的结果）的痛苦，并很大程度的降低了两个应用之间的耦合性，使得两边任意一个应用转移，都不会对另外一边的程序产生任何影响。（你转就转，不过我鸟事，只要之后记得重新把服务接上就行^^）。由于我使用的java，所以就介绍java中最通用的JMS技术的实现，activemq。
(备注：JMS相对于java消息处理==JDBC相对于数据库操作)
说了这么多，到底什么时候使用它呢？
1.当出现多语言之前通信的时候，activemq是一个选择。activemq的中间消息代理是java写的，自然有java客户端api，但同时它也提供了c/c++、python等其他语言的客户端。
2.当你需要多个应用通信，而又不想被RPC技术所束缚的时候。RPC是同步的，慢的，耦合性强的，基于jms的activemq可以很好的弥补这个缺陷。
3.当需要两个应用之间解耦的时候。
4.当需要事件驱动架构的时候。比如订单，下了订单后不会等待，会立马跳转到一个下单成功的页面，可是这是后台程序还在执行，当有什么状态更新的时候，后台程序会主动调用一个接口来通知你。这整个流程就是一个事件驱动模式。你不需要等待任务，任务自己执行，有更新了会主动通知你。
5.面临着高可扩展性的不断发展。SOA思想不断渗透，现今的软件开发业务各自分离，支付宝专门做支付，淘宝、天猫就专门做自己的电商平台、顺丰也有自己的软件部门来处理物流方面的问题，业务不断拆分不断细化的同时，要连接多个应用，就需要进行网络通讯，而同步的处理方式已经不能产生一个优良的用户体验，这时异步的JMS技术就能很好的解决这个问题。
JMS使得消息的发送应用与消息的接收应用能够解耦，主要是因为中间多了个消息中间件。而在JMS中使用了 destinations(目的地) . 这个术语来表示这个中间对象。在activemq中表示方法见下面spring整合的配置项：
这样，消息的接收方没必要知道接收方，接收方也没必要知道消息的发送方，两边都只需要和这个中间目的地（上图展现的只是目的地的一种--队列）打交道就行了。并且双方没有说一定需要同时连接目的地，可以发送方先连上了，发送了之后，接收方什么时候愿意接受消息就再去连就行了。
下面先让我们了解一下JMS。
先简略介绍一下JMS的API中消息的接收方和消息的发送方的具体使用。
接收方：接收方提供同步接收和异步接收的方式。
同步接收是通过实现MessageConsumer的receive方法来接收消息，这样如果destination中没有数据，一旦有了，就接收一条数据并自行处理。
异步接收是通过实现MessageListener的onMessage方法来接收消息，这样是当有消息的时候，会通知监听对象去接收消息，并调用onMessage方法获取一条数据并自行处理。
如图显示采用的是异步接收的方式。
发送方：
如上图所示，这是一个spring整合jms（activemq实现）的一个简单的发送对象数据的一种简单的方式。
JMS消息：JMS消息分为两部分，消息头和消息体，消息头包含了所有元数据，用来代表这条消息的各个属性。消息体则是发送的数据内容。当发送端调用send发送消息的时候，消息头的属性 JMSD estination（目的地）、JMSE xpiration（消息生存时间）、JMSM essage ID（唯一标识这条消息的id）、JMSP riority（消息的优先级）、JMSTimestamp（消息发送的时间）、JMSDeliveryMode（消息的发送模式--持久还是非持久）就会被自动设置了。而消息体很简单，里面存了你需要发送的数据，可能是字符串可能是二进制数据，获取之后经过一定处理可以直接取出来。
JMS Domains：PTP（点对点）和发布/订阅。
PTP：相当于发送一条信息，只有一个接受者能够收到这条信息。它使用的destinations是队列（queue）。
发布/订阅：相当于发送一条信息，所有注册了的接受者都能收到这条信息。它使用的destinations是主题（topic）。
通过以上的说明，对于JMS应该有了一个初步的理解，其实平时使用activemq，基本也就是在使用JMS的api，除非你想有特殊功能，需要activemq来提供。
activemq的各部分组件：
连接器：
为了传递数据，生产者和消费者（都是客户端）需要连接broker代理，客户端和这个broker要连接实际上需要通过 Transport connectors处理。这些连接器都是要通过一定的传输协议进行连接，下面图展现的是这些连接协议和简略的介绍一下他们所使用的场景：
下面来说说activemq。作为一个消息队列，很多人选它，不光是他能解耦、异步处理，而且还是因为它作为一个消息队列，能够保证消息发送失败的时候进行存储。那么它的存储方式是如何的呢？什么时候需要存储而什么时候又不需要呢？
对于队列，很简单，先进去的先存储，在activemq中，推荐使用kahaDB进行文件存储。
对于消息可达性要求高的应用，需要使用存储来保证可靠性。而对于那些实时消息应用则不需要存储，这样可以保证性能。
一旦出现系统异常，消息队列中没有被MessageListener的onMessage方法获取的消息都会被存储下来，在下次系统启动的时候会自动完成获取那部分存储下来的数据，并完成onMessage方法的整个步骤。