什么是jms？jms定定义了哪些不同的消息正文格式

在不同系统之间交换信息的一大障碍是如何在精确交换和格式化数据方面取得一致。Java Message Service（ Java消息服务，简称JMS）通过提供一种与J2EE应用程序或传统系统交互的方法部分的解决了这个问题。

JMS的通用接口集合以异步方式发送或接收消息。异步方式接收消息显然是使用间断网络连接的客户机，诸如移动电话和PDA的最好的选择。另外， JMS采用一种宽松结合方式整合企业系统的方法，其主要的目的就是创建能够使用跨平台数据信息的、可移植的企业级应用程序，而把开发人力解放出来。

Java消息服务支持两种消息模型：Point-to-Point消息 (P2P)和发布订阅消息（Publish Subscribe messaging，简称Pub/Sub）。JMS规范并不要求供应商同时支持这两种消息模型，但开发者应该熟悉这两种消息模型的优势与缺点。

P2P消息模型是在点对点之间传递消息时使用。如果应用程序开发者希望每一条消息都能够被处理，那么应该使用P2P消息模型。与Pub/Sub消息模型不同，P2P消息总是能够被传送到指定的位置。

Pub/Sub模型在一到多的消息广播时使用。如果一定程度的消息传递的不可靠性可以被接受的话，那么应用程序开发者也可以使用Pub/Sub消息模型。换句话说，它适用于所有的消息消费程序并不要求能够收到所有的信息或者消息消费程序并不想接收到任何消息的情况。

JMS通过允许创建持久订阅来简化时间相关性，即使消息预订者未激活也可以接收到消息。此外，使用持久订阅还可通过队列提供灵活性和可靠性，而仍然允许消息被发给许多的接收者。 Topic Subscriber topic Subscriber = topicSession.createDurableSubscriber(topic, subscriptionName)Connection对象表示了到两种消息模型中的任一种的消息系统的连接。服务器端和客户机端对象要求管理创建的JMS连接的状态。连接是由 Connection Factory创建的并且通过JNDI查寻定位。 //取得用于 P2P的 QueueConnectionFactory QueueConnectionFactory = queueConnectionFactory( )Context messaging = new InitialContext( )QueueConnectionFactory = (QueueConnectionFactory) Messaging.lookup(“QueueConnectionFactory”)//取得用于 pub/sub的 TopicConnectionFactory TopicConnectonFactory topicConnectionFactoryContext messaging = new InitialContext()topicConnectionFactory = (TopicConnectionFactory) messaging.lookup(“TopicConnectionFactory”)注意：用于P2P的代码和用于PublishSubscribe的代码非常相似。

如果session被标记为transactional的话，确认消息就通过确认和校正来自动地处理。如果session没有标记为 transactional，你有三个用于消息确认的选项。

· AUTO_ACKNOWLEDGE session将自动地确认收到一则消息。

· CLIENT_ACKNOWLEDGE 客户端程序将确认收到一则消息，调用这则消息的确认方法。 · DUPS_OK_ACKNOWLEDGE 这个选项命令session“懒散的”确认消息传递，可以想到，这将导致消息提供者传递的一些复制消息可能会出错。这种确认的方式只应当用于消息消费程序可以容忍潜在的副本消息存在的情况。 queueSession = queueConnection.createQueueSession(false, session.AUTO_ACKNOWLEDGE)//P2P topicSession = topicConnection.createTopicSession(false, session.AUTO_ACKNOWLEDGE)//Pub-Sub

注意：在本例中，一个session目的从连结中创建，非值指出session是non-transactional的，并且 session将自动地确认收到一则消息。

JMS现在有两种传递消息的方式。标记为NON_PERSISTENT的消息最多投递一次，而标记为PERSISTENT的消息将使用暂存后再转送的机理投递。如果一个JMS服务离线，那么持久性消息不会丢失但是得等到这个服务恢复联机时才会被传递。所以默认的消息传递方式是非持久性的。即使使用非持久性消息可能降低内务和需要的存储器，并且这种传递方式只有当你不需要接收所有的消息时才使用。

虽然 JMS规范并不需要JMS供应商实现消息的优先级路线，但是它需要递送加快的消息优先于普通级别的消息。JMS定义了从0到9的优先级路线级别，0是最低的优先级而9则是最高的。更特殊的是0到4是正常优先级的变化幅度，而5到9是加快的优先级的变化幅度。举例来说： topicPublisher.publish (message, DeliveryMode.PERSISTENT, 8, 10000)//Pub-Sub 或 queueSender.send(message, DeliveryMode.PERSISTENT, 8, 10000)//P2P 这个代码片断，有两种消息模型，映射递送方式是持久的，优先级为加快型，生存周期是10000 (以毫秒度量 )。如果生存周期设置为零，这则消息将永远不会过期。当消息需要时间限制否则将使其无效时，设置生存周期是有用的。

JMS定义了五种不同的消息正文格式，以及调用的消息类型，允许你发送并接收以一些不同形式的数据，提供现有消息格式的一些级别的兼容性。

· StreamMessage — Java原始值的数据流

· MapMessage–一套名称-值对

· TextMessage–一个字符串对象

· ObjectMessage–一个序列化的 Java对象

· BytesMessage–一个未解释字节的数据流

JMS应用程序接口提供用于创建每种类型消息和设置荷载的方法例如，为了在一个队列创建并发送一个TextMessage实例，你可以使用下列语句： TextMessage message = queueSession.createTextMessage()message.setText(textMsg)以异步方式接收消息，需要创建一个消息监听器然后注册一个或多个使用MessageConsumer的JMS MessageListener接口。会话(主题或队列)负责产生某些消息，这些消息被传送到使用onMessage方法的监听者那里。 import javax.jms.*public class ExampleListener implements MessageListener { //把消息强制转化为TextMessage格式 public void onMessage(Message message) { TextMessage textMsg = null// 打开并处理这段消息 } } 当我们创建QueueReceiver和TopicSubscriber时，我们传递消息选择器字符串： //P2P QueueReceiver QueueReceiver receiverreceiver = session.createReceiver(queue, selector)//Pub-Sub TopicSubscriber TopicSubscriber subscribersubscriber = session.createSubscriber(topic, selector)为了启动消息的交付，不论是Pub/Sub还是P2P，都需要调用start方法。 TopicConnection.start( )//pub-sub QueueConnection.start( )//P2P TopicConnection.start ( )// pub-sub QueueConnection.start ( )// P2P

当一条消息被捕捉时，这条消息做为一条必须被强制转化为适当消息类型的普通 Message对象到达。这是一个被用来提取或打开消息内容的getter方法。下列代码片段使用StreamMessage类型。 private void unPackMessage (Message message) { String eNameString positiondouble rateStreamMessage messageMessage = session.createStreamMessage( )//注意下面的代码必须按照我给出的顺序书写 message.writeString(eName)message.writeString(position)message.writeDouble(rate)//实现处理消息的必要的程序逻辑 }

停止消息的传递，无论是Pub/Sub还是P2P，都调用stop方法。 TopicConnection.start( )//pub-sub QueueConnection.start( )//P2P TopicConnection.start ( )// pub-sub QueueConnection.start ( )// P2P 其他的J2EE组件–servlet或EJB–可以当作消息生产者；然而，它们可能只能同步 *** 作，这可能是因为它们的请求-应答的性质决定的。虽然XML目前还不是被支持的消息类型，发送一个XML文件和创建一条文本类型消息以及把XML文件添加到消息的有效负载都一样简单，都是以非专有的方式传送数据。值得注意的是，一些JMS供应厂商已经提供了可用的XML消息类型。但是使用非标准的消息类型可能会出现可移植性问题。 String reportData//reportData内容为XML 文档 TextMessage messagemessage = session.createTextMessage()message.setText (reportData)

消息驱动组件(MDB)是一个当消息到达时被容器调用的异步消息消费程序。和 entity和session EJB不同，MDB没有本地和远程接口并且是匿名的；它们对于客户是不可见的。MDB是JMS系统的一部分，作为消费者实现服务器上的商业逻辑程序。一个客户程序可能通过使用JNDI定位一个与MDB相关联的JMS。 例如： Context initialContext = new InitialContext()Queue reportInfoQueue = (javax.jms.Queue)initialContext.lookup (“java:comp/env/jms/reportInfoQueue”)MDB是由Bean类和相应的XML部署描述符组成。 Bean 类实现MessageDriveBean 接口： import javax.ejb.*import jms.Message.*public interface MessageDriveBean { public void ejbCreate()public void ejbRemove()public void setMessageDrivenContext(MessageDrivenContext ctx)} 消息监听器接口： import javax.jms.*public interface MessageListener { public void onMessage( )}

部署描述符 ＜!DOCTYPE ejb-jar PUBLIC “-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN” “http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd”＞ ＜ejb-jar＞＜enterprise-beans＞ ＜message-driven＞ ＜ejb-name＞MDB＜/ejb-name＞＜ejb-class＞MDB＜/ejb-class＞＜transaction-type＞Container＜/transaction-type＞＜message-driven-destination＞＜jms-destination-type＞javax.jms.Queue＜/jms-destination-type＞＜/message-driven-destination＞ ＜security-identity＞＜run-as-specified-identity＞ ＜role-name＞everyone＜/role-name＞＜/run-as-specified-identity＞ ＜/security-identity＞ ＜/message-driven＞＜/enterprise-beans＞ ＜/ejb-jar＞ 既然我们现在已经有了一些基本的JMS知识，那么我们可以使用JMS做什么呢?任何事情都可以。 例如，分别用于销售、库存、客户服务和账目处理的系统。这些部门之间的系统很可能已经存在了很长时间，这些处理要求把事务移动到系统中去，这并不是一个小的工作。这就是消息服务适用的地点。

    JMS即Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。可以简单的理解为：两个应用程序之间需要进行通信，我们使用一个JMS服务，进行中间的转发，通过JMS 的使用，我们可以解除两个程序之间的耦合。

    点对点模型用于消息生产者和消息消费者之间点到点的通信。消息生产者将消息发送到由某个特定名字标示的消息队列（Queue）中，消息消费者从这个特定队列中获取对应消息。在消息传送给消费者之前它被存储在这个队列中。队列可以是持久的，以保证在消息服务出现故障时仍然能够传递消息。

    在点对点消息传送模型中，应用程序由消息队列（Queue），发送者（Sender），接收者（Receiver）组成。每一个消息发送给一个特殊的消息队列，该队列保存了所有发送给它的消息(除了被接收者消费掉的和过期的消息)。

    在发布/订阅消息模型中，发布者发布一个消息，该消息通过主题（Topic）传递给所有的客户端。在这种模型中，发布者和订阅者彼此不知道对方，是匿名的且可以动态发布和订阅主题（Topic）。主题（Topic）主要用于保存和传递消息，且会一直保存消息直到消息被传递给客户端。

    在发布与订阅消息传送模型中，应用程序由主题（Topic），发布者（Publisher），订阅者（Subscriber）组成。客户端将消息发送到主题。多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

    在JMS中，消息的产生和消息是异步的。对于消费来说，JMS的消息者可以通过两种方式来消费消息。

    JMS API是在javax.jms包中定义的。

    要使用JMS API 需要创建一个提供连接对象的连接工厂。连接对象提供与消息服务器的链接。链接被用来创建会话，会话被用来创建消息，消息通过消息的生产者发送到目标(队列或主题)，然后消息传递到消息消费者。

    整理文章主要为了自己日后复习用，文章中可能会引用到别的博主的文章，如涉及到博主的版权问题，请博主联系我。

就是姐妹们的复数形式。

JMS

开放分类： 程序、计算机、网络用语

JMS（Java Messaging Service）是Java平台上有关面向消息中间件的技术规范，翻译为Java消息服务。JMS支持点对点和发布/订阅两种消息模型。

JMS基本概念

1.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 JMS Server也完全遵从JMS规范,还支持集群,并可以应用于实际企业系统.下图是WebLogic JMS Server体系结构.图中可以看到WebLogic JMS Server主要组件有: WebLogic JMS servers(用于消息通信),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()方法。一旦这个方法被调用，会话会确认最后一次确认之后所有接收到的消息。这种模式允许应用程序以一个调用来接收，处理并确认一批消息。注意：在管理控制台中，如果连接工厂的Acknowledge Policy（确认方针）属性被设置为"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 提供的

---