JMS总结

这周老师让我们组收集有关JMS的资料然后进行讲演，今天找了一上午，找得头晕，现总结一下：

1. JMS基本概念
JMS(Java Message Service)是访问企业消息系统的标准API,它便于消息系
统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发。

2. JMS基本功能
JMS是用于和面向消息的中间件相互通信的应用程序接口。它既支持点对点(point-to-point)的域，又支持发布/订阅(publish/subscribe)类型的域，并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。JMS还提供了另一种方式来对您的应用与旧的后台系统相集成。
3. WebLogic JMS Server介绍
WebLogic Server8.1符合JAVA规范,并通过Sun Microsystems J2EE 1.3认
证.作为WebLogic的一部分,当然WebLogic JMSServer也完全遵从JMS规范,还支持集群,并可以应用于实际企业系统.下图是WebLogic JMSServer体系结构.图中可以看到WebLogic JMSServer主要组件有: WebLogic JMSservers(用于消息通信),Java客户端,JNDI(用于域名查找), 后备存储(用于持久消息存储,基于文件或者JDBC数据库).

二. WebLogic JMS特性
1. 消息通信模型
JMS 支持两种消息通信模型：点到点（point-to-point）（PTP）模型和发布/订阅（Pub/Sub）模型。除了下列不同之外，这两种消息通信模型非常地相似：
PTP 模型规定了一个消息只能有一个接收者;Pub/Sub 模型允许一个消息可以有多个接收者。
2. 消息组成
消息传递系统的中心就是消息。
一条 Message 分为三个组成部分：
· 头（header）是个标准字段集，客户机和供应商都用它来标识和路由消息。
· 属性（property）支持把可选头字段添加到消息。如果您的应用程序需要不使用标准头字段对消息编目和分类，您就可以添加一个属性到消息以实现这个编目和分类。提供set<Type>Property(...) 和 get<Type>Property(...) 方法以设置和获取各种 Java 类型的属性，包括 Object。JMS 定义了一个供应商选择提供的标准属性集。
· 消息的主体（body）包含要发送给接收应用程序的内容。每个消息接口特定于它所支持的内容类型。
JMS 为不同类型的内容提供了它们各自的消息类型，但是所有消息都派生自 Message 接口。
· StreamMessage：包含 Java 基本数值流，用标准流操作来顺序的填充和读取。
· MapMessage：包含一组名/值对；名称为 string 类型，而值为 Java 的基本类型。
· TextMessage：包含一个 String。
· ObjectMessage：包含一个 Serializable Java 对象；能使用 JDK 的集合类。
· BytesMessage：包含未解释字节流: 编码主体以匹配现存的消息格式。
· XMLMessage: 包含XML内容。扩展TextMessage,XMLMessage 类型的使用，使得消息过滤非常便利。
3. 消息确认模式
非事务性会话中，应用程序创建的会话有5 种确认模式,而在事务性会话中，确认模式被忽略。
五种确认模式说明:
· AUTO_ACKNOWLEDGE：自动确认模式。一旦接收方应用程序的方法调用从处理消息处返回，会话对象就会确认消息的接收。
· CLIENT_ACKNOWLEDGE：客户端确认模式。会话对象依赖于应用程序对被接收的消息调用一个acknowledge()方法。一旦这个方法被调用，会话会确认最后一次确认之后所有接收到的消息。这种模式允许应用程序以一个调用来接收，处理并确认一批消息。注意：在管理控制台中，如果连接工厂的AcknowledgePolicy（确认方针）属性被设置为"Previous"（提前），但是你希望为一个给定的会话确认所有接收到的消息，那么就用最后一条消息来调用acknowledge()方法。
· DUPS_OK_ACKNOWLEDGE：允许副本的确认模式。一旦接收方应用程序的方法调用从处理消息处返回，会话对象就会确认消息的接收；而且允许重复确认。在需要考虑资源使用时，这种模式非常有效。注意：如果你的应用程序无法处理重复的消息的话，你应该避免使用这种模式。如果发送消息的初始化尝试失败，那么重复的消息可以被重新发送。
· NO_ACKNOWLEDGE：不确认模式。不确认收到的消息是需要的。消息发送给一个NO_ACKNOWLEDGE 会话后，它们会被WebLogic 服务器立即删除。在这种模式下，将无法重新获得已接收的消息，而且可能导致下面的结果：1. 消息可能丢失；和（或者）另一种情况：2. 如果发送消息的初始化尝试失败，会出现重复消息被发送的情况。
· MULTICAST_NO_ACKNOWLEDGE：IP组播下的不确认模式，同样无需确认。发送给一个MULTICAST_NO_ACKNOWLEDGE会话的消息， 会共享之前所述的NO_ACKNOWLEDGE 确认模式一样的特征。这种模式支持希望通过IP 组播方式进行消息通信的应用程序，而且无需依赖会话确认提供的服务质量。注意：如果你的应用程序无法处理消息的丢失或者重复，那么你应该避免使用这种模式。如果发送消息的初始化尝试失败的话，重复的消息可能会被再次发送。
注：在上表的5 种确认模式中，AUTO_ACKNOWLEDGE，DUPS_OK_ACKNOWLEDGE和
CLIENT_ACKNOWLEDGE 是JMS 规范定义的，NO_ACKNOWLEDGE 和MULTICAST_NO_ACKNOWLEDGE是WebLogic JMS 提供的。

 

2.1. JMS的体系结构

JMS应用由以下几部分组成：

JMS provider ：是一个消息系统，它实现了JMS 接口并提供管理和控制的功能。

JMS clients ：是用Java语言写的一些程序和组件，它们产生和使用消息。

Messages ：是在JMS clients之间传递的消息的对象。

Administered objects ：是由使用JMS clients 的人生成的预选设置好的JMS 对象。有两种这样的对象：destinations和connection factories。

2.2. Message机制

JMS规范制定了两种Message机制：point-to-point和publish/subscribe。

2.2.1 point-to-point

point-to-point (PTP) 的产品和应用是建立在message queues, senders和receivers概念上的。 每一个message发送到某一个特定的queue, 然后接收客户从queue 里面提取messages。 Queues里保存所有发给接收客户的messages，直到messages被提供了或过期。

应该注意：

1.每一个message只有一个使用者。

2.一个message的sender和receiver没有时间上的依赖关系。无论sendere有没有在运行，Receiver都可提取message。

3.Receiver完成对message处理这后，发出确认。

当你所发出的每一个消息必须由一个使用者成功处理的情况下，使用 PTP messaging机制。

2.2.2 publish/subscribe

在publish/subscribe(pub/sub)产品或应用中, 客户发送messages到一个topic。Publishers和subscribers通常是匿名的并且可以动态发布或订阅。系统负责分发从多个publishers来的同一个topic的messages。当messages 分发到了所有目前的subscribers，Topics就不再保留他们。

Pub/sub messaging有如下的特点：

1.每一个message可以有多个使用者;

2.Publishers和subscribers在时间上有依赖关系。一个订阅了某一个topic的客户，只能使用在它生成订阅之后发布的message, 并且subscriber必须一直保持活动状态。

JMS API允许客户生成持久性的订阅，从而在某种程度上放宽了这种时间上的依赖关系，提高了灵活性处可靠性。

2.2.3 Messaging的使用

Messaging本生是asynchronous的，使message的使用者之间没有时间上的依赖关系。但是，JMS规范给出了更精确的定义，使Message可以以两种方式被使用:

1.Synchronously：subscriber或receiver可以能过调用receive方法显示地从destination上提取message。Receive方法在收到一个 message后结束，或当message 在一定的时间限制内没有收到时超时结束。

2.Asynchronously：客户可以为某一个使用者注册一个message listener。message listener和event listener很相似。当一个message到达了destination, JMS provider通过调用listener的onMessage方法将message传递过去，由onMessage方法负责处理message。

3. JMS API编程模型

一个JMS应用由以下几个模块组成：

3.1. Administered Objects

JMS应用的destinations和connection factories最后是通过管理而不是编程来使用，因为不同的provider使用他们的方法不一样。

JMS 客户应该使用同一的接口得到这些objects，从而使用JMS应用可以运行在不同provider上，而不需要修改或修改很少。通常管理员在JNDI上设置administered objects, 然后JMS clients 在JNDI上look up这些对象。

3.1.1 Connection Factories：

connection factory 是client用来生成与provider的connection的对象。connection factory封装了一套由管理员定义的connection configuration参数。每个connection factory 是一个QueueConnectionFactory 或 TopicConnectionFactory接口的实例。

在JMS 客户程序中, 通常先执行connection factory 的JNDI API lookup。

 

常见Java开源JMS消息中间件及特性简介：

mom4j是一个完全实现JMS1.1规范的消息中间件并且向下兼容JMS1.0与1.02.它提供了自己的消息处理存储使它独立于关系数据与语言,所以它的客户端可以用任何语言开发.

OpenJMS

OpenJMS是一个开源的JavaMessage Service API 1.0.2规范的实现,它包含有以下特性：

　　*. 它既支持点到点(point-to-point)(PTP)模型和发布/订阅(Pub/Sub)模型。

　　*. 支持同步与异步消息发送

　　*. JDBC持久性管理使用数据库表来存储消息

　　*. 可视化管理界面。

　　*. Applet支持。

　　*. 能够与Jakarta Tomcat这样的Servlet容器结合。

　　*. 支持RMI, TCP, HTTP 与SSL协议。

　　*. 客户端验证

　　*. 提供可靠消息传输、事务和消息过滤

　　UberMQ

　　UberMQ完全实现了Java Message Service 规范。UberMQ是因为现有的许多JMS提供商已经违背了分布式计算的核心原则：快速与简单而开发的。

　　Hermes JMS

　　利用它提供的SwingUI可以很好的实现监控JMSproviders。

　　ActiveMQ

　　ActiveMQ是一个开放源码基于Apache2.0 licenced 发布并实现了JMS 1.1。它能够与Geronimo，轻量级容器和任Java应用程序无缝的给合。

　　Somnifugi

　　Somnifugi使得工作在同一个java虚拟机中的线程能实现消息互发。

　　MantaRay

　　MantaRay基于peer-2-peer 技术。它具有以下特性:

　　1.它既支持点对点(point-to-point)的域，又支持发布/订阅(publish/subscribe)类型的域。

　　2.并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。

　　3.消息过滤体制。

　　4.能与WebLogic and WebSphere 给合。

　　5.支持TCP, UDP 与 HTTP传输协。

　　Presumo

　　Presumo也是一个实现Java Message Service API的JMS消息中间件。

　　JORAM

　　JORAM一个类似于openJMS分布在ObjectWeb之下的JMS消息中间件。

　　JMS4Sdivad

　　JMS4Sdivad是一个消息系统.它部分地实现了Java消息服务(JMS) API.

 

 

利用JMS建立消息传递系统：

JMS（Java消息服务）是一个消息交换标准，它允许使用J2EE应用程序组件建立、发送、接收和读取消息。它假设分布式通讯拥有自由（free）的连接、是可靠的（reliable）和异步的（asynchronous）。

　　Exchange（交换）系统

　　消息交换反映了程序组件或应用程序之间的一种交互作用。消息交换系统是一种类似于下的系统：一个相似系统的客户端可以发送和接收任何其它客户端的消息。每个客户端都并入系统的代理中，它提供了建立、发送、接收和读取消息的可能。

　　交换系统使得分布式的交互操作成为可能。组件在目的地（Destination）发送消息，收件人也可以在相同的目的地中得到这个消息。发送者和收件人不一定是互相熟悉的。换句话说，它并没有强迫发送者知道一些收件人的信息，也没有强迫收件人知道某些发送者的信息。发送者和收件人只需要知道消息的格式以及要到达的目的地。在这种情形下，上述的系统不同于与它紧密相连的一些技术，例如远程方法调用（RMI），它只要求开发人员了解RMI中的一些方法。

　　消息传递系统

　　消息传递系统是一种分布式的系统，是基于系统组件之间的异步消息交换。面向消息的中间件（Message-Oriented Middleware，MOM）就是这种产品，消息传递系统是在它的原理上建立的。

　　消息传递系统应用软件不会直接地通讯（这与传统的系统（基于RMI的）形成鲜明的对照），而需要依赖MOM的帮助。如果系统的某个组件希望给另一个组件发送消息，它将把给定的消息发送给MOM，接着MOM把该消息发送给收件人。

　　

　　与传统的基于RMI构建的系统相比，它有以下优点：

　　· 发送消息的应用程序不需要期待回应，可以继续执行。

　　· 没有强迫发送消息的应用程序和特定消息的收件人在某个特定的时刻是激活的。如果消息的收件人不是激活的，MOM保证收件人一旦激活就立即收到该消息。

　　· 系统组件没有直接地彼此相连。它们被分离开了，这就是在运行时刻能把组件从一个主机传输到另一个、却不会中断系统可用性的原因。

　　消息交换模型：点对点模型和发表－预订模型

　　目前有两种“基本的”消息交换模型：点对点模型和发表－预订（pub-sub）模型。点对点模型应用于一个或多个组件（发送者）仅仅给一个组件收件人（接收者）发送消息的情形。这种模型是基于消息队列概念的：发送者把消息发送到队列中，接收者从该队列中读取消息。在点对点模型中，相同的队列上可能存在多个接收者，但是MOM只给其中一个传递消息。给哪一个传递消息依赖于MOM的实现（implementation）。

　　发表－预订模型应用于一个或多个组件（发表者）给一个或多个组件收件人（预订者）发送消息的情形。这种特定的模型是基于消息主题（message topic）概念的：发表者把消息发送到某个主题中，而该特定主题的预订者接收这些消息。

　　发表－预订模型看起来更加“优雅”，但是很多发表－预订模型不能保证消息按照发送的次序传递（它与点对点模型相反，点对点队列实现了FIFO（先进先出）原理）。因此，消息的次序很重要（或者为了同步需要使用消息的头和属性部分）的时候，就应该避免采用发表－预订模型。

　　Java消息服务（JMS）是使用面向消息中间件的一套Java API，它允许你的应用程序建立、发送、接收和读取消息。这组程序集位于J2EE程序包结构树上的javax.jms程序包中。JMS在很多MOM产品中得到了实现，其中iPlanet Message Queue、 IBM MQSeries、ProgressSoftware SonicMQ、BEA WebLogic Server、PrismTechnologies 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消息由三个部分组成：

　　· 消息头

　　· 属性（不是必要的）

　　· 消息体（不是必要的）

　　本文没有解释更多的细节信息，你可以在官方文档中找到具体的细节。

　　什么时候使用EJB2.0

　　请注意下述各项内容：

　　在新的EJB2.0规范中，与JMS的集成是通过建立新的EJB类型——消息驱动Bean（MDB）来实现的。MDB的特性是客户端不会使用远程接口（remoteinterface）与它通讯。其交互操作的唯一途径是通过消息发送。MDB仅仅是消息监听程序，是一个实现了javax.ejb.MessageDrivenBean和javax.jms.MessageListener接口的类，没有任何其它的功能。其中的第一个接口只有两个方法：setMessageDrivenContext()和ejbRemove()。第二个接口只有一个方法：onMessage()。这个规范还需要一个不带参数的ejbCreate()建立方法。客户端不会直接与MDB通讯；它不会建立MDB。容器（container）自身决定什么时候和需要多少个MDB来处理来自特定目的地的消息。MDB的主要缺陷是它只能从一个目的地接收到消息。

javax.jms API：

http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/package-summary.html