JMS

发表回复

JMS（Java平台上的专业技术规范）编辑

jms即Java消息服务（Java Message Service）应用程序接口是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。Java消息服务是一个与具体平台无关的API，绝大多数MOM提供商都对JMS提供支持。jms同时也可以指Journal of Marketing Science，《营销科学学报》的简称。
JMS是一种与厂商无关的 API，用来访问消息收发系统消息。它类似于JDBC(Java Database Connectivity)：这里，JDBC 是可以用来访问许多不同关系数据库的 API，而 JMS 则提供同样与厂商无关的访问方法，以访问消息收发服务。许多厂商都支持 JMS，包括 IBM 的 MQSeries、BEA的 Weblogic JMS service和 Progress 的 SonicMQ，这只是几个例子。 JMS 使您能够通过消息收发服务（有时称为消息中介程序或路由器）从一个 JMS 客户机向另一个 JMS客户机发送消息。消息是 JMS 中的一种类型对象，由两部分组成：报头和消息主体。报头由路由信息以及有关该消息的元数据组成。消息主体则携带着应用程序的数据或有效负载。根据有效负载的类型来划分，可以将消息分为几种类型，它们分别携带：简单文本(TextMessage)、可序列化的对象 (ObjectMessage)、属性集合 (MapMessage)、字节流 (BytesMessage)、原始值流 (StreamMessage)，还有无有效负载的消息 (Message)。

1专业技术规范编辑

JMS（Java Messaging Service）是Java平台上有关面向消息中间件(MOM)的技术规范，它便于消息系统中的Java应用程序进行消息交换,并且通过提供标准的产生、发送、接收消息的接口简化企业应用的开发，翻译为Java消息服务。

2历史编辑

Java消息服务是一个在 Java标准化组织（JCP）内开发的标准（代号JSR 914）。2001年6月25日，Java消息服务发布JMS 1.0.2b，2002年3月18日Java消息服务发布 1.1，统一了消息域。

3体系架构编辑

JMS由以下元素组成。
JMS提供者
连接面向消息中间件的，JMS接口的一个实现。提供者可以是Java平台的JMS实现，也可以是非Java平台的面向消息中间件的适配器。
JMS客户
生产或消费基于消息的Java的应用程序或对象。
JMS生产者
创建并发送消息的JMS客户。
JMS消费者
接收消息的JMS客户。
JMS消息
包括可以在JMS客户之间传递的数据的对象
JMS队列
一个容纳那些被发送的等待阅读的消息的区域。队列暗示，这些消息将按照顺序发送。一旦一个消息被阅读，该消息将被从队列中移走。
JMS主题
一种支持发送消息给多个订阅者的机制。

4对象模型编辑

JMS对象模型包含如下几个要素：[1] 
1）连接工厂。连接工厂（ConnectionFactory）是由管理员创建，并绑定到JNDI树中。客户端使用JNDI查找连接工厂，然后利用连接工厂创建一个JMS连接。
2）JMS连接。JMS连接（Connection）表示JMS客户端和服务器端之间的一个活动的连接，是由客户端通过调用连接工厂的方法建立的。
3）JMS会话。JMS会话（Session）表示JMS客户与JMS服务器之间的会话状态。JMS会话建立在JMS连接上，表示客户与服务器之间的一个会话线程。
4）JMS目的。JMS目的（Destination），又称为消息队列，是实际的消息源。
5）JMS生产者和消费者。生产者（Message Producer）和消费者（Message Consumer）对象由Session对象创建，用于发送和接收消息。
6）JMS消息通常有两种类型：
① 点对点（Point-to-Point）。在点对点的消息系统中，消息分发给一个单独的使用者。点对点消息往往与队列（javax.jms.Queue）相关联。
② 发布/订阅（Publish/Subscribe）。发布/订阅消息系统支持一个事件驱动模型，消息生产者和消费者都参与消息的传递。生产者发布事件，而使用者订阅感兴趣的事件，并使用事件。该类型消息一般与特定的主题（javax.jms.Topic）关联。

5模型编辑

Java消息服务应用程序结构支持两种模型：
点对点或队列模型
发布者/订阅者模型
在点对点或队列模型下，一个生产者向一个特定的队列发布消息，一个消费者从该队列中读取消息。这里，生产者知道消费者的队列，并直接将消息发送到消费者的队列。这种模式被概括为：
只有一个消费者将获得消息
生产者不需要在接收者消费该消息期间处于运行状态，接收者也同样不需要在消息发送时处于运行状态。
每一个成功处理的消息都由接收者签收
发布者/订阅者模型支持向一个特定的消息主题发布消息。0或多个订阅者可能对接收来自特定消息主题的消息感兴趣。在这种模型下，发布者和订阅者彼此不知道对方。这种模式好比是匿名公告板。这种模式被概括为：
多个消费者可以获得消息
在发布者和订阅者之间存在时间依赖性。发布者需要建立一个订阅（subscription），以便客户能够订阅。订阅者必须保持持续的活动状态以接收消息，除非订阅者建立了持久的订阅。在那种情况下，在订阅者未连接时发布的消息将在订阅者重新连接时重新发布。
使用Java语言，JMS提供了将应用与提供数据的传输层相分离的方式。同一组Java类可以通过JNDI中关于提供者的信息，连接不同的JMS提供者。这一组类首先使用一个连接工厂以连接到队列或主题，然后发送或发布消息。在接收端，客户接收或订阅这些消息。

6传递方式编辑

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--一个未解释字节的数据流

7应用程序编辑

ConnectionFactory 接口（连接工厂）
用户用来创建到JMS提供者的连接的被管对象。JMS客户通过可移植的接口访问连接，这样当下层的实现改变时，代码不需要进行修改。管理员在JNDI名字空间中配置连接工厂，这样，JMS客户才能够查找到它们。根据消息类型的不同，用户将使用队列连接工厂，或者主题连接工厂。
Connection 接口（连接）
连接代表了应用程序和消息服务器之间的通信链路。在获得了连接工厂后，就可以创建一个与JMS提供者的连接。根据不同的连接类型，连接允许用户创建会话，以发送和接收队列和主题到目标。
Destination 接口（目标）
目标是一个包装了消息目标标识符的被管对象，消息目标是指消息发布和接收的地点，或者是队列，或者是主题。JMS管理员创建这些对象，然后用户通过JNDI发现它们。和连接工厂一样，管理员可以创建两种类型的目标，点对点模型的队列，以及发布者/订阅者模型的主题。
Session 接口（会话）
表示一个单线程的上下文，用于发送和接收消息。由于会话是单线程的，所以消息是连续的，就是说消息是按照发送的顺序一个一个接收的。会话的好处是它支持事务。如果用户选择了事务支持，会话上下文将保存一组消息，直到事务被提交才发送这些消息。在提交事务之前，用户可以使用回滚操作取消这些消息。一个会话允许用户创建消息生产者来发送消息，创建消息消费者来接收消息。
MessageConsumer 接口（消息消费者）
由会话创建的对象，用于接收发送到目标的消息。消费者可以同步地（阻塞模式），或（非阻塞）接收队列和主题类型的消息。
MessageProducer 接口（消息生产者）
由会话创建的对象，用于发送消息到目标。用户可以创建某个目标的发送者，也可以创建一个通用的发送者，在发送消息时指定目标。
Message 接口（消息）
是在消费者和生产者之间传送的对象，也就是说从一个应用程序传送到另一个应用程序。一个消息有三个主要部分：
消息头（必须）：包含用于识别和为消息寻找路由的操作设置。
一组消息属性（可选）：包含额外的属性，支持其他提供者和用户的兼容。可以创建定制的字段和过滤器（消息选择器）。
一个消息体（可选）：允许用户创建五种类型的消息（文本消息，映射消息，字节消息，流消息和对象消息）。
消息接口非常灵活，并提供了许多方式来定制消息的内容。

8提供者编辑

JMS流程图

要使用Java消息服务，你必须要有一个JMS提供者，管理会话和队列。既有开源的提供者也有专有的提供者。
开源的提供者包括：
Apache ActiveMQ
JBoss 社区所研发的 HornetQ
Joram
Coridan的MantaRay
The OpenJMS Group的OpenJMS
专有的提供者包括：
BEA的BEA WebLogic Server JMS
TIBCO Software的EMS
GigaSpaces Technologies的GigaSpaces
Softwired 2006的iBus
IONA Technologies的IONA JMS
SeeBeyond的IQManager（2005年8月被Sun Microsystems并购）
webMethods的JMS+ -
my-channels的Nirvana
Sonic Software的SonicMQ
SwiftMQ的SwiftMQ

IBM的WebSphere MQ


Apache ActiveMQ：


企业消息软件从80年代起就存在，它不只是一种应用间消息传递风格，也是一种集成风格。因此，消息传递可以满足应用间的通知和互相操作。但是开源的解决方案是到最近10年才出现的。Apache ActiveMQ就是其中一种。它使应用间能以异步，松耦合方式交流。本章将向您介绍ActiveMQ。

    ActiveMQ是Apache软件基金下的一个开源软件，它遵循JMS1.1规范（Java Message Service），是消息驱动中间件软件（MOM）。它为企业消息传递提供高可用，出色性能，可扩展，稳定和安全保障。ActiveMQ使用Apache许可协议。因此，任何人都可以使用和修改它而不必反馈任何改变。这对于商业上将ActiveMQ用在重要用途的人尤为关键。MOM的工作是在分布式的各应用之间调度事件和消息，使之到达指定的接收者（第二章将阐述该内容）。所以高可用，高性能，高可扩展性尤为关键。

    ActiveMQ的目标是在尽可能多的平台和语言上提供一个标准的，消息驱动的应用集成。ActiveMQ实现JMS规范并在此之上提供大量额外的特性。这些额外的特性也会在这本书中详细阐述。

    你最初的几步对于你成功将ActiveMQ应用在你的工作中尤为重要。对于新手，ActiveMQ看起来令人恐惧；对于有经验的人，则会比较容易理解。这一章将带你熟悉ActiveMQ。你将了解到ActiveMQ的特性集，也将了解到为什么和在哪里部署ActiveMQ。之后，你将有足够的知识去安装和开始使用ActiveMQ。

 

1.1 ActiveMQ特性

    ActiveMQ提供大量的特性，这些特性是用大量人力进行开发的。本书的各章将专注这些特性的各个部分进行讲解。下面是一个高层次的特性列表。

·         遵循JMS规范 ----理解ActiveMQ的起始点是明白ActiveMQ的各种特性是JMS1.1规范的实现。本章后面将讨论JMS规范提供的好处和保证。它们包括同步和异步消息传递，一次和只有一次的消息传递，对于预订者的持久消息等等。依附于JMS规范意味着，不论JMS消息提供者是谁，同样的基本特性都是有效的。

·         连接----ActiveMQ提供各种连接选择，包括HTTP，HTTPS，IP多点传送，SSL，STOMP，TCP，UDP，XMPP等。大量的连接协议支持使之具有更好的灵活性。很多现有的系统使用一种特定协议并且不能改变，所以一个支持多种协议的消息平台降低了使用的门槛。虽然连接很重要，但是和其他容器集成也同样重要。第四章将讲解ActiveMQ的传输连接器（transport connectors）和网络连接器（network connectors）。

·         可插拔的持久性和安全----ActiveMQ提供多种持久性方案可供选择，也可以完全按自己需求定制验证和授权。例如，ActiveMQ通过KahaDB提供自己的超快速消息持久方案（ultra-fast message persistence），但也支持标准的JDBC方案。ActiveMQ可以通过配置文件提供简单的验证和授权，也提供标准的JAAS登陆模块。这两部分内容将在5，6章论述。

·         用Java建立消息驱动应用----ActiveMQ最常用在Java应用中，用于发送和接收消息。这部分的内容涉及JMS规范API，将会在第7章讨论。

·         与应用服务器集成----ActiveMQ与java应用服务器集成是很常见的。第8章提供了一些集成例子，包括Apache Tomcat，Jetty，Apache Geronimo和JBoss。

·         客户端APIs----ActiveMQ对多种语言提供客户端API，除了Java之外还有C/C++，.NET，Perl，PHP，Python，Ruby等。这使得ActiveMQ能用在Java之外的其它语言中。很多其它语言都可以通过ActiveMQ提供的客户端API使用ActiveMQ的全部特性。当然，ActiveMQ代理器（broker）仍然是运行在java虚拟机上，但是客户端能够使用其它的被支持的语言。客户端和ActiveMQ的连接将在第9章讨论。

·         代理器集群（Broker clustering）----为了利于扩展，多个ActiveMQ broker能够联合工作。这个方式就是network of brokers并且能支持多种拓扑结构。这部分将在第10章讨论。

·         高级代理器特性和客户端选项----ActiveMQ为代理器和客户端连接提供很多高级的特性。ActiveMQ也可以通过代理器的XML配置文件支持Apache Camel。这部分内容将在11和12章介绍。

·         简单的管理----ActiveMQ是为开发者设计的。它并不需要专门的管理工具，因为它提供各种易用且强大的管理特性。有很多方法去监控ActiveMQ的各个方面，可以通过JMX使用JConsole或ActiveMQ web console；可以运行ActiveMQ消息报告；可以用命令行脚本；可以通过日志。这些都会在第14章介绍。

    上面只是简单介绍了ActiveMQ的特性。就像你看到的，这些特性将在全书的各个章节讨论。为了演示，第3章将带来一些简单例子。但在看这些例子和特性之前，你一定想知道为什么要使用ActiveMQ。

1.2使用ActiveMQ：为什么，何时

    时间回到2003年，一群开源开发者集合在一起形成了Apache Geronimo。之后，他们发现当前没有好用的使用BSD-style许可协议的消息代理器。Geronimo是由于java EE兼容性需要一个JMS实现。所以一些开发者开始讨论其可能性。拥有丰富MOMs经验甚至自己创建过一些MOMs的这些开发者开始创建下一个伟大的开源消息代理。ActiveMQ这么快开始是因为当时市场上大多数的MOMs是商业，闭源而且购买和支持昂贵。市场上的MOMs已经广泛地被使用，但是一些商业行为是买不起如此昂贵的软件。这使得创建一个开源MOMs的需求更加大。很明显，有一个市场急需一个开源的使用Apache License的MOM。最终就导致了Apache ActiveMQ的诞生。

    ActiveMQ遵循JMS规范，是为分布式应用远程交流而创建的。为了理解这目的，最好就是去看一些分布式应用的设计和是交互。

 

1.2.1松耦合与ActiveMQ

    ActiveMQ提供松耦合的应用架构。松耦合一般是为了减轻经典RPC（Remote Procedure Calls）调用的紧耦合架构而被引入的。该松耦合以异步形式存在，任何一个应用对ActiveMQ的调用不依赖于任何其它应用，没有任何依赖或者时序要求。应用依赖于ActiveMQ的能力保证消息传递。因此，我们把应用发送消息的形式称之为触发和忘记（fire-and-forget）--应用发送消息到ActiveMQ之后并不关心消息如何或者什么时候被传递。同样的消息的接收者也不关心消息从哪里或者如何到来。在不同的环境中这样做的好处是允许客户端使用不同的语言编写甚至使用不同的线路协议。ActiveMQ作为中间人存在，允许不同环境的集成和异步交互。更多内容将在下一节论述。

    当我们考虑分布式应用设计时，耦合是很重要的。耦合是指两个或多个应用间的相互依赖。考虑耦合的一个简单办法是思考其中某个应用改变所产生的影响，即其它应用所需要作出的改变。是否一个应用的变化会强制其它应用跟着改变？如果答案是肯定的，则这些应用是紧耦合的。如果一个应用的变化无需强制其它应用跟着改变，则这些应用是松耦合的。这说明了紧耦合系统比松耦合系统更难维护。也就是说，松耦合系统更能适应未知的变化。

    在第二章我们将讨论COM,CORBA,DCE和EJB等使用RPC的技术，它们是紧耦合的。使用RPC，当一个应用调用另一个应用，调用者将被阻塞知道被调用者返回结果。图1.1描述了这个过程。 

Apache ActiveMQ介绍 - czg_e - czg_e的博客

调用方（Application one）将被阻塞直到被调用方（Application two）返回控制权。很多系统使用RPC并且成功了。但是对于这样一个紧耦合系统确实有很多缺点：最显著的缺点是，即使很小的一个改变都要较高的维护代价;正确的时机也很重要，当请求从应用1发到应用2时，两个系统都必须正常工作，同样的，响应从应用2发送到应用1时，两个系统也必须正常工作。这样的时序要求有点麻烦，使得系统稳定性降低。现在我们把这个紧耦合系统和图1.2的系统进行比较。Apache ActiveMQ介绍 - czg_e - czg_e的博客

 在图1.2中，应用1发送消息到MOM只是一个单方行为。可能一段时间后，应用2从MOM接收消息，这也是一个单方行为。任何一方都不需要知道另一方的存在，它们之间也没有任何时序要求。所以在分布式系统设计时，松耦合系统比紧耦合系统有巨大的优势。如图所示，这就是ActiveMQ存在的地方。

    考虑现在其中的一个应用必须搬到一个新的地方。这可能在新硬件引入或应用需要移动时发生。如果是一个紧耦合系统，这样的迁移会很困难，因为系统的其它部分都必须停止工作等待迁移完成。如果是松耦合系统，系统的各个部分能够自由迁移而不影响其它部分。考虑这样一个场景，应用A和B各有很多个实例，其中各个实例分布在不同的机器上。ActiveMQ安装在另外的机器上。在这种情况下，任何一个应用实例都可以自由移动而不影响其它应用。事实上，多个ActiveMQ实例也可以通过network of brokers配置联合使用。这就允许ActiveMQ实例自由迁移而不影响应用A或应用B。采用这种价构，系统的任何一部分在任何时间都可以停机进行维护而不影响整个系统。更多的介绍将放在第10章。

   总之，ActiveMQ提供一个令人难以置信的灵活性允许松耦合思想变成现实。对于某些情况不能使用异步方式实现，ActiveMQ也提供消息的请求/回复模式支持。那么什么时候使用ActiveMQ可以获得如上所述的好处呢？

 

1.2.2何时使用ActiveMQ

    有很多情况ActiveMQ和异步消息能对一个系统的架构产生有意义的作用。下面列举一些场景。

·         不同语言应用集成----ActiveMQ使用java编写，并且提供一个java客户端API。但ActiveMQ也为C/C++，.NET,Perl,PHP,Python,Ruby等提供客户端。当你考虑在不同平台不同语言下的各个应用进行集成时，这将是一个巨大的优势。不同语言的客户端API使各种不同的语言能够通过ActiveMQ发送和接收消息。对于ActiveMQ提供的多语言兼容，还有一个好处是相对于RPC调用，它能帮助系统各应用间的解耦。

·         RPC的替代者----应用广泛的使用RPC模式的同步调用。想一下，现在大量使用RPC调用的客户端服务器模式的应用，它们包括ATMs，大多数web应用，信用卡系统，销售点（point-of-sale）系统等。尽管它们大多数是成功的，但是转换到异步消息模式能够在保证正确响应的情况下带来一些好处。使用同步请求的系统在规模上有较大的限制，因为请求会被阻塞，从而导致整个系统变慢。如果使用异步消息替代，可以很容易增加额外的消息接收者，使得消息能被并发消耗，从而加快请求处理。当然，必须你系统应用间是解耦的。

·         应用间解耦----就是上面讨论过的，紧耦合系统能带来很多问题，特别是在应用是分布式的情况下。松耦合系统，也就是依赖性小的系统，可以更好地适应未知变化。不只是系统某部分的改变不会影响整个系统，而且部件间的交互也更简单。相比使用同步的系统（调用者必须等待被调用者返回信息），异步系统（调用方发送消息后就不管，即fire-and-forget）能够给我们带来事件驱动架构（event-driven architecture EDA）.

·         作为事件驱动架构的骨架----解耦，异步架构的系统允许通过代理器自己配置更多的客户端，内存等（即vertical scalability）来扩大系统，而不是增加更多的代理器（即horizontal scalability）。考虑如亚马逊这样繁忙的电子商务系统。当用户购买物品，事实上系统需要很多步骤去处理，包括下单，创建发票，付款，执行订单，运输等。但是用户下单后，会立即返回“谢谢你下单”的界面。不只是没有延迟，而且用户还会受到一封邮件表明订单已经收到。在亚马逊下单的例子就是一个多步处理的例子。每一步都由单独的服务去处理。当用户下单是，有一个同步的体积表单动作，但整个处理流程并不通过浏览器同步处理。相反地，订单马上被接受和反馈。而剩下的步骤就通过异步处理。如果在处理过程中出错，用户会通过邮件收到通知。这样的异步处理能提供高负载和高可用性。

·         提高系统扩展性。很多使用事件驱动设计的系统是为了获得高可扩展性，例如电子商务，政府，制造业，线上游戏等。通过异步消息分开商业处理步骤给各个应用，能够带来很多可能性。考虑设计一个应用来完成一项特殊的任务。这就是面向服务的架构（service-oriented architecture SOA）。每一个服务完成一个功能并且只有一个功能。应用就通过服务组合起来，服务间使用异步消息和最终一致性。这样的设计便可以引入一个复杂事件处理概念（complex event processing CEP）。使用CEP，部件间的交互可以被记录追踪。在异步消息系统中，可以很容易在部件间增加一层处理。