JMS的基础认识

JMS，应用程序通过虚拟通道来交换消息，这些虚拟通道称之为目的地(队列或主题)，可以实现接收消息的应用程序和发送消息的应用程序就能够实现去耦

他们可以在自己认为合适的时候发送和接收消息。

之前应对异构系统的集成问题方面，已经有很多方法，较早期的一些解决方案，多通过FTP或其他文件传输来传输信息，包括使用将一个磁盘或磁带从一台机器拷贝

到另一台机器上的经典“人力网络”方法，使用数据库在两个异构系统或应用程序之间来共享信息，这是另一种至今仍在应用的常见方法，远程调用

或者简称RPC，也是在不同系统之间共享数据和功能的另一种方法，这些解决方案各自都有优缺点，只有消息传送机制提供的去耦解决方案，能够真正实现跨应用

程序或子系统共享数据和功能，Web服务已经作为异构系统集成的另一种可能的解决方法脱颖而出，不过，Web服务在可靠性方面的欠缺，使得消息传送机制成为一种更佳的集成

选择，使用消息传送机制，许多开源消息传送系统和商业消息传送系统使用了一种集成消息桥，该桥能够将使用JMS的一条消息转换为通用的内部消息格式，来实现

java和其他语言和平台之间的无缝连接。这些消息传送系统的例子有ActiveMQ(开源系统)，IBM WebSphere MQ(商业系统)，这两种消息传送系统都支持JMS，

消息传送优点：

1，缓解系统瓶颈：只要你的某个进程跟不上对他访问请求的速度，那么就会产生系统和应用程序的瓶颈问题，经典例子：在一个拙劣优化的数据库中，应用程序和进程一直等待

，直到数据库连接可用或数据库锁被释放为止，在系统的某些地方，系统将会阻塞，响应会越来越慢。

2，提高可伸缩缩性：大多数企业服务总线允许使用基于HTTP的通信，基于消息传送的系统则仍然继续保持了在大多数生产企业系统当中的标准地位

，企业消息传送的一个关键概念就是：异步。

3，集中式体系结构：使用集中式体系结构的企业消息传送系统，依赖于一台消息服务器(消息服务器又称为消息路由器(message router) 或代理)，消息服务器可以

实现一个发送客户端和其他接收客户端之间的去耦，客户端仅仅会看到消息传送服务器，不会看到其他客户端，这将允许在不会影响系统整合的情况下添加或删除客户端

消息传送模型：JMS支持两类消息，点对点模型和发布/订阅消息传送模型经常分别缩写为P2P和Pub/Sub。发布/订阅模型设计用于一对多(one-to-many)消息广播，而

点对点模型设计用于一对一(one-to-one)消息传送

从JMS的视角来看，消息传送客户端称为JMS客户端(JMS client)，而消息传送系统则称为JMS提供者(JMS provider)，一个JMS应用程序是由多个JMS客户端和一个JMS

提供者组成的业务系统。生产消息的JMS客户端称为消息生产者，接收消息的JMS客户端则称为消息消费者，一个JMS客户端可以既是消息生产者，又是消息消费者

当使用消费者(consumer)或生产者(producer)时，我们分别是指消费或生产消息的一个JMS客户端

点对点模型既支持异步"即发即弃"消息传送方式，又支持同步请求/应答消息传送方式，发送者可能会向一个队列发送一个订单并等待响应，响应中包含一个交易确认码，

这样一来，消息发送者就会知道消息接收者将要处理交易订单，另一个例子就是一个生成长时间运行报告的异步请求，发送者发出报告请求，而当该报告准备就绪时，

就会给发送者发送一条通知消息，在这种情况下，发送者就会知道消息接收者将要处理该消息并创建报告。点对点模型支持负载均衡，它允许多个接收者侦听同一队列

，并以此来分配负载，JMS提供者负责管理队列，确保每条消息被组内下一个可用的接收者消费一次，而且仅仅一次，JMS规范没有规定在多个接收者中间分发消息的规则，

尽管某些JMS厂商已经选择实现此规则来提升负载均衡能力，点对点模型还具有其他优点，比如说队列浏览器允许客户端在消费其消息之前查看队列内容---在发布/订阅模型中

，并没有这种浏览器的概念。

发布/订阅模型，消息会发布到一个名为主题(topic)的虚拟通道中，生产者称为发布者(publisher)，而消息消费者则称为订阅者(subscriber)，可以由多个订阅者接收，有时候，

也称这项技术为广播(broadcasting)消息，每个订阅者都会接收到每条消息的一个副本，总的来说，发布/订阅消息传送模型基本上是一个基于推送(push)的模型

其中消息自动的向消费者广播，他们无须请求或轮询主题来获得新消息，在发布/订阅消息传送模型内部，有多种不同类型的订阅者。非持久订阅者是临时订阅类型，

它们只是在主动侦听主题时才接收消息，而另一方面，持久订阅者将接收到发布的每条消息的一个副本，即便在发布消息，它们处于"离线"状态时也是如此，另外还有动态

持久订阅者和受管的持久订阅者等类型。

发送和接收JMS消息有关的JMS API接口主要有7个：connectoryFactory, Destination, Connection, Session, Message, MessageProducer,MessageConsumer

在这些接口中，ConnectionFactory和Destination必须使用JNDI(遵照JMS规范要求)从提供者处获得，其他接口则可以通过工厂方法在不同的API接口中创建，例如：一旦

有了一个ConnectionFactory，就可以创建一个Connection，一旦有了Connection，就可以创建一个Session，而一旦有了一个Session，就可以创建一个Message，

MessageProducer和MessageConsumer,这7个主要的JMS公共API接口之间的关系：Session对象保存着用于消息传送的事务性工作单元(transactional unit)，而不是

Connection对象，这和JDBC不同，JDBC中是Connection对象保存事务性工作单元，这意味着在使用JMS时，一个应用程序通常只会有一个Connection对象，但是它可以

有一个Session对象池，另外，还有和异常处理，消息优先级及消息持久性有关的其他接口。

点对点 API ：用户向一个队列发送和从一个队列接收消息的接口: QueueConnectionFactory，Queue，QueueConnection，QueueSession，Message，QueueSender，

QueueReceiver，与在JMS公共API中一样，QueueConnectionFactory和Queue对象必须通过JNDI从JMS提供者获得(按照JMS规范的要求)，队列连接工厂和队列都是通过

JNDI从JMS提供者获得，请注意：大多数接口名称仅仅是在公共API接口名称之前添加Queue一词而已，不同之处在于，这里是称为Queue的Destination接口，而

MessageProducer和MessageConsumer接口则分别称为QueueSender和QueueReceive。

发布/订阅 API：发布/订阅消息传送模型内部使用的接口如下：TopicConnectionFactory，Topic，TopicConnection，TopicSession，Message，TopicPublisher，

TopicSubscriber，除了TopicPublisher和TopicSubscriber不同以外，发布/订阅中的接口和P2P域中的那些接口基本类似，发布/订阅模型使用主题，发布者和订阅者

而P2P模型使用的是队列，发送者，接收者。

面向服务体系架构(SOA)定义了从对应的企业服务实现中抽象出来的业务服务，SOA已经促生了一种称为企业总线(ESB)的新类型中间件，大多数ESB是作为

消息代理实现的，由此，消息传送层内部的组件会用于执行某种智能路由选择，或者用于在传送消息之前进行消息转换，这些早期的消息代理，已经发展成为

成熟的商业ESB产品和开源ESB产品，它们在核心之处使用了消息传送机制，尽管某些ESB产品能够支持传统的非JMS型HTTP传送，但是，大多数企业级

产品的实现仍然采用消息传送作为通信协议，在需要将业务服务从底层实现中完全抽象出来的SOA内部构建抽象层时，消息传送是一种极好的手段。

异构平台集成：消息传送机制在这些异构平台相互通信之中起到关键作用，尽管Java这样的平台可以使用JMS API，而其他平台，比如.NET或C++却都无法使用。

许多商业消息传送系统厂商和开源消息传送系统厂商都会支持JMS API和一个本机API，这些提供者一般都有一个内置的消息传送桥，允许将一条JMS消息转换为

内部消息，例如像.NET，可能会需要一个外部消息传送桥，将一条JMS消息转换为MSMQ消息(这取决于你使用的消息提供者)，例如：ActiveMQ就提供了一个消息

传送桥，用于将MSMQ消息转换为JMS格式。

企业应用集成：大多数组织都同时拥有遗留应用系统和新的应用系统，这些系统都是独立实现的，无法实现互操作，各个组织都会有将这些应用系统集成起来的

强烈需求，以便他们能够在大规模企业运行中共享信息并实现协作，这些应用系统的集成称为企业应用集成(EAI),虽然EAI提供了解决方案，但是,企业消息

传送系统仍然是大多数解决方案的主流，企业消息传送系统允许应用系统(由异构产品，技术与组件等组成)和事件进行通信并交换数据，同时还保持物理上的独立。

数据和事件可以通过主题或队列以信息的形式进行交换，它们提供了可以实现各个参与应用系统去耦的一个抽象。例如：因特网系统使用JMS向一个主题传送

有关新订单的业务数据，而一个ERP网关应用程序，它通过本机API访问一个SAP应用程序，能够订阅该订单主题，当新订单广播到该主题时，网关就会

接收这个订单，并将他们纳入SAP应用程序的处理之中。

企业到企业，因特网，XML和现代消息传送系统已经从根本上改变了在如今称为企业到企业(B2B)的系统中，如何进行数据交换和交互，使用消息传送系统

是现代B2B解决方案的主流趋势，因为它允许各个组织相互协作，而无须将它们的业务系统紧密集成起来，此外，它还降低了接入门槛，根据和企业相结合

的队列和主题的不同，它们既可以加入到B2B之中，也可以自由退出。

地理分散：比如远程仓库中的存货系统需要和位于公司总部的集中式内部ERP系统进行通信，由各个子公司本地管理的敏感雇员数据需要和总公司实现同步等

JMS消息传送系统能够确保地理上分散的业务数据交换的安全性和可靠性。

信息广播：举例，在广播股票报价时绝对地保证信息传送，这可能并不是最重要的，然而，在交易者通过购买订单对报价做出响应的情况下，以保证方式返回响应

是至关重要的，此时需要综合利用消息传送机制的可靠性，因为发布/订阅模型分发速度很快但是不可靠，而使用P2P模型从交易者处购买订单则是非常可靠地，

JMS和企业消息传送为发布/订阅和P2P这两种模型都提供了不同程度的可靠性。

构建动态系统：例如需要处理来源不同的采购订单，比如一个来自因特网的系统，而另一个来自遗留的EDI系统，则需要将遗留采购订单系统加入混合系统

之中即可。

RPC和异步消息传送：

1.紧密耦合的RPC，在调用一个远程过程时，调用者将被阻塞，直到该过程完成并将控制权返回调用者，从开发者的角度看，这种同步模型使得该系统就好像

运行在一个进程当中，这些工作会依次完成，同时确保以预定顺序完成，RPC同步的本质特性，将客户端(进行调用的软件)和服务器(为该调用服务的软件)

两者紧密耦合在一起，因为客户端已被阻塞，所以它无法继续进行工作，直到服务器做出响应为止。但是在system-to-system的处理过程当中，它的同步，紧密耦合等本质

却是一个严重的缺陷，当该系统的一部分中断运行时，一切都得停止。当你向一个订单输入系统添加订单时，它要对其他系统依次进行同步调用，这会导致订单

输入系统发生阻塞，并一直等待，直到每个系统都处理完该订单时为止，而此时消息传送机制为此提供了另一种选择方案。

2.企业消息传送，规定应用程序之间的通信应该采用异步方式，将各个部分连接在一起的代码会假定这是一个单向消息，客户端不需要立即从另一个应用程序那里

得到响应，换句话说，也就是没有出现阻塞现象，一旦一条消息被发出，消息传送客户端就能够转向其他任务，它不必等待对这条消息的响应，这就是

RPC和异步消息发送之间的主要区别，而且，它对于理解消息传送系统的优点来说至关重要。

每个子系统不存在和其他系统的耦合，它们通过消息传送服务器进行通信，因此，某个子系统出现故障，并不会妨碍其他子系统的运行，

在网络系统中出现局部故障，这是一个不可避免的事实，其中的一个系统，可能会在其连续运行期间的某个时刻，发生不可预测的故障，或者需要停机。

这样现象可能会由于内部系统与合作系统地理上的分散而被进一步放大，考虑到这个，JMS提供了保证传送方式，他可以确保即便发生了局部故障，预定消费者最终

也会接收到这条消息。保证传送使用的一种"保存并转发"的机制，意味着，如果预定消费者当前不可用，底层消息服务器就会将输入的消息写入到一个持久存储器

之中，随后，当该接收应用程序变为可用时，"保存并转发"机制会把预定消费者在不可用时错过的所有消息传送给它们。

底层的"保存并转发"机制保证了消息的传送，JMS不仅仅是另外一种事件服务，它的设计涵盖了范围极广的企业应用程序，包括EAI，B2B和推送模型等，

通过异步处理,"保存并转发"及"保证传送"机制，他为保持业务应用程序连续运行并实现不间断服务提供了很高的可用性，他通过发布/订阅功能和点对点功能

提供了集成灵活性，通过位置透明和管理控制，它提供了一种健壮的，基于服务的体系架构。

JNDI需要提供JMS提供者的JNDI连接信息，你需要设置连接到JMS服务所需要的初始上下文工厂类，提供者URL，用户名和密码，ConnectionFactory和Destination(主题和队

列)，InitialContext会调用jndi.properties文件中配置的JMS服务器等内容。

TopConnection表示和消息服务器的一个连接，从TopicConnectionFactory中创建的每个TopicConnection就是和该服务器的唯一连接，一个JMS客户端一般从同一个连接工厂

创建一个连接(因为多个连接的开销较大，每个连接都需要一个网络套接字,I/O流和内存等)，一般认为同一个连接中创建多个session对象，效率更高，因为会话共享了对同一

连接的访问。TopConnection是Connection接口的一个扩展接口，它定义了几种通用方法，包括start(开始JMS连接，允许传送消息),stop(暂时阻塞了到达的消息流，直到再次

调用start方法时为止),close(关闭连接消息服务器的TopConnection)方法：关闭TopConnection将关闭和该连接有关的所有对象，包括

TopicSession，TopicPublisher，TopicSubscriber等，TopicSession对象是用于创建Message，TopicPublisher和TopicSubscriber对象的工厂，一个客户端可以创建多个

TopicSession对象，对发布者，订阅者及其相关事务提供粒度更细的控制，createTopicSession()方法中的boolean参数用来表示Session对象是不是事务性的，一个事务性

Session自动管理一个事务内部的输出和输入消息，参数AUTO_ACKNOWLEDGE意味着消息将在客户端接收之后自动确认。jndi.lookup(topicName)查找一个JMS主题。

TopicPublisher用于将消息传送给一个消息服务器上的特定主题，TopicSubscriber从特定的主题接收消息，MessageListener对象的OnMessage()方法接收一条消息

subscriber.setMessageListener(this)使用本类的onMessage()方法去接收，一条消息分为3部分：消息头，属性和有效负载，消息头由用于标示消息，声明消息属性及提供

路由信息的特殊字段组成，消息的属性区包含了和该消息有关的附加元数据，这些元数据由开发者进行设置，某些时候由JMS提供者进行设置。

会话和线程：程序中分别为发布者和订阅者设置了两个单独的会话：pubSession和subSession，其原因在于JMS强制实行的线程限制，一个会话不能同时在一个以上的线程中

运行，测试中的onMessage()处理器是异步调用的，所以当主线程在writeMessage()方法中发布一条消息时，就可以调用onMessage()方法，如果发布者和订阅者都是由同一

个会话创建的，那么，这两个线程就能够同时在这些方法上运行，实际上，它们是能够在同一个TopicSession上并发运行的，不过，这种情况被禁止了。