JMS 学习记录

. JMS基本概念
JMS(Java Message Service)是访问企业消息系统的标准API,它便于消息系
统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发。

2. JMS基本功能
JMS是用于和面向消息的中间件相互通信的应用程序接口。它既支持点对点(point-to-point)的域，又支持发布/订阅(publish/subscribe)类型的域，并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。JMS还提供了另一种方式来对您的应用与旧的后台系统相集成。
3. WebLogic JMS Server介绍
WebLogic Server8.1符合JAVA规范,并通过Sun Microsystems J2EE 1.3认
证.作为WebLogic的一部分,当然WebLogic JMS Server也完全遵从JMS规范,还支持集群,并可以应用于实际企业系统.下图是WebLogic JMS Server体系结构.图中可以看到WebLogic JMS Server主要组件有: WebLogic JMS servers(用于消息通信),Java客户端,JNDI(用于域名查找), 后备存储(用于持久消息存储,基于文件或者JDBC数据库).

二. WebLogic JMS特性
1. 消息通信模型
JMS 支持两种消息通信模型：点到点（point-to-point）（PTP）模型和发布/订阅（Pub/Sub）模型。除了下列不同之外，这两种消息通信模型非常地相似：
PTP 模型规定了一个消息只能有一个接收者;Pub/Sub 模型允许一个消息可以有多个接收者。
2. 消息组成
消息传递系统的中心就是消息。
一条 Message 分为三个组成部分：
· 头（header）是个标准字段集，客户机和供应商都用它来标识和路由消息。
· 属性（property）支持把可选头字段添加到消息。如果您的应用程序需要不使用标准头字段对消息编目和分类，您就可以添加一个属性到消息以实现这个编目和分类。提供 set Type Property(...) 和 get Type Property(...) 方法以设置和获取各种 Java 类型的属性，包括 Object。JMS 定义了一个供应商选择提供的标准属性集。
· 消息的主体（body）包含要发送给接收应用程序的内容。每个消息接口特定于它所支持的内容类型。
JMS 为不同类型的内容提供了它们各自的消息类型，但是所有消息都派生自 Message 接口。
· StreamMessage：包含 Java 基本数值流，用标准流操作来顺序的填充和读取。
· MapMessage：包含一组名/值对；名称为 string 类型，而值为 Java 的基本类型。
· TextMessage：包含一个 String。
· ObjectMessage：包含一个 Serializable Java 对象；能使用 JDK 的集合类。
· BytesMessage：包含未解释字节流: 编码主体以匹配现存的消息格式。
· XMLMessage: 包含XML内容。扩展TextMessage,XMLMessage 类型的使用，使得消息过滤非常便利。
3. 消息确认模式
非事务性会话中，应用程序创建的会话有5 种确认模式,而在事务性会话中，确认模式被忽略。
五种确认模式说明:
· AUTO_ACKNOWLEDGE：自动确认模式。一旦接收方应用程序的方法调用从处理消息处返回，会话对象就会确认消息的接收。

· CLIENT_ACKNOWLEDGE：客户端确认模式。会话对象依赖于应用程序对被接收的消息调用一个acknowledge()方法。一旦这个方法被调用，会话会确认最后一次确认之后所有接收到的消息。这种模式允许应用程序以一个调用来接收，处理并确认一批消息。注意：在管理控制台中，如果连接工厂的Acknowledge Policy（确认方针）属性被设置为“Previous“（提前），但是你希望为一个给定的会话确认所有接收到的消息，那么就用最后一条消息来调用acknowledge()方法。

· DUPS_OK_ACKNOWLEDGE 模式
在 DUPS_OK_ACKNOWLEDGE 模式下，会话在使用了十条消息后进行确认。目前无法对该值进行配置。与 AUTO_ACKNOWLEDGE 或 CLIENT_ACKNOWLEDGE 模式不同的是，会话线程不会阻塞等待代理确认，因为在 DUPS_OK_ACKNOWLEDGE 模式下不请求任何代理确认。

这意味着，无法保证只对消息传送和使用一次。一般来说，不会非常频繁地重新传送消息；这种情况只会在发生故障（代理未收到它所传送的消息的客户机确认）时出现。如果客户机对重复传送并不在意，则应使用 DUPS_OK_ACKNOWLEDGE 模式。

由于客户机确认按批次发送且客户机线程不会阻塞，因此消息吞吐量通常远高于其他模式。

NO_ACKNOWLEDGE 模式
在 NO_ACKNOWLEDGE 模式下，代理会代表客户机进行客户机确认，因此不能保证消费者客户机已成功地对消息进行了处理。

如果消息吞吐量很重要，而传送的可靠性并不是很重要，则请使用此模式。例如，可能会出现以下情况：定期发送消息的时间间隔很短，因而消息负荷很高，此时丢失一些消息不会有太大的影响。

此模式扩展了 JMS 规范，只应由不需要与其他 JMS 提供者配合使用的客户机使用。

事务
上述客户机和代理的确认过程同样适用于编组为事务的 JMS 消息传送。在此类情况下，客户机和代理确认在事务（包括事务中包含的所有消息）级别进行。当提交事务时，将自动发送代理确认。

代理会跟踪事务，使它们可以在出现故障时进行提交或回滚。该事务管理也支持本地事务（较大的分布式事务的一部分，请参见分布式事务）。代理会一直跟踪这些事务的状态，直到它们被提交。当代理启动时，它会检查所有未提交的事务，在默认情况下，回滚未处于 PREPARED 状态的所有事务（必须手动解决）。