JMS概述

【1.面向消息的中间件】
顾名思义，面向消息的中间件就是通过使用消息(而不是命令)将企业内的组件连接起来的系统。例如库存系统可能会与工资和会计系统进行通信，如果使用面向消息的中间件将他们连接在一起，就可以在任何时候关闭任何系统，发送到这个系统的消息会放在队列中，知道系统恢复工作，这样就可以在平台，语言，API和时间方面对系统进行松散耦合。

【2.JMS 】
JMS即JAVA消息服务，在JMS中JMS消息并不同应用直接交互，而是同JMS服务器的目的地(destination)进行交互。对应发送消息的应用程序而言，它不需要关注接收数据的应用程序是否正常工作，对于未接收消息的应用程序而言，它不需要关注发送消息的应用程序是否在正常工作，因此他们仅仅同目的地进行交互。
JMS是能够异步处理客户请求的开发模型。为支持消息的异步处理，java/j2ee平台引入了JMS API。JMS支持两种消息模式：点对点发布模式/订阅模式。(对应J2EE环境而言，消息驱动Bean能够异步处理消息)
【点对点模式】的含义是:消息生产者将消息发布到Queue中，在随后的操作中将会有消息消费者从该Queue中将消息消费掉。一旦消息消费掉，queue中将不再存在它,因此其它消费者将不能获得已消费的消息。【注意 尽管Queue支持同时存在多个消息消费者，但对于单个的消息而言，仅仅会有一个消息消费者去消费它】
【发布/订阅模式】的含义是：消息生产者将消息发布到Topic中，于此同时将会有多个消息消费者(订阅者)消费发布到该Topic的消息，它和点对点不同，即发布到Topic的消息将会被所有已订阅该Topic的订阅者消费.【注意 如果消息发往Topic中时 当时不存在消息监听者(即：订阅者不处于监听状态)则该消息将丢弃掉 但有一点特殊 如果某订阅者是持久订阅者 则该消息将保留到该持久订阅者消费掉该消息为止。】

[JMS的基本构件]
【1.连接工厂】连接工厂是客户用来创建连接的对象。例如ActiveMQ提供的ActiveMQConnectionFactory.
【2.连接】 JMS Connection封装了客户与JMS提供者之间的一个虚拟的连接。
【3.会话】JMS Session是生产和消费消息的一个单线程上下文。会话用于创建消息生产者(producer),消息消费者(customer)和消息(message)等。会话提供了一个事务性的上下 
文，在这个上下文中，一组发送和接收被组合到了一个原子操作中。
【4.目的地】目的地是客户用来指定它生产的消息的目标和它消费的消息的来源的对象。JMS1.0.2规范中定义了两种消息传递域：点对点消息传递域和发布/订阅消息传递域。
点对点消息传递域的特点如下：
每个消息总能有一个消费者。
消息的生产者和消费者之间没有时间上的关联性。
发布/订阅消息传递域的特点如下：
每个消息可以有多个消费者。
生产者和消费者之间有时间上的相关性。订阅一个主题的消费者只能消费自它订阅之后发布的消息，JMS规范允许客户创建持久订阅，这在一定程度上放松了时 
间上的相关性要求。持久订阅允许消费者消费它在处于激活状态时发送的消息。
在点对点消息传递域中，目的地被成为队列，在发布/订阅消息传递域中，目的地称为主题。
【5.消息生产者】消息生产者是由会话创建的一个对象，用于把消息发送到一个目的地。
【6.消息消费者】消息消费者是由会话创建的一个对象，它用于接收发送到目的地的消息，消息的消费可以采用一下两种方式之一：
同步消费：通过调用消费者的receive方法从目的地中显式提取消息。receive方法可以一直阻塞到消息到达。
异步消费：客户可以为消费者注册一个消息监听者，以定义在消息到达时所采取的动作。
【7.消息】JMS消息由以下三部分组成：
1.消息头：每个消息头字段都有相应的getter和setter方法。
2.消息属性：如果需要除消息头字段以外的值，可以使用消息属性。
3.消息体：JMS定义的消息类型有TextMessage,MapMessage,BytesMessage,StreamMessage,和ObjectMessage.
【JMS可靠性机制】
【A.确认】
JMS消息只有在被确认之后，才认为已经被成功地消费了。消息的成功消费通常包含三个阶段：客户接收消息、客户处理消息和消息被确认。
在事务性会话中，当一个事务被提交的时候，确认自动发生。在非事务性会话中，消息何时被确认取决于创建会话时的应答模式（acknowledgement mode）。该参 
数有以下三个可选值：
Session.AUTO_ACKNOWLEDGE:当客户成功的从receive方法返回的时候，或者从MessageListener.onMessage方法成功返回的时候，会话自动确认客户收到的消
息。
Session.CLIENT_ACKNOWLEDGE:客户通过消息的acknowledge方法确认消息。需要注意的是，在这种模式中，确认是在会话层上进行：确认一个被消费的消息将自
动确认所有已被会话消费的消息。例如，如果一个消息消费者消费了10个消息，然后确认第5个消息，那么所有10个消息都被确认。
Session.DUPS_ACKNOWLEDGE:该选择只是会话迟钝第确认消息的提交。如果JMS provider失败，那么可能会导致一些重复的消息。如果是重复的消息，那么JMS 
provider必须把消息头的JMSRedelivered字段设置为true。
【B.持久性】
JMS 支持以下两种消息提交模式：
PERSISTENT:指示JMS provider持久保存消息，以保证消息不会因为JMS provider的失败而丢失。
NON_PERSISTENT。不要求JMS provider持久保存消息。
【C.优先级】
可以使用消息优先级来指示JMS provider首先提交紧急的消息。优先级分10个级别，从0（最低）到9（最高）。如果不指定优先级，默认级别是4。需要注意的是，
JMS provider并不一定保证按照优先级的顺序提交消息。
【D.消息过期】
可以设置消息在一定时间后过期，默认是永不过期。
【E.临时目的地】
可以通过会话上的createTemporaryQueue方法和createTemporaryTopic方法来创建临时目的地。它们的存在时间只限于创建它们的连接所保持的时间。只有创建该
临时目的地的连接上的消息消费者才能够从临时目的地中提取消息。
【F.持久订阅】
首先消息生产者必须使用PERSISTENT提交消息。客户可以通过会话上的createDurableSubscriber方法来创建一个持久订阅，该方法的第一个参数必须是一个
topic。第二个参数是订阅的名称。
JMS provider会存储发布到持久订阅对应的topic上的消息。如果最初创建持久订阅的客户或者任何其它客户使用相同的连接工厂和连接的客户ID、相同的主题和 
相同的订阅名再次调用会话上的createDurableSubscriber方法，那么该持久订阅就会被激活。JMS provider会象客户发送客户处于非激活状态时所发布的消息。 
持久订阅在某个时刻只能有一个激活的订阅者。持久订阅在创建之后会一直保留，直到应用程序调用会话上的unsubscribe方法。
【G.本地事务】
在一个JMS客户端，可以使用本地事务来组合消息的发送和接收。JMS Session接口提供了commit和rollback方法。事务提交意味着生产的所有消息被发送，消费的所有消息被确认；事务回滚意味着生产的所有消息被销毁，消费的所有消息被恢复并重新提交，除非它们已经过期。事务性的会话总是牵涉到事务处理中，commit或rollback方法一旦被调用，一个事务就结束了，而另一个事务被开始。关闭事务性会话将回滚其中的事务。 需要注意的是，如果使用请求/回复机制，即发送一个消息，同时希望在同一个事务中等待接收该消息的回复，那么程序将被挂起，因为知道事务提交，发送操作才会真正执行。需要注意的还有一个，消息的生产和消费不能包含在同一个事务中。

【JMS 规范的变迁】
JMS的最新版本的是1.1。它和同1.0.2版本之间最大的差别是，JMS1.1通过统一的消息传递域简化了消息传递。这不仅简化了JMS API，也有利于开发人员灵活选择消息传递域，同时也有助于程序的重用和维护。
以下是不同消息传递域的相应接口：
JMS公共 点对点域 发布/订阅域 
ConnectionFactory QueueConnectionFactory TopicConnectionFactory 
Connection QueueConnection TopicConnection 
Destination Queue Topic 
Session QueueSession TopicSession 
MessageProducer QueueSender TopicPublisher 
MessageConsumer QueueReceiver TopicSubscriber

【JMS中的消息类型】
JMS常见的消息类型有如下几种类型：
StreamMessage:Java数据流消息，用标准流操作来顺序的填充和读取。
MapMessage:一个Map类型的消息，名称为String类型，而值为java基本类型。
TextMessage:普通字符串类型，包含一个String.
ObjectMessage:对象消息，包含一个可序列化的java对象。
BytesMessage:二进制数组消息，包含一个byte[].
XMLMessage:一个XML类型的消息。
最常用的是TextMessage和ObjectMessage.
ConnectionFactory和Destination和JMS提供者有关。如果在一个JavaEE环境中，可以通过JNDI查找得到，如果在一个非JavaEE
环境中，只能通过JMS提供的接口得到。