JMS学习笔记（二）
接下来的一节，我对JMS中的一些接口和一些开发步骤做个记录。方便进行简单的基于JMS的开发。
一、JMS中的接口
JMS 定义了一组封装各种消息概念的高级接口。而这些接口又因为两个消息域——PTP 和 pub/sub——进行了进一步地定义和定制。
高级接口包括：
- ConnectionFactory：一个创建Connection的受管理对象。
- Connection：连接到提供者的活动连接。
- Destination：一个封装消息目的地的身份的受管理对象，如消息的来源地和发送地。
- Session：发送和接收消息的单线程环境。为了简化，并且因为Session控制事务的缘故，通过多个线程进行并发访问受到了限制。可以将多个Session用于多线程应用程序。
- MessageProducer：用于发送消息。
- MessageConsumer：用于接收消息。
接口 （续）
下表列出了从每一个高级接口继承的特定于域的接口。
| 高级接口 |
PTP 域 |
Pub/sub 域 |
| ConnectionFactory |
QueueConnection Factory |
TopicConnection Factory |
| Connection |
QueueConnection |
TopicConnection |
| Destination |
Queue |
Topic |
| Session |
QueueSession |
TopicSession |
| MessageProducer |
QueueSender |
TopicPublisher |
| MessageConsumer |
QueueReceiver，QueueBrowser |
TopicSubscriber |
在JMS1.1版本中，对与之前的接口的声明做了些许改动。在JMS1.1之前的版本中，我们将父级接口叫做“高级接口”，而在JMS1.1版本中，将这一名称修改为“公共接口”，如下图：
| JMS 公用接口 |
PTP 域 |
Pub/sub 域 |
| ConnectionFactory |
QueueConnectionFactory |
TopicConnectionFactory |
| Connection |
QueueConnection |
TopicConnection |
| Destination |
Queue |
Topic |
| Session |
QueueSession |
TopicSession |
| MessageProducer |
QueueSender |
TopicPublisher |
| MessageConsumer |
QueueReceiver,QueueBrowser |
TopicSubsc |
二、JMS的开发步骤
开发 JMS 程序
一个典型的 JMS 程序要经过以下步骤才能开始产生和使用消息：
- 通过 JNDI 查询ConnectionFactory。
- 通过 JNDI 查询一个或者多个Destination。
- 用ConnectionFactory创建一个Connection。
- 用Connection创建一个或者多个Session。
- 用Session和Destination创建所需要的MessageProducer和MessageConsumer。
- 启动Connection。
三、重要概念介绍
消息
消息系统的核心当然是消息。JMS 为不同类型的内容提供了几种消息类型，但所有消息都是从Message接口派生出来的。
Message分为三个组成部分：
- header是一组标准字段，客户机和提供者都用它们来标识和路由消息。
- Properties提供了一个给消息添加可选标题字段的实用工具。如果应用程序需要用标准标题字段没有提供的方法对消息进行归类或分类，那么可以为消息添加一个属性来实现这种归类和分类；提供了set<Type>Property(...)和get<Type>Property(...)方法来设置和获得各种 Java 类型的属性，其中包括Object。JMS 定义了提供者可以选择性提供的一组标准属性。
- 消息的body包含将 发送到接收应用程序的内容。每一个消息接口都专用于它所支持的内容类型。
header 字段
下面列出了Message的每一个标题字段的名称、它对应的 Java 类型和字段的描述：
- JMSMessageID——类型为string
惟一标识提供者发送的每一条消息。这个字段是在发送过程中由提供者设置的，客户机只能在消息发送后才能确定消息的JMSMessageID。
- JMSDestination——类型为Destination
消息发送的Destination，在发送过程中由提供者设置。
- JMSDeliveryMode——类型为int
包含值DeliveryMode.PERSISTENT或者DeliveryMode.NON_PERSISTENT。持久性消息被传输并且只被传输一次，非持久性消息最多被传输一次。要知道“最多一次”包括根本不传输。非持久性消息在应用程序或者系统出故障时被提供者弄丢。因此要格外小心，确保持久性消息不受故障的影响。这比开销通常被认为是发送持久性消息方面的开销，在决定消息的发送模式时，必须仔细考虑，在可靠性和性能之间进行权衡。
- JMSTimestamp——类型为long
提供者发送消息的时间，由提供者在发送过程中设置。 - JMSExpiration——类型为long
消息失效的时间。这个值是在发送过程中计算的，是发送方法的生存时间（time-to-live）值和当前时间值的和。提供者不应发送过期的消息。值 0 表明消息不会过期。
- JMSPriority——类型为int
消息的优先级，由提供者在发送过程中设置。优先级 0 的优先级最低，优先级 9 的优先级最高。
- JMSCorrelationID——类型为string
通常用来链接响应消息与请求消息，由发送消息的 JMS 程序设置。响应来自另一个 JMS 程序的消息的 JMS 程序将正响应消息的JMSMessageID拷贝到这个字段中，这样，正作出响应的程序就可以与它所发出的特定请求的响应相关联。 - JMSReplyTo——类型为Destination
请求程序用它来指出回复消息应发送的地方，由发送消息的 JMS 程序设置。
- JMSType——类型为string
JMS 程序用它来指出消息的类型。一些提供者维护着一个消息类型仓库，并用该字段引用仓库中的定义类型，在这里，JMS 程序不应该使用这个字段。
- JMSRedelivered——类型为boolean
指出消息被过早地发送给了 JMS 程序，程序不知道消息的接收者是谁；由提供者在接收过程中设置。
标准属性
下面列表给出了Message的每一个标准属性的名称、它对应的 Java 类型和该属性的说明。提供者对标准属性的支持是可选的。JMS 为这些属性和将来 JMS 定义的属性保留了 “JMSX” 属性名。
- JMSXUserID——类型为string
发送消息的用户的身份。 - JMSXApplID——类型为string
发送消息的应用程序的身份。 - JMSXDeliveryCount——类型为int
已经尝试发送消息的次数。 - JMSXGroupID——类型为string
该消息所属的消息组的身份。 - JMSXGroupSeq——类型为int
该消息在消息组中的序号。 - JMSXProducerTXID——类型为string
生成该消息的事务的身份。 - JMSXConsumerTXID——类型为string
使用该消息的事务的身份。 - JMSXRcvTimestamp——类型为long
JMS 将消息发送给客户的时间。 - JMSXState——类型为int
提供者用它来维护消息的消息仓库，通常，它与 JMS 生产者和客户关系不大。 - JMSX_<vendor_name>
为特定于提供者的属性而保留
消息正文
有五种消息正文格式，每一种格式都是由一个扩展 Message 的接口定义的。这些接口是：
- StreamMessage：包含一组 Java 原始值，这些值是通过标准流操作按顺序进行填充和读取的。
- MapMessage：包含一组名称-值（ name-value ）对，其中名称是string的类型，值是 Java 原始值。
- TextMessage：包含一个String。
- ObjectMessage：包含一个SerializableJava 对象，可以使用 JDK 1.2 的 collection类。
- BytesMessage：包含一些未解释字节；允许对正文进行编码来匹配现有的消息格式。
每一个提供者都提供了一些特定于实现这些接口的其产品的类。一定要注意的是， JMS 规范命令提供者必须准备接收和处理不属于它自己的Message类的实例的Message对象。
尽管提供者处理这些“外来”对象时不能像处理自己对象那样有效，但他们必须处理这些对象来确保与所有 JMS 提供者的互操作性。
事务
JMS 事务将一组已产生的消息和一组已使用的消息组织为原子工作单位。如果事务中出现故障，那么可以“取消”出现错误之前产生和使用消息的操作。
Session对象控制事务，创建Session时将它标注为transacted。已处理的Session总是有一个当前事务，也就是说，它begin()；commit()和rollback()可以终止一个事务并自动开始另一个事务。
可以通过 Java Transaction API （JTA）XAResource API 支持分布式事务，尽管这提供者而言是可选择的。
确认
确认是通知提供者已经成功接收到消息的一种机制。
如果被处理的是接收消息的Session，则确认的处理是自动的。如果被处理的不是Session，则在创建Session时确定确认的类型。
有三种类型的确认：
- Session.DUPS_OK_ACKNOWLEDGE：消息发送的延迟回执，它通过最小化工作的重复来减少开销，只有在可以预计和处理重复消息时，才可以使用这种确认。
- Session.AUTO_ACKNOWLEDGE：在完成接收消息的方法时自动确认消息的发送。
- Session.CLIENT_ACKNOWLEDGE：通过调用Message的acknowledge()方法显式确认消息发送。
消息选择
JMS 提供了一种称为message selector的机制，以便 JMS 程序对收到的消息进行过滤和分类。
消息选择器是一个包含表达式的String，该表达式的语法是基于 SQL92 的子集的。在尝试接收消息时，对消息选择器进行求值，只有与选择器的选择标准相匹配的消息才能让程序变得可用。
选择是基于与标题字段和属性的匹配度的，正文值不能用于选择。JMS 规范中详细描述了消息选择器的语法。
JMS 和 XML
基于将大量使用String消息的假设，JMS的制定者加入了TextMessage消息类型。
他们的理由是， XML 将会成为一种流行———否则就是最流行——的表示消息内容的方法。可移植的传输机制（JMS）结合可移植的数据表示（XML）被证实是企业应用程序集成（EAI）和其他数据交换领域中的一个强大的工具。
JMS 和 J2EE
J2EE 版本1.2 要求兼容应用服务器包含 JMS API，但并不强制要求提供 JMS 提供者。
J2EE 版本 1.3 要求应用服务器提供 JMS 提供者。J2EE 版本 1.3 还引入了消息驱动 bean，为 Enterprise JavaBeans 容器增加了异步通知能力，并将此作为 EJB 2.0 规范的一部分。消息驱动 bean 可以实现MessageListener接口（请参阅本教程后面的MessageListener），并且可以通过EJB容器在消息到达在部署时指定的目的地时调用消息驱动 bean 。消息驱动 bean 包含处理消息的业务逻辑，如果需要，它还可以调用其他企业 bean 。
J2EE 版本1.4 要求 J2EE 产品包含支持点对点和发布/订阅消息的 JMS 版本 1.1 提供者。它规定， J2EE 应用程序不能使用 JMS 客户机 API 进行事务处理，事务将由 J2EE 容器处理。J2EE 版本 1.4 还要求Web 和 EJB 容器中的组件只为每一个连接创建一个活动Session。
版权声明：本文为博主原创文章，未经博主允许不得转载。