当前页面: 开发资料首页 → Java 专题 → 利用JMS建立消息传递系统
利用JMS建立消息传递系统
摘要: 在开始之前需要说明，为了理解本文，我们希望读者拥有Java编程的相当坚实的基础
在开始之前需要说明，为了理解本文，我们希望读者拥有Java编程的相当坚实的基础。我们将试图尽可能简单地解释什么是JMS，但是在你能够建立自己的程序并正确地理解它们之前，你需要有一些使用JNDI开发实际应用程序的经验。
JMS（Java消息服务）是一个消息交换标准，它允许使用J2EE应用程序组件建立、发送、接收和读取消息。它假设分布式通讯拥有自由（free）的连接、是可靠的（reliable）和异步的（asynchronous）。
Exchange（交换）系统
消息交换反映了程序组件或应用程序之间的一种交互作用。消息交换系统是一种类似于下的系统：一个相似系统的客户端可以发送和接收任何其它客户端的消息。每个客户端都并入系统的代理中，它提供了建立、发送、接收和读取消息的可能。
交换系统使得分布式的交互操作成为可能。组件在目的地（Destination）发送消息，收件人也可以在相同的目的地中得到这个消息。发送者和收件人不一定是互相熟悉的。换句话说，它并没有强迫发送者知道一些收件人的信息，也没有强迫收件人知道某些发送者的信息。发送者和收件人只需要知道消息的格式以及要到达的目的地。在这种情形下，上述的系统不同于与它紧密相连的一些技术，例如远程方法调用（RMI），它只要求开发人员了解RMI中的一些方法。
消息传递系统
消息传递系统是一种分布式的系统，是基于系统组件之间的异步消息交换。面向消息的中间件（Message-Oriented Middleware，MOM）就是这种产品，消息传递系统是在它的原理上建立的。
消息传递系统应用软件不会直接地通讯（这与传统的系统（基于RMI的）形成鲜明的对照），而需要依赖MOM的帮助。如果系统的某个组件希望给另一个组件发送消息，它将把给定的消息发送给MOM，接着MOM把该消息发送给收件人。
<table width="90%" align=center border=0> <tr> <td> </td></tr></table>
与传统的基于RMI构建的系统相比，它有以下优点：
· 发送消息的应用程序不需要期待回应，可以继续执行。
· 没有强迫发送消息的应用程序和特定消息的收件人在某个特定的时刻是激活的。如果消息的收件人不是激活的，MOM保证收件人一旦激活就立即收到该消息。
· 系统组件没有直接地彼此相连。它们被分离开了，这就是在运行时刻能把组件从一个主机传输到另一个、却不会中断系统可用性的原因。
消息交换模型：点对点模型和发表－预订模型
目前有两种“基本的”消息交换模型：点对点模型和发表－预订（pub-sub）模型。点对点模型应用于一个或多个组件（发送者）仅仅给一个组件收件人（接收者）发送消息的情形。这种模型是基于消息队列概念的：发送者把消息发送到队列中，接收者从该队列中读取消息。在点对点模型中，相同的队列上可能存在多个接收者，但是MOM只给其中一个传递消息。给哪一个传递消息依赖于MOM的实现（implementation）。
发表－预订模型应用于一个或多个组件（发表者）给一个或多个组件收件人（预订者）发送消息的情形。这种特定的模型是基于消息主题（message topic）概念的：发表者把消息发送到某个主题中，而该特定主题的预订者接收这些消息。
发表－预订模型看起来更加“优雅”，但是很多发表－预订模型不能保证消息按照发送的次序传递（它与点对点模型相反，点对点队列实现了FIFO（先进先出）原理）。因此，消息的次序很重要（或者为了同步需要使用消息的头和属性部分）的时候，就应该避免采用发表－预订模型。
Java消息服务（JMS）是使用面向消息中间件的一套Java API，它允许你的应用程序建立、发送、接收和读取消息。这组程序集位于J2EE程序包结构树上的javax.jms程序包中。JMS在很多MOM产品中得到了实现，其中iPlanet Message Queue、 IBM MQSeries、Progress Software SonicMQ、BEA WebLogic Server、Prism Technologies OpenFusion等最有名气，也存在一些免费的实现。
JMS同时支持消息交换的两种“基本的”模型。但是，其说明（specification）并没有要求厂商同时实现两种模型，尽管大多数JMS产品实现了点对点和发表－预订模型。
JMS应用程序
JMS应用程序的主要部分是：
· 产生连接的部分和目的地
· 连接
· 对话
· 产生消息的部分
· 使用消息的部分
· 消息
产生连接的部分（ConnectionFactory）是负责建立JMS连接的对象。每个ConnectionFactory都是QueueConnectionFactory或TopicConnectionFactory的一个副本（copy）。MOM管理器建立特定的对象，并把它与JNDI树关联起来，这样JMS客户端就能够使用标准的JNDI查找表得到ConnectionFactory的入口。在点对点的模型中，它使用了javax.jms.QueueConnectionFactory；在发表－预订模型中，它使用的是javax.jms.TopicConnectionFactory。
目的地（Destination）——它是队列或主题，这依赖于我们使用了下面哪种模型：javax.jms.Queue或javax.jms.Topic。
连接（Connection）——它可能是客户端和服务应用之间的开放的TCP/IP。它可以被用于建立一个或少量的对话。在你的应用程序能够接收消息前，你必须调用start()方法。为了暂停发送消息，你需要调用stop()。
对话（Session）——在JMS连接的帮助下建立的对象，被客户端用作发送和接收消息。
产生消息的部分（MessageProducer）——对话建立的对象，被用于在目的地中发送消息。
使用消息的部分（MessageConsumer）——对话建立的对象，用于接收消息。为了同步接收消息，需要使用receive()方法。对于异步的情形，使用MessageListener和唯一的方法——onMessage()。在该方法中，在定义的消息到达后应该执行一定的操作。
消息（Message）——消息本身。JMS消息由三个部分组成：
· 消息头
· 属性（不是必要的）
· 消息体（不是必要的）
本文没有解释更多的细节信息，你可以在官方文档中找到具体的细节。
什么时候使用EJB 2.0
请注意下述各项内容：
在新的EJB 2.0规范中，与JMS的集成是通过建立新的EJB类型——消息驱动Bean（MDB）来实现的。MDB的特性是客户端不会使用远程接口（remote interface）与它通讯。其交互操作的唯一途径是通过消息发送。MDB仅仅是消息监听程序，是一个实现了javax.ejb.MessageDrivenBean和javax.jms.MessageListener接口的类，没有任何其它的功能。其中的第一个接口只有两个方法：setMessageDrivenContext() 和ejbRemove()。第二个接口只有一个方法：onMessage()。这个规范还需要一个不带参数的ejbCreate()建立方法。客户端不会直接与MDB通讯；它不会建立MDB。容器（container）自身决定什么时候和需要多少个MDB来处理� 醋蕴囟康牡氐南ⅰDB的主要缺陷是它只能从一个目的地接收到消息。
zmbbs=1;
JMS（Java消息服务）是一个消息交换标准，它允许使用J2EE应用程序组件建立、发送、接收和读取消息。它假设分布式通讯拥有自由（free）的连接、是可靠的（reliable）和异步的（asynchronous）。
Exchange（交换）系统
消息交换反映了程序组件或应用程序之间的一种交互作用。消息交换系统是一种类似于下的系统：一个相似系统的客户端可以发送和接收任何其它客户端的消息。每个客户端都并入系统的代理中，它提供了建立、发送、接收和读取消息的可能。
交换系统使得分布式的交互操作成为可能。组件在目的地（Destination）发送消息，收件人也可以在相同的目的地中得到这个消息。发送者和收件人不一定是互相熟悉的。换句话说，它并没有强迫发送者知道一些收件人的信息，也没有强迫收件人知道某些发送者的信息。发送者和收件人只需要知道消息的格式以及要到达的目的地。在这种情形下，上述的系统不同于与它紧密相连的一些技术，例如远程方法调用（RMI），它只要求开发人员了解RMI中的一些方法。
消息传递系统
消息传递系统是一种分布式的系统，是基于系统组件之间的异步消息交换。面向消息的中间件（Message-Oriented Middleware，MOM）就是这种产品，消息传递系统是在它的原理上建立的。
消息传递系统应用软件不会直接地通讯（这与传统的系统（基于RMI的）形成鲜明的对照），而需要依赖MOM的帮助。如果系统的某个组件希望给另一个组件发送消息，它将把给定的消息发送给MOM，接着MOM把该消息发送给收件人。
<table width="90%" align=center border=0> <tr> <td> </td></tr></table>
与传统的基于RMI构建的系统相比，它有以下优点：
· 发送消息的应用程序不需要期待回应，可以继续执行。
· 没有强迫发送消息的应用程序和特定消息的收件人在某个特定的时刻是激活的。如果消息的收件人不是激活的，MOM保证收件人一旦激活就立即收到该消息。
· 系统组件没有直接地彼此相连。它们被分离开了，这就是在运行时刻能把组件从一个主机传输到另一个、却不会中断系统可用性的原因。
消息交换模型：点对点模型和发表－预订模型
目前有两种“基本的”消息交换模型：点对点模型和发表－预订（pub-sub）模型。点对点模型应用于一个或多个组件（发送者）仅仅给一个组件收件人（接收者）发送消息的情形。这种模型是基于消息队列概念的：发送者把消息发送到队列中，接收者从该队列中读取消息。在点对点模型中，相同的队列上可能存在多个接收者，但是MOM只给其中一个传递消息。给哪一个传递消息依赖于MOM的实现（implementation）。
发表－预订模型应用于一个或多个组件（发表者）给一个或多个组件收件人（预订者）发送消息的情形。这种特定的模型是基于消息主题（message topic）概念的：发表者把消息发送到某个主题中，而该特定主题的预订者接收这些消息。
发表－预订模型看起来更加“优雅”，但是很多发表－预订模型不能保证消息按照发送的次序传递（它与点对点模型相反，点对点队列实现了FIFO（先进先出）原理）。因此，消息的次序很重要（或者为了同步需要使用消息的头和属性部分）的时候，就应该避免采用发表－预订模型。
Java消息服务（JMS）是使用面向消息中间件的一套Java API，它允许你的应用程序建立、发送、接收和读取消息。这组程序集位于J2EE程序包结构树上的javax.jms程序包中。JMS在很多MOM产品中得到了实现，其中iPlanet Message Queue、 IBM MQSeries、Progress Software SonicMQ、BEA WebLogic Server、Prism Technologies OpenFusion等最有名气，也存在一些免费的实现。
JMS同时支持消息交换的两种“基本的”模型。但是，其说明（specification）并没有要求厂商同时实现两种模型，尽管大多数JMS产品实现了点对点和发表－预订模型。
JMS应用程序
JMS应用程序的主要部分是：
· 产生连接的部分和目的地
· 连接
· 对话
· 产生消息的部分
· 使用消息的部分
· 消息
产生连接的部分（ConnectionFactory）是负责建立JMS连接的对象。每个ConnectionFactory都是QueueConnectionFactory或TopicConnectionFactory的一个副本（copy）。MOM管理器建立特定的对象，并把它与JNDI树关联起来，这样JMS客户端就能够使用标准的JNDI查找表得到ConnectionFactory的入口。在点对点的模型中，它使用了javax.jms.QueueConnectionFactory；在发表－预订模型中，它使用的是javax.jms.TopicConnectionFactory。
目的地（Destination）——它是队列或主题，这依赖于我们使用了下面哪种模型：javax.jms.Queue或javax.jms.Topic。
连接（Connection）——它可能是客户端和服务应用之间的开放的TCP/IP。它可以被用于建立一个或少量的对话。在你的应用程序能够接收消息前，你必须调用start()方法。为了暂停发送消息，你需要调用stop()。
对话（Session）——在JMS连接的帮助下建立的对象，被客户端用作发送和接收消息。
产生消息的部分（MessageProducer）——对话建立的对象，被用于在目的地中发送消息。
使用消息的部分（MessageConsumer）——对话建立的对象，用于接收消息。为了同步接收消息，需要使用receive()方法。对于异步的情形，使用MessageListener和唯一的方法——onMessage()。在该方法中，在定义的消息到达后应该执行一定的操作。
消息（Message）——消息本身。JMS消息由三个部分组成：
· 消息头
· 属性（不是必要的）
· 消息体（不是必要的）
本文没有解释更多的细节信息，你可以在官方文档中找到具体的细节。
什么时候使用EJB 2.0
请注意下述各项内容：
在新的EJB 2.0规范中，与JMS的集成是通过建立新的EJB类型——消息驱动Bean（MDB）来实现的。MDB的特性是客户端不会使用远程接口（remote interface）与它通讯。其交互操作的唯一途径是通过消息发送。MDB仅仅是消息监听程序，是一个实现了javax.ejb.MessageDrivenBean和javax.jms.MessageListener接口的类，没有任何其它的功能。其中的第一个接口只有两个方法：setMessageDrivenContext() 和ejbRemove()。第二个接口只有一个方法：onMessage()。这个规范还需要一个不带参数的ejbCreate()建立方法。客户端不会直接与MDB通讯；它不会建立MDB。容器（container）自身决定什么时候和需要多少个MDB来处理� 醋蕴囟康牡氐南ⅰDB的主要缺陷是它只能从一个目的地接收到消息。
zmbbs=1;
↑返回目录
前一篇: Java更新XML的四种常用方法简介
后一篇: Java Applet基础入门之数据类型