「jmsjava实现」javaxjms是哪个jar

本篇文章给大家谈谈jmsjava实现，以及javaxjms是哪个jar对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、jms 是 java 消息队列的标准，activemq 是具体实现，还是不太懂
• 2、『什么是JMS（Java消息服务）』面试题目
• 3、jms是什么意思
• 4、java jms为什么引入消息中间件
• 5、什么是JMS消息服务（Java Message Service）?
• 6、JAVA中的JMS是什么意思？它起了什么作用

jms 是 java 消息队列的标准，activemq 是具体实现，还是不太懂

jms 是java规定的系统应用之间的一种数据交换标准；

jdbc 是java规定系统应用与关系型数据库系统之间的一套标准；

activemq 是对jms标准的一种实现；

好比于 mysql 驱动对 jdbc的标准的一种实现；

『什么是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提供支持。

例句：

You have successfully used the JMS protocol for communicating with your SOAP requests.

您已经成功地使用JMS协议和SOAP请求通信了。

扩展资料

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

1、StreamMessage -- Java原始值的数据流

2、MapMessage--一套名称-值对

3、TextMessage--一个字符串对象

4、ObjectMessage--一个序列化的 Java对象

5、BytesMessage--一个未解释字节的数据流

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 Message Service）?

打个比方。你家里人都在家。那你们聊个天什么的，直接说就可以了。

但是如果你父母在家，你在外地，那要聊个天什么的，吼两句就没办法了。这时候就是要借助电话或者互联网这类工具了。这类工具会把你的消息传达给你的父母，再把你父母的消息传递给你。

而JMS就是这么一个功能。负责多方的消息传输。

一般做分布式，都是把多层应用放到多个服务器上去。比如说，前台服务器接受到用户请求。会先去缓存服务器查一下该页面有没有缓存。那这个时候就要跟缓存服务器通信。发出查询是否有缓存的请求。那你就要建一个这样的服务，让前台可查询。查询后，缓存服务器又要响应结果。

如果没有缓存的话，那这个时候又要与业务层打交道，业务层再与数据层请求。这层与层之间，或者服务器与服务器间通讯，都需要有一套的通讯框架。JSM就是做这个了。

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）支持把可选头字段添加到消息。如果您的应用程序需要不使用标准头字段对消息编目和分类，您就可以添加一个属性到消息以实现这个编目和分类。提供 setTypeProperty(...) 和 getTypeProperty(...) 方法以设置和获取各种 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 提供的。

jmsjava实现的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于javaxjms是哪个jar、jmsjava实现的信息别忘了在本站进行查找喔。