Java 消息服务 (JMS)
SOA与异步消息传送模型都适合于系统集成：
异步消息传送模型非常适于完成集成复杂系统的任务；对于此类系统，在执行操作的过程中让一个组件为另一个组件提供支持既不切实际，也不值得这样做。尽管异步消息传送放弃了同步系统所具有的某些控制功能，但大大提高了组件间相互作用的灵活性。它还增强了系统的稳定性，因为一个组件的故障并不会导致整个系统瘫痪。
SOA或者WS是主动请求，消息的接收方必须做好准备，这类系统的集成属于 整体一个组件必须为另一个组件提供支持。并且这样就很难做到高密度吞吐量。
消息的格式：标题 属性 主体 属性可以用来过滤消息。避免在消息接收者的应用程序中再去过滤处理。 消息主体可以是对象，字节流，key-value的map等。
创建连接时，将分配通信资源以及验证客户机。这是一个相当重要的对象，大多数客户机均使用一个连接来进行所有的消息传送。
客户机使用消息生产者对象 (MessageProducer) 向指定的物理目标（在 API 中由目标对象destinaction表示）发送消息。
客户机使用消息消费者对象 (MessageConsumer) 从指定的物理目标（在 API 中表示为目标对象destinaction表示）接收消息。共有两种类型的目标，分别是队列和主题
物理目标是在jms服务器上。destinaction只是在客户机上对应的抽象。destination分为队列和主题。不同的目标对应不同的传送模型：点对点模型和发布/订阅模型。
消息消费者可以支持同步或异步消息使用。
* 同步使用是指，消费者明确请求传送消息并随后使用该消息。
* 异步使用是指，自动将消息传送给为消费者注册的消息侦听器对象 (MessageListener)。当会话线程调用消息侦听器对象的 onMessage() 方法时，客户机将使用该消息。
在MessageListener中应该会维护一个列表。onMessage类似于事件的监听方法，是通过回调执行的。用来从列表中取消息处理。消费者可以选择立刻由应用程序消费消息还是放到一个队列里，由onMessage异步消费。这与线程池处理任务类似，有些线程池立刻处理任务，有些线程池是把任务放到队列里有空闲线程时执行
在JMS中，确保消息的可传输有二个方面：1.事务/确认 2.消息服务器上存储消息。
确认与事务都是在session级别支持。
确认：消息服务－>sender（消息服务确认已收到消息，并将消息置于其物理目标中并进行了相应的存储，sender方会一直阻塞，直到收到确认） receiver->消息服务(一般情况下，receiver只需给消息服务器发送一个确认，消息服务器收到确认删除消息)。有些情况还会存在消息服务到receiver的确认。比如消息服务在处理完receiver的确认之后，接着删除目标中的消息，然后再发一个确认给receiver,告诉客户机确认已得到处理，不能再次传送此消息了。
注意，确认这个词很好理解，都是授予到赠予的确认。所以，不存在sender对消息服务的确认。消息服务对receiver的确认。
事务：本地事务 分布式事务
本地事务的范围是session。所以，本地事务不可能同时包括sender发送消息以及receiver消费消息。因为这是二个会话。
＊分布式事务：应该可以将发送与接收放置到一个事务里。
本地事务针对消息的生成或消费。分布式事务针对消息的生成和消费（端到端的过程）以及与其它资源（比如数据库操作）共同组成的事务
持久性存储：
另一方面的可靠性就是确保在将持久性消息传送至消费者之前，消息服务不会将它们丢失（避免了消息服务器down掉后，可以从数据库中恢复消息）。这意味着，当持久性消息到达其物理目标时（注意时机），消息服务器必须将其置于持久性数据存储库中。