消息中间件和JMS&XA分布式事务处理

消息中间件和JMS

    当前，CORBA、DCOM、RMI等RPC中间件技术已广泛应用于各个领域。但是面对规模和复杂度都越来越高的分布式系统，这些技术也显示出其局限性：（1）同步通信：客户发出调用后，必须等待服务对象完成处理并返回结果后才能继续执行；（2）客户和服务对象的生命周期紧密耦合：客户进程和服务对象进程都必须正常运行；如果由于服务对象崩溃或者网络故障导致客户的请求不可达，客户会接收到异常；（3）点对点通信：客户的一次调用只发送给某个单独的目标对象。
   面向消息的中间件（Message Oriented Middleware，MOM）较好的解决了以上问题。发送者将消息发送给消息服务器，消息服务器将消息存放在若干队列中，在合适的时候再将消息转发给接收者。这种模式下，发送和接收是异步的，发送者无需等待；二者的生命周期未必相同：发送消息的时候接收者不一定运行，接收消息的时候发送者也不一定运行；一对多通信：对于一个消息可以有多个接收者。
   已有的MOM系统包括IBM的MQSeries、Microsoft的MSMQ和BEA的MessageQ等。由于没有一个通用的标准，这些系统很难实现互操作和无缝连接。Java Message Service（JMS）是SUN提出的旨在统一各种MOM系统接口的规范，它包含点对点（Point to Point，PTP）和发布/订阅（Publish/Subscribe，pub/sub）两种消息模型，提供可靠消息传输、事务和消息过滤等机制。

1.JMS
   JAVA 消息服务(JMS)定义了Java 中访问消息中间件的接口。JMS 只是接口，并没有给予实现，实现JMS 接口的消息中间件称为JMS Provider，iLink实现了JMS接口，用户可以通过使用JMS接口，在iLink中进行JMS编程。 iLink支持JMS1.0.2版本。

2.JMS接口描述
   JMS 支持两种消息类型PTP 和Pub/Sub，分别称作：PTP Domain 和Pub/Sub Domain，这两种接口都继承统一的JMS父接口，JMS 主要接口如下所示：

MS父接口

PTP

Pub/Sub

ConnectionFactory

QueueConnectionFactory

TopicConnectionFactory

Connection

QueueConnection

TopicConnection

Destination

Queue

Topic

Session

QueueSession

TopicSession

MessageProducer

QueueSender

TopicPublisher

MessageConsumer

QueueReceiver,QueueBrowse r

TopicSubscriber

 

 

 

                  
   ConnectionFactory ：连接工厂，JMS 用它创建连接
   Connection ：JMS 客户端到JMS Provider 的连接
   Destination ：消息的目的地
   Session： 一个发送或接收消息的线程
   MessageProducer： 由Session 对象创建的用来发送消息的对象
   MessageConsumer： 由Session 对象创建的用来接收消息的对象

3.JMS消息模型
 JMS 消息由以下几部分组成：消息头，属性，消息体。
  
3.1 消息头(Header) - 消息头包含消息的识别信息和路由信息，消息头包含一些标准的属性如：JMSDestination,JMSMessageID 等。

 消息头

 由谁设置

JMSDestination

send 或 publish 方法

JMSDeliveryMode

send 或 publish 方法

JMSExpiration

send 或 publish 方法

JMSPriority

send 或 publish 方法

JMSMessageID

send 或 publish 方法

JMSTimestamp

send 或 publish 方法

JMSCorrelationID

客户

JMSReplyTo

客户

JMSType

客户

JMSRedelivered

JMS Provider

 

 

        
 

 

 

      

3.2 属性(Properties) - 除了消息头中定义好的标准属性外，JMS 提供一种机制增加新属性到消息头 中，这种新属性包含以下几种：
   1. 应用需要用到的属性;
   2. 消息头中原有的一些可选属性;
   3. JMS Provider 需要用到的属性。
   标准的JMS 消息头包含以下属性：

JMSDestination

消息发送的目的地

JMSDeliveryMode

传递模式， 有两种模式： PERSISTENT 和NON_PERSISTENT，PERSISTENT 表示该消息一定要被送到目的地，否则会导致应用错误。NON_PERSISTENT 表示偶然丢失该消息是被允许的，这两种模式使开发者可以在消息传递的可靠性和吞吐量之间找到平衡点。

JMSMessageID

唯一识别每个消息的标识，由JMS Provider 产生。

JMSTimestamp

一个消息被提交给JMS Provider 到消息被发出的时间。

JMSCorrelationID

用来连接到另外一个消息，典型的应用是在回复消息中连接到原消息。

JMSReplyTo

提供本消息回复消息的目的地址

JMSRedelivered

如果一个客户端收到一个设置了JMSRedelivered 属性的消息，则表示可能该客户端曾经在早些时候收到过该消息，但并没有签收(acknowledged)。

JMSType

消息类型的识别符。

JMSExpiration

消息过期时间，等于QueueSender 的send 方法中的timeToLive 值或TopicPublisher 的publish 方法中的timeToLive 值加上发送时刻的GMT 时间值。如果timeToLive值等于零，则JMSExpiration 被设为零，表示该消息永不过期。如果发送后，在消息过期时间之后消息还没有被发送到目的地，则该消息被清除。

JMSPriority

消息优先级，从0-9 十个级别，0-4 是普通消息，5-9 是加急消息。JMS 不要求JMS Provider 严格按照这十个优先级发送消息，但必须保证加急消息要先于普通消息到达。

 

 

 

 

 

 

 

 

 

 

3.3 消息体(Body) - JMS API 定义了5种消息体格式，也叫消息类型，你可以使用不同形式发送接收 数据并可以兼容现有的消息格式，下面描述这5种类型：

消息类型

消息体

TextMessage

java.lang.String对象，如xml文件内容

MapMessage

名/值对的集合，名是String对象，值类型可以是Java任何基本类型

BytesMessage

字节流

StreamMessage

Java中的输入输出流

ObjectMessage

Java中的可序列化对象

Message

没有消息体，只有消息头和属性

下例演示创建并发送一个TextMessage到一个队列：
TextMessage message = queueSession.createTextMessage();
message.setText(msg_text); // msg_text is a String
queueSender.send(message);

下例演示接收消息并转换为合适的消息类型：
Message m = queueReceiver.receive();
if (m instanceof TextMessage) {
 TextMessage message = (TextMessage) m;
 System.out.println("Reading message: " + message.getText());
} else {
 // Handle error
}

4. 消息的同步异步接收
   消息的同步接收是指客户端主动去接收消息，JMS 客户端可以采用MessageConsumer 的receive方法去接收下一个消息。
   消息的异步接收是指当消息到达时，主动通知客户端。JMS 客户端可以通过注册一个实 现MessageListener 接口的对象到MessageConsumer，这样，每当消息到达时，JMS Provider 会调用MessageListener中的onMessage 方法。

5. PTP模型
PTP(Point-to-Point)模型是基于队列的，发送方发消息到队列，接收方从队列接收消息，队列的存在使得消息的异步传输成为可能。和邮件系统中的邮箱一样，队列可以包含各种消息，JMS Provider 提 供工具管理队列的创建、删除。JMS PTP 模型定义了客户端如何向队列发送消息，从队列接收消息，浏览队列中的消息。
   下面描述JMS PTP 模型中的主要概念和对象：

名称

描述

Queue

由JMS Provider 管理，队列由队列名识别，客户端可以通过JNDI 接口用队列名得到一个队列对象。

TemporaryQueue

由QueueConnection 创建，而且只能由创建它的QueueConnection 使用。

QueueConnectionFactory

客户端用QueueConnectionFactory 创建QueueConnection 对象。

QueueConnection

一个到JMS PTP provider 的连接，客户端可以用QueueConnection 创建QueueSession 来发送和接收消息。

QueueSession

提供一些方法创建QueueReceiver 、QueueSender、QueueBrowser 和TemporaryQueue。如果在QueueSession 关闭时，有一些消息已经被收到，但还没有被签收(acknowledged)，那么，当接收者下次连接到相同的队列时，这些消息还会被再次接收。

QueueReceiver

客户端用QueueReceiver 接收队列中的消息，如果用户在QueueReceiver 中设定了消息选择条件，那么不符合条件的消息会留在队列中，不会被接收到。

QueueSender

客户端用QueueSender 发送消息到队列。

QueueBrowser

客户端可以QueueBrowser 浏览队列中的消息，但不会收走消息。

QueueRequestor

JMS 提供QueueRequestor 类简化消息的收发过程。QueueRequestor 的构造函数有两个参数：QueueSession 和queue，QueueRequestor 通过创建一个临时队列来完成最终的收发消息请求。

可靠性(Reliability)

队列可以长久地保存消息直到接收者收到消息。接收者不需要因为担心消息会丢失而时刻和队列保持激活的连接状态，充分体现了异步传输模式的优势。

              
          
  
 

 

 

 

 

 

 

 

 

6. PUB/SUB模型
JMS Pub/Sub 模型定义了如何向一个内容节点发布和订阅消息，这些节点被称作主题(topic)。
   主题可以被认为是消息的传输中介，发布者(publisher)发布消息到主题，订阅者(subscribe)从主题订阅消息。主题使得消息订阅者和消息发布者保持互相独立，不需要接触即可保证消息的传送。
   下面描述JMS Pub/Sub 模型中的主要概念和对象：

名称

描述

订阅(subscription)

消息订阅分为非持久订阅(non-durable subscription)和持久订阅(durable subscrip-tion)，非持久订阅只有当客户端处于激活状态，也就是和JMS Provider 保持连接状态才能收到发送到某个主题的消息，而当客户端处于离线状态，这个时间段发到主题的消息将会丢失，永远不会收到。持久订阅时，客户端向JMS 注册一个识别自己身份的ID，当这个客户端处于离线时，JMS Provider 会为这个ID 保存所有发送到主题的消息，当客户再次连接到JMS Provider时，会根据自己的ID 得到所有当自己处于离线时发送到主题的消息。

Topic

主题由JMS Provider 管理，主题由主题名识别，客户端可以通过JNDI 接口用主题名得到一个主题对象。JMS 没有给出主题的组织和层次结构的定义，由JMS Provider 自己定义。

TemporaryTopic

临时主题由TopicConnection 创建，而且只能由创建它的TopicConnection 使用。临时主题不能提供持久订阅功能。

TopicConnectionFactory

客户端用TopicConnectionFactory 创建TopicConnection 对象。

TopicConnection

TopicConnection 是一个到JMS Pub/Sub provider 的连接，客户端可以用TopicConnection创建TopicSession 来发布和订阅消息。

TopicSession

TopicSession 提供一些方法创建TopicPublisher、TopicSubscriber、TemporaryTopic 。它还提供unsubscribe 方法取消消息的持久订阅。

TopicPublisher

客户端用TopicPublisher 发布消息到主题。

TopicSubscriber

客户端用TopicSubscriber 接收发布到主题上的消息。可以在TopicSubscriber 中设置消息过滤功能，这样，不符合要求的消息不会被接收。

Durable TopicSubscriber

如果一个客户端需要持久订阅消息，可以使用Durable TopicSubscriber，TopSession 提供一个方法createDurableSubscriber创建Durable TopicSubscriber 对象。

恢复和重新派送(Recovery and Redelivery)

非持久订阅状态下，不能恢复或重新派送一个未签收的消息。只有持久订阅才能恢复或重新派送一个未签收的消息。

TopicRequestor

JMS 提供TopicRequestor 类简化消息的收发过程。TopicRequestor 的构造函数有两个参数：TopicSession 和topic。TopicRequestor 通过创建一个临时主题来完成最终的发布和接收消息请求。

可靠性(Reliability)

当所有的消息必须被接收，则用持久订阅模式。当丢失消息能够被容忍，则用非持久订阅模式。

 

 

 

 

 

 

 

 

 

 
 
 
 
 
 
 
 
 

7. 开发JMS的步骤
   广义上说，一个JMS 应用是几个JMS 客户端交换消息，开发JMS 客户端应用由以下几步构成：
用JNDI 得到ConnectionFactory 对象；
用JNDI 得到目标队列或主题对象，即Destination 对象；
用ConnectionFactory 创建Connection 对象；
用Connection 对象创建一个或多个JMS Session；
用Session 和Destination 创建MessageProducer 和MessageConsumer；
通知Connection 开始传递消息。

XA分布式事务处理

    在谈到 XA 规范之前，必须首先了解分布式事务处理（ Distributed Transaction Processing ， DTP ）的概念。 Transaction ，即事务，又称之为交易，指一个程序或程序段，在一个或多个资源如 数据库 或文件上为完成某些功能的执行过程的集合。 LU 人的博客 )vqfhOBA
　　分布式事务处理是指一个事务可能涉及多个数据库操作，分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。
　 X/Open 组织（即现在的 Open Group ）定义了分布式事务处理模型。 X/Open DTP 模型（ 1994 ）包括应用程序（ AP ）、事务管理器（ TM ）、资源管理器（ RM ）、通信资源管理器（ CRM ）四部分。一般，常见的事务管理器（ TM ）是交易中间件，常见的资源管理器（ RM ）是数据库，常见的通信资源管理器（ CRM ）是消息中间件。
　　通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。
    所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库。对数据库的操作发生在系统的各处但必须全部被提交或回滚。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。 LU 人的博客 8v:d?(~;~$A-Q9V D
　　一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。

　　 XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。 XA 接口函数由数据库厂商提供。

XA 与两阶段提交协议

　　具体来说，如果没有交易中间件，应用系统需要在程序内部直接通知数据库开始、结束和提交事务，当出现异常情况时必须由专门的程序对数据库进行反向操作才能完成回滚。如果是有很多事务分支的全局事务，回滚时情况将变得异常复杂。而使用 XA 接口，则全局事务的提交是由交易中间件控制，应用程序只需通知交易中间件提交或回滚事务，就可以控制整个事务（可能涉及多个异地的数据库）的全部提交或回滚，应用程序完全不用考虑冲正逻辑。
　　在一个涉及多个数据库的全局事务中，为保证全局事务的完整性，由交易中间件控制数据库做两阶段提交是必要的。但典型的两阶段提交，对数据库来说事务从开始到结束（提交或回滚）时间相对较长，在事务处理期间数据库使用的资源（如逻辑日志、各种锁），直到事务结束时才会释放。因此，使用典型的两阶段提交相对来说会占用更多的资源，在网络条件不是很好，如低速网、网络颠簸频繁，情况会更为严重。
　　当一个全局事务只涉及一个数据库时，有一种优化方式，即一阶段提交。当 AP 通知交易中间件提交事务时，交易中间件直接要求数据库提交事务，省去两阶段提交中的第一阶段，可以缩短处理一个事务的时间，以提高事务处理的效率。作为两阶段提交的一种特例，与两阶段一样，一阶段提交也是标准的。

　　通常情况下，交易中间件与数据库通过 XA 接口规范，使用两阶段提交来完成一个全局事务， XA 规范的基础是两阶段提交协议。
　　在第一阶段，交易中间件请求所有相关数据库准备提交（预提交）各自的事务分支，以确认是否所有相关数据库都可以提交各自的事务分支。当某一数据库收到预提交后，如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来，并给交易中间件一个同意提交的应答，此时数据库将不能再在该事务分支中加入任何操作，但此时数据库并没有真正提交该事务，数据库对共享资源的操作还未释放（处于上锁状态）。如果由于某种原因数据库无法提交属于自己的事务分支，它将回滚自己的所有操作，释放对共享资源上的锁，并返回给交易中间件失败应答。 在第二阶段，交易中间件审查所有数据库返回的预提交结果，如所有数据库都可以提交，交易中间件将要求所有数据库做正式提交，这样该全局事务被提交。而如果有任一数据库预提交返回失败，交易中间件将要求所有其它数据库回滚其操作，这样该全局事务被回滚。
　　以一个全局事务为例， AP 首先通知交易中间件开始一个全局事务，交易中间件通过 XA 接口函数通知数据库开始事务，然后 AP 可以对数据库管理的资源进行操作，数据库系统记录事务对本地资源的所有操作。操作完成后交易中间件通过 XA 接口函数通知数据库操作完成。交易中间件负责记录 AP 操作过哪些数据库（事务分支）。 AP 根据情况通知交易中间件提交该全局事务，交易中间件会通过 XA 接口函数要求各个数据库做预提交，所有数据库返回成功后要求各个数据库做正式提交，此时一笔全局事务结束。
　　 XA 规范对应用来说，最大好处在于事务的完整性由交易中间件和数据库通过 XA 接口控制， AP 只需要关注与数据库的应用逻辑的处理，而无需过多关心事务的完整性，应用设计开发会简化很多。