【IT168 技术文章】

        JMS 1.1

　　兼容 J2EE 的应用服务器现在需要支持 1.1 版的 Java 消息服务(Java Message Server，JMS)规范，这也许是新版本 J2EE 规范中最明显的改变。JMS 1.1 完全向后兼容 J2EE 1.3 规范所要求的 JMS 1.1，所以应当不需要改变现有的应用程序。值得强调的是，除非需要向后兼容性，否则没有理由用老的队列和主题接口编写新的 JMS 应用程序。新的应用程序应当只使用新的统一接口，如清单 1 中的例子所示。

　　清单 1. 展示统一 JMS 接口的例子

　　正如 Bobby 在他的文章中所说的，统一接口不仅简化了消息编程模型，它们还使应用程序可以用一个事务 Session 接收来自队列的消息，并向主题发送消息(或者相反)。这意味着可以在同一个事务工作单元中进行发送和接收，而无需借助于 bean 或者容器管理的事务。

　　J2EE 对 JMS 使用的限制

　　像以前版本的 J2EE 规范一样，1.4 版对 JMS 的使用有一些限制。我将在本节分析这些限制。

　　限制的接口

　　尽管许多开发人员可能不知道，但是 J2EE 规范对于 J2EE 应用程序如何使用 JMS API 总是有一些限制。例如，以下接口用于 JMS 提供者与应用服务器之间的集成(它们是在 JMS 规范中描述的 Application Server Facilities 的一部分)，因而不能被应用程序使用：

　　javax.jms.ServerSession

　　javax.jms.ServerSessionPool

　　javax.jms.ConnectionConsumer

　　All javax.jms.XA interfaces

　　限制的方法

　　对于那些“应用程序组件在阻止创建线程的容器中不能执行”的方法，J2EE 1.3 规范给出了让人困惑的声明。EJB 容器不允许应用程序创建线程，但是一个 Web 容器 可以 允许应用程序这样做。结果，在 J2EE 1.3 中，根据所使用的 Web 容器，可以调用或者不可以调用这些方法。幸运的是，J2EE 1.4 规范删除了这些令人困惑的说法，只是说明下列方法只能被运行在客户容器中的应用程序所使用——换句话说，它们不会在 Web 或者 EJB 容器中调用：

　　javax.jms.ServerSession method setMessageListener()

　　javax.jms.ServerSession method getMessageListener()

　　javax.jms.Session method run()

　　javax.jms.QueueConnection method createConnectionConsumer()

　　javax.jms.TopicConnection method createConnectionConsumer()

　　javax.jms.TopicConnection method createDurableConnectionConsumer()

　　javax.jms.MessageConsumer method getMessageListener()

　　javax.jms.MessageConsumer method setMessageListener()

　　javax.jms.Connection method setExceptionListener()

　　javax.jms.Connection method stop()

　　javax.jms.Connection method setClientID()

　　这些方法中的前六个也属于 Application Server Facilities，因此将它们排除在外是合理的，但是其他的方法呢?禁止 setMessageListener() 和 getMessageListener() 的决定会给大多数应用程序开发人员带来最大的问题。这些方法用于注册 MessageListener ，这样当消息到达目标时就会调用其 onMessage() 方法。在 Web 和 EJB 容器中不允许它的原因是因为 上下文。调用 EJB 和 servlet 方法时，容器会保留与线程相关联的上下文，如当前事务和安全 principal。JMS 提供者调用 MessageListener 时，应用服务器没有办法拦截这个调用并添加适当的上下文。应当用同步方法 receive() 轮询消息或者考虑使用消息驱 bean 替代这些方法。

　　尽管上面列出的最后三个方法在以前版本的 J2EE 应用程序也是禁止的，但是您仍然想知道为什么不允许它们。这要追溯到应用服务器管理连接的方式。它可能希望在不同的应用程序之间共享同一个连接，如果应用程序可以调用改变连接的状态的方法，那么它就不能这样做了。只有在使用 MessageListener 时 setExceptionListener() 和 stop() 方法才是有用的，因此，不能调用它们不是个问题，而应当能够在管理式地定义连接工厂时设置一个客户标识符。

　　每个 Connection 有一个 Session

　　还有一个新限制可能使现有的应用程序无法使用。J2EE 规范现在规定一个应用程序中，对每一个 Connection 只能有一个活动的(未关闭) Session 。换句话说，调用了 createSession() 后，如果在关闭原来的 Session 之前再次调用它，就会抛出一个异常。

　　规范没有解释为什么会增加这个限制，不过我将给出我的理论。最新版本的 Java Connector Architecture (JCA) 规范建议 JMS 提供者可以实现为 JCA 资源适配器。在 JCA 编程模型中，就像 JDBC 一样，只有两个对象( ConnectionFactory 和 Connection )，而在 JMS 中有三个( ConnectionFactory 、 Connection 和 Session )。更重要的是，在 JCA 中，与事务相关联的是 Connection ，而在 JMS 中是 Session 。因而，如果在 JMS 中允许每个 Connection 有多于一个 Session ，那么 Connection 实际上就会与多个事务相关联。总之，这种限制使得 JMS 提供者更容易实现为 JCA 资源适配器。

　　那么所有这些对应用程序开发人员有什么意义呢?在过去，您也许曾经试图利用 JMS Connection 对象的多线程本性，并将它们缓冲到 EJB 组件或者 servlet 的静态变量中。与之相反，现在应当只是将 Connection 做为 EJB 组件的一个实例变量缓冲，并保证在任何时刻只有一个会话，或者只在每次需要 Session 时创建一个 Connection 。大多数应用服务器会对对象实现某种缓冲池，所以它没有您所担心的那么昂贵(只是要记住在完成 Connection 时关闭它们)。