获得消息: J2EE 1.4 中的消息(2)

这些方法中的前六个也属于 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 时关闭它们）。

消息目标

使用 JMS 的 J2EE 应用程序通常分为两个阵营：

使用 JMS 与后端系统通信的应用程序。

使用 JMS 提供与应用程序的不同部分异步通信的应用程序。

在这一节中，我将描述在 J2EE　规范中的一个改变，它使第二种类型的应用程序更容易部署。作为例子，我将展示两个 EJB 组件，它们通过彼此发送消息进行通信。在 J2EE 1.3 中，每个 bean 都要在其部署描述符中定义一个 resource-env-ref ，它在以后要在其本地命名空间中查询它。在清单 2 所示的例子中， SenderEJB 将从 java:/comp/env/jms/target 中查询其目标，而 ReceiverEJB 将从 java:/comp/env/jms/source 中查询其目标。因为引用在不同的本地命名空间中，所以没有一种机制让应用程序汇编器（application assemb

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!