面向Web的JMS应用系统

核心提示： 内容摘要 JMS面向Web的应用与面向桌面的应用相比，有非凡的用户环境要求：同一个消息必须能被若干未知的用户消费，面向Web的JMS应用系统，因此在消息接收方必须有"接收而不确认"的提交机制；本文以CWNF校务系统为实现案例，讨论面向Web的JMS应用系统消息提交

内容摘要

　 JMS面向Web的应用与面向桌面的应用相比，有非凡的用户环境要求：同一个消息必须能被若干未知的用户消费，因此在消息接收方必须有"接收而不确认"的提交机制；本文以CWNF校务系统为实现案例，讨论面向Web的JMS应用系统消息提交原理及采用的要害技术。

　 消息传递是一种在软件组件或应用之间进行分布式通信的松散耦合方法，与各种紧密耦合通信技术（如CORBA、java RMI、COM/DCOM）相比，不同之处在于：①消息系统是一种对等实施，通信双方即消息的发送者和接受者都是该系统中的客户端，彼此不呈C/S关系；②通信双方的工作是异步的；③基于消息格式一致，通信双方只需一个中介来存储并治理消息就可以实现通信，而紧密耦合技术则需要知道远程方法在本地的接口。因自身特点，消息传递技术在企业中和企业间有较广泛的应用需求。

　 JMS（Java Message Service）是J2EE企业平台的Java消息服务，目前主流J2EE产品的JMS都实现了存储功能，JMS客户端通过JMS API创建，彼此间通过目的地（Destination）对象进行通信；可是JMS消息系统多见于桌面应用，而Web应用鲜见，本文以笔者开发的CWNF校务系统为案例，讨论面向Web的JMS应用系统的实现原理及采用的要害技术。

1　面向Web的JMS应用系统实现原理

1.1　JMS应用系统消息传递原理

　 JMS应用系统有4个部分：①JMS提供者（JMS PRovider），是一个逻辑数据存储体，并提供治理工具和控制特性；②JMS客户端，是用Java语言编写的发送或接收消息的组件或应用；③消息，是JMS客户端间被传递的承载信息的对象；④被治理对象，是系统治理员为客户端预置的JMS对象，包括目的地对象和连接工厂对象，其中目的地对象是客户端间的消息中介。这4个部分通过JNDI相关联：治理员通过治理工具把目的地对象和连接工厂对象绑定到一个JNDI API命名空间中，JMS客户端就可以在命名空间中查找这些对象，并通过JMS提供者建立与这些对象的逻辑连接，从而彼此之间实现通信（图1）。JMS支持2种消息传递域：点到点、发布/订阅，与之相对应的消息目的地对象也有2种：队列、主题。

1.2　Web应用的消息提交机制

　  通常，无论是消息发送方还是接收方，桌面应用都不容许消息丢失或重复，JMS消息提交机制是基于这个要求的，它们从不同方面保证该要求的实现：①在接收方控制消息的确认。通过确认保证一个接收者对一个消息只消费一次，在非事务性的会话中，消息确认方式取决于create×××session方法第二个参数的值；在事务性会话中，无论由Bean治理事务还是由Bean容器治理事务，消息确认都由Bean容器自动完成。②在发送方指定消息的提交模式和生存期。提交模式有两种：PERSISTENT(稳定存储)和NON_PERSISTENT(非稳定存储)，稳定存储保证在故障情况下消息不会丢失；生存期决定一个消息在存储中介中的存在寿命，JMS提供者会自动摧毁到期的消息。③创建持久定阅的接收方。在发布/订阅系统中，持久订阅者可以接收到在订阅者关闭阶段消息发送方发布的消息。

　  但是Web应用系统在消息接收方有Web特有的用户环境要求：①若干个用户共用一个JMS客户端组件，因此消息就应向一个消息接收者提交而不需确认，具有容器自动确认功能的Bean是无法实现这一要求的；在一个组件内假如把会话设置成事务性的，而这个组件的容器又不具有事务治理能力，则这个组件就能做到"接收而不确认"，在Web应用系统中只有Servlet组件符合这一要求。②JMS客户端的消息接收者经常关闭，为了接收在关闭期间发送来的消息，消息接收者必定是基于主题的持久定阅者，所以面向Web的JMS应用系统必定采用发布/订阅消息传递域。

2　CWNF校务系统模型

　 CWNF是一个面向Web的JMS校务系统，用于校园发布通知及征求意见等校务工作，通知分为2类：普通通知和征求意见性通知。

　 该系统用户分成3类，用户不同，处理模型也不同，基本情况如下：①发布用户，拥有通知发布权，向主题发布通知；②署名用户，查阅通知，也可发表对征求意见性通知的反馈意见；③匿名用户，只查阅通知。

2.1　数据与数据流模型

　 系统中的数据因此有2类：通知、反馈。接收方接收的数据将形成一个xml文档对象，以便发往Web浏览器显示；基于这样的要求，考察下面2个问题：①系统中各方之间的数据关系，②各方数据的形式。

　  主要的数据关系有3个：①通知发送方与通知接收方的数据关系，②反馈发送方与反馈接收方的数据关系，③通知接收方与反馈接收方的数据关系。（如图2）在发送方，数据（通知或反馈）是一件一件的发送，在接收方，数据（通知或反馈）则是批接收，是对应发送方数据的集合，因此在发送方没有必要把数据直接加工成XML文档对象形式，只要生成能构成XML文档对象的元素对象即可；而通知接收方与反馈接收方的数据关系则是：每一条征求意见性通知都有相关的一个反馈集合。