类似于rmi、hessian、burlap等远程方法调用，它们都是同步的，所谓同步调用就是客户端必须等待操作完成，如果远程服务没有返回任何响应，客户端会一直等待直到服务完成。
异步调用则不同，客户端发送完消息无需等待服务处理完成便可立即返回，就像发送完消息就立刻被处理成功一样。
在异步处理的世界，我们可以把消息的发送比作一个邮局系统。比如我们要给某个人发送信件，我们只需准备好信件，把它投入邮局的邮箱即可，我们不必关心邮件如何送出、能否到达，邮局系统会保证信件最终送达到我们希望的接收者手中。和邮局系统类似，当一个应用向另一个应用发送消息，两个应用之间没有直接的关联，而是发送消息的应用把消息交给一个消息系统，由消息系统确保把消息传递给接收消息的应用。
在异步消息系统中有两个重要的角色：消息broker和destination。当一个应用发送一条消息，它会直接把它发送给消息broker，消息broker扮演的就是邮局，它会确保消息被传递到特定的destination。当我们邮寄信件时，信件的地址尤为重要，消息系统中的地址就是destination。不过与信件中的地址不同，destination中定义的不是接收者是谁，而是消息被放在消息broker的什么地方（具体指queue或者topic），destination其实更像邮局系统中的邮筒。
尽管存在各种各样的消息系统，每个消息系统都有各自的消息路由方式，但总体上有两种类型的destination：queue和topic，它们也各自关联着一种特定的消息处理模型：点对点(point-to-point/queue)和发布/订阅(publish/subscribe/topic）
在点对点模型中，每个消息只有一个发送者和一个接收者。如下图所示：
在点对点模型中， 消息broker会把消息放入一个queue。当一个接收者请求下一个消息时，消息会被从queue中取出并传递给接收者。因为消息从queue中取出便会被移除，所以这保证了一个消息只能有一个接收者。
尽管消息队列中的每个消息只有一个接收者，但这并不意味着只能有一个接收者从队列获取消息，可以同时有多个接收者从队列获取消息，只不过它们只能处理各自接收到的消息。其实这就像在银行排队一样，排队的人可以看做一个个消息，而银行工作窗口便是消息的接收者，每个窗口服务完一个客户之后都会让队列中的“下一个”到窗口办理业务。
还有，如果多个接收者监听一个队列，我们是很难确定到底哪个接收者处理哪个消息的。不过这也不一定不好，因为这样就使得我们很方便的通过增加接收者来拓展应用处理能力了。
在发布/订阅模式中，消息是被发送到topic中的。就像queue一样，很多接收者可以监听同一个topic，但是与queue每个消息只传递给一个接收者不同，订阅了同一个topic的所有接收者都会收到消息的拷贝，如下图所示：
从发布/订阅的名字中我们也可看出，发布者发布一条消息，所有订阅者都能收到，这就是发布订阅模式最大的特性。对于发布者来说，它只知道将消息发布到了一个特定的topic，它不关心谁监听这个topic，这也就意味着它并不知道这些消息是被如何处理的。
在具体介绍异步消息系统带来的好处之前，我们先看看同步系统的局限性：
同步会话意味着等待：当客户的调用远程服务的方法时，客户端必须等待远程方法结束之后才能继续，如果客户端与远程服务交流频繁或者远程服务响应过慢，会影响客户端的性能
客户端和服务接口耦合：如果服务接口发生改变，所有客户的都需要修改
客户端和服务位置耦合：客户端要想使用远程服务就必须配置服务的地址，如果网络拓扑发生变化，客户端需要重新配置服务地址
客户端和服务可用性耦合：如果服务不可用，那么也会导致客户端不可用
下面我们再看一下异步消息系统是如何解决这些问题的。
无需等待
当一个消息被异步发送，客户端不需要等待它处理完成。客户端直接把消息扔给broker然后做其它事情，broker负责把消息送到合适的目的地。
因为客户端不需要等待，所以客户端的性能会有很大的提升。
面向消息和解耦合
不同于传统基于方法调用的rpc会话，消息异步发送是以数据为中心的。这就意味着客户端不需要和某个方法签名绑定，任何queue或topic的订阅者都可以处理客户端发送的消息。客户端不必再关心服务方任何相关的问题。
位置独立
同步rpc服务的调用是通过网络地址定位的，这就意味着客户端无法摆脱网络拓扑的变化。如果服务的ip或端口发生改变，客户端也需要做相应的改变。
相反，异步消息系统中的客户端并不关心服务所在的位置及其如何处理消息，它只负责将消息发送到特定的queue或topic。所以，服务位于什么地方都无所谓，只要它们能够从queue或topic中获取消息即可。
在点对点模式中，可以很方便的利用位置独立这个特性创建一个服务集群。客户端不需要关心服务的位置，集群中各个服务仅需知道broker的位置，并从同一个queue获取消息，如果服务压力过大无法及时处理消息，我们只需要在集群中增加一个服务实例去监听同一个queue即可。
在发布/订阅模式中，位置独立同样有很重要的作用。多个服务可以订阅同一个topic，他们都能获取到topic中的每个消息，但是对各个服务的处理可以不同。比如我们有一个服务集合订阅了一个接收新员工消息的topic，所以这些服务都可以得到每个新员工消息，一个服务可以将新员工添加到薪资系统，另一个服务可以将新员工增加到hr系统，还有服务负责赋予新员工各种系统权限等等，每个订阅topic的服务都能对各自的消息做出自己的处理。
可靠性保证
当一个客户端和服务通过同步方式进行交互时，如果服务出现任何问题挂掉，都会影响客户端正常工作。但是当消息是异步发送时，客户端与服务之间被broker隔离，客户端只负责发送消息，即使当发送消息时服务挂掉，消息也会被broker存储起来，等到服务可用时再接着进行处理。
java message service是一个java标准，它定义了一套与消息broker交互的通用api。在jms出现之前，每一种消息broker都有自己独特的一套api，使得应用代码无法在不同的broker之间适用。但是通过jms，所有与broker交互的代码就可以适用一套通用的api，就像jdbc一样。
当然spring对jms也提供了支持，即jmstemplate。通过jmstemplate，我们可以更加方便地向queue和topic发送和接收消息。后面我们会详细介绍spring对jms的实现，但是在发送和接收消息之前，我们需要现有一个broker。
我们要想发送消息到activemq，就需要先创建到它的连接，<code>activemqconnectionfactory</code>就是jms中负责创建到activemq连接的工厂类。在spring中配置方式如下：
除此之外，spring为activemq提供了专门的命名空间，我们可以使用spring的activemq命名空间来创建连接工厂。首先要在配置文件中声明amq命名空间：
然后我们就可以利用<code><amq:connectionfactory></code>元素来声明一个连接工厂：
需要注意，<code><amq:connectionfactory></code>元素是专门针对activemq的。如果我们用到的是其它broker，就需要用另外的标签元素或注入另外的工厂bean。上面元素中的<code>brokerurl</code>指定了activemq在服务器中的ip和端口，上面端口值就是activemq默认端口。
除了要有一个连接工厂之外，我们还需要知道消息发送到的destination。上面讲过了，消息的destination只有两类queue或者topic，在spring中，我们需要配置queue或topic对应的bean。
配置一个activemq queue bean：
配置一个activemq topic bean：
上面例子中<code>c:_</code>属性代表的是构造器参数，它指定了queue或topic的名称。
像连接工厂一样，spring提供了另外一种配置destination的方式，就是通过spring activemq命名空间进行配置。
使用<code><amq:queue></code>元素配置一个queue：
使用<code><amq:topic></code>元素配置一个topic:
上面元素中<code>physicalname</code>属性代表消息通道的名称，也就是queue和topic的名称。
通过上面两个组件的配置，我们就可以向activemq发送和接收消息了。发送和接收消息我们使用的是spring提供的jmstempate，它是spring对jms的抽象，下面就详细介绍jmstemplate的使用。
虽然jms提供了一套与各种broker交互的通用api，但实际使用起来并不是很方便，我们先看一下使用普通jms api与broker交互的代码。
上面代码中我们可以看到，为了发送一条 “hello world”的消息却用了20多行代码，就像jdbc一样，我们大部分代码都是再做一些重复性的准备工作，比如获取连接、创建session、异常处理等等。其实接收消息的代码也是如此，在jdbc中，spring提供了一个jdbctemplate来简化jdbc代码开发，同样，spring也提供了<code>jmstemplate</code>来简化jms消息处理的开发。
jmstemplate其实是spring对jms更高一层的抽象，它封装了大部分创建连接、获取session及发送接收消息相关的代码，使得我们可以把精力集中在消息的发送和接收上。另外，<code>jmstemplate</code>对异常也做了很好的封装，其对应的基本的异常为<code>jmsexception</code>。
要使用jmstemplate，就要在spring配置文件中配置它作为一个bean：
因为jmstemplate需要先和broker进行连接，所以它需要依赖一个connectionfactory。
发送消息
假如我们有一个业务需要用到异步消息发送，我们先定义这样一个业务接口：
上面接口中只有一个方法，就是发送消息。
我们写这个接口的实现，在这个接口实现中，我们就是用<code>jmstemplate</code>实现异步消息发送：
我们可以看到，我们业务的实现中注入了一个<code>jmsoperations</code>对象，这个对象就是<code>jmstempate</code>的实现。<code>jmsoperations</code>的<code>send()</code>方法有两个参数，第一个是消息的<code>destination</code>，第二个便是具体的<code>message</code>，在上面例子中message是通过一个匿名内部类<code>messagecreator</code>的<code>createmessage()</code>方法构造的。
通过上面例子可以发现，通过<code>jmstempate</code>，我们只需要关心发送消息即可，所有的连接和session的维护都由<code>jmstempate</code>负责。
设置默认destination
大部分情况下，一个业务消息的destination是相同的，所以我们不必每次发送都填写destination，我们可以在配置文件中对其进行配置：
在上面配置中我们默认destination值为<code>biz1.queue</code>，因为它只是声明了一个名称，并没有说明是哪种类型的destination，所以，如果存在相同名称的queue或topic，就会自动与之匹配，如果不存在，则会默认创建一个相同名称的queue。如果我们想指定destination的类型，我们可以通过配置让其依赖之前配置的destination bean即可：
当我们配置了默认destination，我们就可以在发送消息时省略第一个参数了：
其实上面的<code>send()</code>方法可以变得更简单，我们可以利用消息转换器。
使用消息转换器发送消息
除了<code>send()</code>方法之外，<code>jmstemplate</code>还提供了<code>convertandsend()</code>方法。与<code>send()</code>方法需要依赖一个<code>messagecreator</code>不同，<code>convertandsend()</code>方法只需要传入你想发送的消息即可。下面我们用<code>convertandsend()</code>实现接口中的<code>sendmessage()</code>方法：
<code>convertandsend()</code>方法会自动把你发的消息转换成<code>message</code>，具体如何转换的由<code>org.springframework.messaging.converter.messageconverter</code>的实现来决定。我们先看一下<code>messageconverter</code>接口：
我们可以看到这个接口中只有两个方法而且很容易实现。其实大部分情况下我们不需要自己去实现这个接口，spring已经为我们提供给了很多常用的实现：
默认情况下，当<code>jmstemplate</code>的<code>convertandsend()</code>方法使用的是<code>simplemessageconverter</code>。但是我们也可以通过配置把我们自定义的<code>messageconverter</code>作为属性注入到<code>jmstemplate</code>中，比如我们有个一<code>messageconverter</code>的实现bean：
我们可以把上面这个bean注入到jmstemplate中：
消费消息
对于消费来说，<code>jmstemplate</code>使用起来比发送更简单，只需要调用<code>jmsoperations</code>的<code>receive()</code>方法即可：
当调用 <code>jmsoperations.receive()</code>方法时，它会尝试从broker获取消息，若此时没有消息，<code>receive()</code>方法会一直等待直到有消息产生。前面例子中，当我们发送消息的时候消息被封装成的是<code>objectmessage</code>，所我们在获取的时候可以再将其转换回<code>objectmessage</code>。
这里有一点需要注意，当调用<code>message.getobject()</code>方法时会抛出<code>jmsexception</code>，这个异常是属于jms api的。<code>jmsexception</code>是一个检查异常，在jms操作中会抛出各种各样的<code>jmsexception</code>，但是前面我们使用<code>jmstemplate</code>时并没有捕获任何<code>jmsexception</code>，是因为<code>jmstemplate</code>内部已经将需要检查的<code>jmsexception</code>转换成了非检查的spring自己的<code>jmsexception</code>。在上面代码中因为调用的是<code>message.getobject()</code>方法而不是<code>jmstemplate</code>的方法，所以我们需要捕获<code>jmsexception</code>。但是按照spring的设计理念，我们应该尽量减少检查异常，所以在catch块里面我们又通过jmsutils工具把<code>jmsexception</code>转换成了非检查的<code>jmsexception</code>。
同样，就行消息的发送一样，我们也可以使用jmstemplate的<code>receiveandconvert()</code>方法替换<code>receive()</code>方法：
我们看到，因为使用的是<code>jmstemplate</code>的方法，所以我们不需要再捕获<code>jmsexception</code>检查异常。
不管使用<code>mstemplate</code>的<code>receive()</code>还是<code>receiveandconvert()</code>方法消费消息，它们都是同步的。也就是说接收者在消息到达时需要等待。这样看起来是不是有点奇怪？发送消息时是异步的，接收消息时却是同步的。
这也就是为什么会有下面的消息驱动pojo出现的原因，下面我们就看一下如何实现异步的接收消息。
我们上面已经知道，<code>jmstemplate</code>的<code>receive()</code>方法是一个同步方法，在消息到达之前这个方法会挂起一直等待直到消息出现，如果这样的话，我们的应用可能会出现一直等待消息而不能做其它事情的情况。为何不让应用先去处理其它业务，当消息出现时再告知应用处理呢？
在ejb中，<code>message driven bean（mdb）</code>就可以实现异步的处理消息。spring在这方面参考了ejb3对mdb的实现，不过在spring中我们把它称作消息驱动pojo，也就是<code>message-driven pojo（mdp）</code>。
要想在消息出现时得到通知，那么就需要一个监听器监听queue或者topic，之所以称作消息驱动pojo，意识因为监听器是消息驱动的，而是因为这个监听器本身就是一个普通的pojo对象，不需要依赖任何接口：
有了这个pojo对象，下面只需要做简单的配置即可。
赋予上面pojo接收消息能力的关键在于将其配置成一个spring消息监听器，spring的jms命名空间提供了所有相关配置。
首先，我们现需要把上面的pojo对象声明成一个bean：
其次，把messagehandler变成一个消息驱动pojo，即把这个bean声明成一个listener：
通过上面配置，消息监听容器里面就多了一个消息监听器。消息监听容器是一个特殊的bean，它能够监听jms的destination，监听消息的到达。一旦消息到达，消息监听容器会接受这个消息并将其发送给所有相关的listener。下面这幅图展示了整个内部处理过程：
为了配置监听容器和监听者，我们用到了jms命名空间中的两个元素。<code><jms:listener-container></code>是父元素，<code><jms:listener ></code>是子元素。<code><jms:listener-container></code>依赖一个<code>connectionfactory</code>，这样它的各个<code><jms:listener ></code>就可以监听消息了。<code><jms:listener ></code>用来定义具体接收消息的bean及方法。按照上面的配置，当消息到达queue时，<code>mymessagehandler</code>的<code>handlemessage</code>方法便会被调用。
需要注意到是，我们的<code>messagehandler</code>还可以实现一个<code>messagelistener</code>接口，这样的话就不需要再单独指定消息处理的方法了，<code>mymessagehandler</code>的<code>onmessage()</code>方法会自动被调用。messagelistener接口定义如下：
我们写一个简单的实现类：
然后直接配置listener即可（不用再配置method方法属性）：