jmsjava
㈠ java消息服务的JMS消息模型
除了消息头中定义好的标准属性外，JMS 提供一种机制增加新属性到消息头中，这种新属性包含以下几种： 1. 应用需要用到的属性；2. 消息头中原有的一些可选属性；3. JMS Provider 需要用到的属性。标准的 JMS 消息头包含以下属性：
JMSDestination：消息发送的目的地；
JMSDeliveryMode：传递模式， 有两种模式：PERSISTENT 和NON_PERSISTENT，PERSISTENT 表示该消息一定要被送到目的地，否则会导致应用错误。NON_PERSISTENT 表示偶然丢失该消息是被允许的，这两种模式使开发者可以在消息传递的可靠性和吞吐量之间找到平衡点；
JMSMessageID：唯一识别每个消息的标识，由JMS Provider 产生；
JMSTimestamp：一个消息被提交给JMS Provider 到消息被发出的时间；
JMSCorrelationID：用来连接到另外一个消息，典型的应用是在回复消息中连接到原消息；
JMSReplyTo：提供本消息回复消息的目的地址；
JMSRedelivered：如果一个客户端收到一个设置了JMSRedelivered 属性的消息，则表示可能该客户端曾经在早些时候收到过该消息，但并没有签收(acknowledged)；
JMSType：消息类型的识别符；
JMSExpiration：消息过期时间，等于 QueueSender 的 send 方法中的 timeToLive 值或 TopicPublisher 的publish 方法中的 timeToLive 值加上发送时刻的 GMT 时间值。如果 timeToLive 值等于零，则 JMSExpiration 被设为零，表示该消息永不过期。如果发送后，在消息过期时间之后消息还没有被发送到目的地，则该消息被清除。
JMSPriority：消息优先级，从 0-9 十个级别，0-4 是普通消息，5-9 是加急消息。JMS 不要求 JMS Provider 严格按照这十个优先级发送消息，但必须保证加急消息要先于普通消息到达。 JMS API 定义了 5 种消息体格式，也叫消息类型，你可以使用不同形式发送接收数据并可以兼容现有的消息格式，下面描述这 5 种类型：
TextMessage：java.lang.String 对象，如 xml 文件内容；
MapMessage：名/值对的集合，名是 String 对象，值类型可以是 Java 任何基本类型；
BytesMessage：字节流；
StreamMessage：Java 中的输入输出流；
ObjectMessage：Java 中的可序列化对象；
Message：没有消息体，只有消息头和属性。 Java 消息服务支持两种消息模型：Point-to-Point 消息(P2P)和发布订阅消息 (Publish Subscribe messaging，简称Pub/Sub)。JMS 规范并不要求供应商同时支持这两种消息模型，但开发者应该熟悉这两种消息模型的优势与缺点。P2P 消息模型是在点对点之间传递消息时使用。如果应用程序开发者希望每一条消息都能够被处理，那么应该使用 P2P 消息模型。与 Pub/Sub 消息模型不同，P2P 消息总是能够被传送到指定的位置。
Pub/Sub 模型在一到多的消息广播时使用。如果一定程度的消息传递的不可靠性可以被接受的话，那么应用程序开发者也可以使用 Pub/Sub 消息模型。换句话说，它适用于所有的消息消费程序并不要求能够收到所有的信息或者消息消费程序并不想接收到任何消息的情况。
㈡ 1. 解释java的关键字的作用JVM, JNDI, JMS, JTA, JDK,JAF,RMI
JVM：Java
Virtual
Machine（Java虚拟机）http://ke..com/view/160708.htm
JNDI：Java命名系统接口http://ke..com/view/209575.htm
JMS：Java消息服务http://ke..com/view/157103.htm
JTA：Java事务API
http://ke..com/view/512788.htm
JDK：Java
Development
Kit
http://ke..com/view/25214.htm
JAF：JavaBeans
Activation
Framework
http://ke..com/view/1280380.htm
RMI：Remote
Method
Invocation，远程方法调用http://ke..com/view/99017.htm
㈢ JAVA中的JMS是什么意思它起了什么作用
. 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 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 提供的。
㈣ 什么是JMS消息服务（Java Message Service）
JMS(Java Message Service)是访问企业消息系统的标准API,它便于消息系统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发。
1.JMS应用由以下几部分组成：
JMS provider ：是一个消息系统，它实现了JMS 接口并提供管理和控制的功能。
JMS clients ：是用Java语言写的一些程序和组件，它们产生和使用消息。
Messages ：是在JMS clients之间传递的消息的对象。
Administered objects ：是由使用JMS clients 的人生成的预选设置好的JMS 对象。有两种这样的对象：destinations和connection factories。
2.JMS基本功能
JMS是用于和面向消息的中间件相互通信的应用程序接口。它既支持点对点(point-to-point)的域，又支持发布/订阅 (publish/subscribe)类型的域，并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支 持。JMS还提供了另一种方式来对您的应用与旧的后台系统相集成。
㈤ java jms为什么引入消息中间件
mom4j
mom4j是一个完全实现JMS1.1规范的消息中间件并且向下兼容JMS1.0与1.02.它提供了自己的消息处理存储使它独立于关系数据与语言,所以它的客户端可以用任何语言开发.
OpenJMS
OpenJMS是一个开源的Java Message 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
利用它提供的Swing UI可以很好的实现监控JMS providers。
ActiveMQ
ActiveMQ是一个开放源码基于Apache 2.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消息中间件。
JMS4Spread
JMS4Spread是一个消息系统.它部分地实现了Java消息服务(JMS) API.
-------------------------------------------------------------------------------------------
开源JMS简单比较
我考虑在公司的项目中采用JMS来降低服务器之间的耦合性，但为了降低成本，商业软件是不考虑的，于是只能在开源的并且对商业友好的JMS服务器中选择一个了。选择条件主要基于：
支持JMS 1.1规范
持久化，能满足商业应用所需的稳定性
满足项目的性能需求
最好本身提供JNDI服务
最好支持JMX
最好本身提供一个友好的管理工具
最好提供一份完整的文档
准备进行选择的JMS服务器有：OpenJMS、UberMQ、ActiveMQ、MantaRay、JORAM
OpenJMS：老牌的JMS服务器了，也是我最早知道的开源JMS服务器，不过只支持JMS 1.02，已经很长时间没有更新了，因此不予考虑。
UberMQ：采用NIO的JMS服务器，以前我学习NIO的时候看过它的代码，写的蛮不错的，也支持JMS 1.1。由于采用了NIO，所以具有很高的弹性，在满足项目的性能需求上没有什么问题；本身也提供JNDI服务，但是遗憾的是我bind其他类型的数据时会出错；提供admin和viewer两个管理工具，但是在管理工具里不能创建ConnectionFactory和Destination并绑定到JNDI；文档不太完整；最头痛的对于持久化支持不好，如果关闭JMS服务器再开启，所有保存在JMS中的信息就全部丢失了，这点没有办法满足商业应用所需的稳定性。
ActiveMQ：最近比较活跃的一个JMS服务器，主页上的介绍说在协议配置上可以选择支持NIO，但是我仔细看它所支持的协议，却并没有提到如何配置，并且在实际的测试中也并没有发现其有采用NIO的迹象，多连接一个Client端，服务器端就增多了一个线程。满足JMS 1.1，有多种方法进行持久化；本身不提供JNDI，也没有对JMX的支持，本身不带管理工具，采用Hermes进行管理（这个我会在以后提到），文档也相对较少。
MantaRay：也是比较活跃的一个JMS服务器，采用的是P2P模型，但是我不喜欢这种模型，对于JMS服务来说，很大的一个特点就是客户端可以不用永远在线，比如在更新某一个客户端时需要暂停服务，等服务再度开启时，这段时间内所接收到的信息并不会丢失，保存在服务器上，所以我并不能看到P2P模型应用在JMS服务器上的优势，况且采用JMS服务就是为了解除耦合，速度并不是唯一需要考量的事情。出于我不喜欢其所采用模型，并且在运行其所带的示例时都出现了示例时都出现了问题，两个客户端互发互收，但是彼此之间都收不到消息，于是不予考虑。
JORAM：支持JMS 1.1，可以持久化到文件，本身提供JNDI服务和提供对JMX的支持，自带的管理工具可以添加ConnectionFactory和Destination并绑定到JNDI，这点对实现动态管理来说非常有用；文档非常完备，100多页的PDF，包含了各种配置和调整信息。其稳定性考虑的尤其好，不仅考虑到JMS服务器的集群，甚至连JNDI的集群也考虑进去（尽管暂时对我而言还用不上），这点对于商业应用而言应该会有加分。
ActiveMQ是Apache License，JORAM是LGPL，这两者对于商业应用都是友好的；UberMQ和MantaRay采用是Dual License，UberMQ的Dual License是只要你不分发，就可以允许使用；而MantaRay是商业使用需要应用一个商业的License。
比较上面的这些JMS服务器，最终我是选择了JORAM，其满足了我的绝大部分要求，唯一比较遗憾的是其采用传统的IO模型，每连接一个Client端会在服务器端增加两个线程，这点稍微影响了服务器的弹性。不过考虑到我们的项目应用，这点暂时可以不用考虑，实在压力过大了，最多到时候采用JMS集群呗：）
开源JMS再比较
四月份时我曾经比较了那时活跃度比较高的一些开源JMS——《开源JMS简单比较》，时隔四个月，重新回顾这些项目，发现与四个月以前的比较有一些出入，在这里再进行一些比较：）
比较的项目没有变化，OpenJMS、UberMQ、ActiveMQ、MantaRay、JORAM，这段时间内没有出现什么JMS新秀，JBoss计划在今年第四季度发布JBoss Messaging，但只要还是捆绑发行，我对其就没什么兴趣。
在上次的比较中，OpenJMS已经有比较长的一段时间没有更新了，但最近的四个月似乎又活跃了起来，其预备发行的0.7.7版计划支持JMS 1.1（这个来的太晚了些），其主页上的Changelog表明了接下来的这个版本有着较大的变化。这对那些以前将OpenJMS应用在项目中的人来说是一个不错的消息，但对正在选择JMS的人而言，OpenJMS的这些改进来的还是稍稍晚了些。
UberMQ这段时间没有更新，我对它的评价与以前一样，没有任何变化。
MantaRay在其主页上更新了一系列的Flash Demos，通过这些Demo，我更坚定了我的看法——MantaRay并不适合用于企业的JMS服务。
P2P这个词虽然热，但是不是什么地方都需要P2P的，在我看来JMS就是用于解除各个应用之间的耦合，速度是个关键指标，但比起这个关键指标更重要的是它存在的意义。我更倾向于采用MantaRay在Flash中所反对的那种模型，通过中心服务器进行转发，可以存放离线消息以及解除耦合。更何况，企业应用中很少有类似MantaRay演示DEMO中出现的那种网络拓扑图，并不是任何两个节点之间都是互联互通的。当然，如果MantaRay能够做一些改进，先尝试采用点对点模型，如果点对点失败，这时将消息发送到中心服务器上（但这一切必须对用户透明），我会比较赞成，既具有传统优势，又能提高消息发送接收速度。
至于上篇文章中提到的运行其自带的示例出现了问题，这次在Flash演示中终于找到了答案。看来MantaRay真应该提高其示例程序的易用性，这么复杂的操作，要是不看Flash演示，还真难想到该这样操作：（
ActiveMQ是让我感到惊讶的一个项目，上次对它的评价似乎有失偏颇。 ActiveMQ支持多种网络拓扑模型，既可以采用传统JMS的Client-Server模型，也可以采用MantaRay的P2P模型，还可以仅仅支持同一JVM内的JMS应用。持久化机制一如既往的优秀，默认采用Apache Derby数据库持久化，也可以配置为各种主流数据库来持久。目前也提供了一简单的JNDI实现，对于JMS应用而言，这已经够用了。
但是其缺点也同样明显，本身不提供管理工具；示例代码非常少；虽然主页上的文档看上去比较全面，但是一来缺乏一种有效的组织方式（文档凌乱，用户很难由浅入深进行了解，提高了门槛），二来文档整体的专业性太强（不了解ActiveMQ？看文档去吧，可是文档是写给了解ActiveMQ的用户看的……），对于普通用户而言，门槛有点高。
而且感觉ActiveMQ有点不安于JMS的本份，开始做一些周边应用了，看其主页就可以看出来，多了很多比较流行的词汇。说不上这是优点还是缺点，但就我的角度而言，我更希望其专注于做好它的JMS。
JORAM在这段期间推出了4.3.x的版本，也是我们在应用中所采用的版本，我的评价和上次相比没有什么大的变化。主页上说其速度有了提高，但我们应用中JMS数据量相对较少，没有感觉出来。稍微遗憾的是在我们试用的过程中，从4.2.3升级到4.3，老版本的持久化消息都无法在新版本上识别出来，只能全部清空。在兼容性上，看来JORAM还得多下功夫。总而言之，我们在应用中采用JORAM，感觉就是波澜不惊，没碰到什么大问题，也没有什么惊喜。
㈥ jms 是 java 消息队列的标准，activemq 是具体实现，还是不太懂
jms 是java规定的系统应用之间的一种数据交换标准；
jdbc 是java规定系统应用与关系型数据库系统之间的一套标准；
activemq 是对jms标准的一种实现；
好比于 mysql 驱动对 jdbc的标准的一种实现；
㈦ Java消息服务的JMS接口描述
JMS 支持两种消息类型 PTP 和 Pub/Sub，分别称作：PTP Domain 和 Pub/Sub Domain，这两种接口都继承统一的 JMS Parent 接口，JMS 主要接口如下所示：
JMS Parent PTPDomain Pub/Sub Domain
ConnectionFactory QueueConnectionFactory TopicConnectionFactory
Connection QueueConnection TopicConnection
Destination Queue Topic
Session QueueSession TopicSession
MessageProcer QueueSender TopicPublisher
MessageConsumer QueueReceiver,QueueBrowser TopicSubscriber
以下是对这些接口的简单描述：
ConnectionFactory：连接工厂，JMS 用它创建连接；
Connection：JMS 客户端到 JMS Provider 的连接；
Destination：消息的目的地；
Session：一个发送或接收消息的线程；
MessageProcer：由 Session 对象创建的用来发送消息的对象；
MessageConsumer：由 Session 对象创建的用来接收消息的对象。
㈧ java jms qm中的一些简称
你好，我也一直在用jms做东西，我给你系统地解释一下吧
MDP：是message-driven bean的缩写，也就是一个消息驱动的bean
QU：是Queue Usual，普通队列的意思
Mbf：是Master Business Functions的缩写，就是一个主业务函数
亲，有任何问题可以继续追问，请记得及时采纳哦！
㈨ ‘什么是JMS（Java消息服务）’面试题目
JMS(Java Message Service)是访问消息系统的标准API,它便于消息系统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口简化应用的开发。
JMS应用由以下几部分组成：
JMS provider ：是一个消息系统，它实现了JMS 接口并提供管理和控制的功能。
JMS clients ：是用Java语言写的一些程序和组件，它们产生和使用消息。
Messages ：是在JMS clients之间传递的消息的对象。
Administered objects ：是由使用JMS clients 的人生成的预选设置好的JMS 对象。有两种这样的对象：destinations和connection factories。
2.JMS基本功能
JMS是用于和面向消息的中间件相互通信的应用程序接口。它既支持点对点(point-to-point)的域，又支持发布/订阅 (publish/subscribe)类型的域，并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支 持。JMS还提供了另一种方式来对您的应用与旧的后台系统相集成。
㈩ jms是什么意思
Java Message Service的简称。
读音：英 [ˈdʒɑːvə ˈmesɪdʒ ˈsɜːvɪs] 美 [ˈdʒɑvə ˈmesɪdʒ ˈsɜːrvɪs]
释义：消息服务，使用Java消息服务。
语法：JMS即Java消息服务（Java Message Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。
例句：
sts.
您已经成功地使用JMS协议和SOAP请求通信了。
(10)jmsjava扩展阅读
JMS定义了五种不同的消息正文格式，以及调用的消息类型，允许你发送并接收以一些不同形式的数据，提供现有消息格式的一些级别的兼容性。
1、StreamMessage -- Java原始值的数据流
2、MapMessage--一套名称-值对
3、TextMessage--一个字符串对象
4、ObjectMessage--一个序列化的 Java对象
5、BytesMessage--一个未解释字节的数据流