jms 技术（转）

企业消息传递101

企业消息传递框架被设计用于使得一个或多个应用能够克服各种障碍进行通信。常见的屏障包括：两个系统同时运行（同步通信）的需求，多个应用获取同一条消息（多重传输）的需求，大多数系统都彼此异构，以及网络故障等。

M许多企业的体系结构依赖于面向消息的中间件系统（MOM）来为不同类型的系统提供消息通道。MOM为应用提供了一种公共的、可靠的方式，使这些应用能够轻松地创建、交换和处理消息，而无需考虑消息传递客户机的实现细节。消息被发送到服务器目的地和域 （domain），而不是发送到物理地址。消息传递客户机只需简单地声明对某个特定的域和目的地感兴趣，提供适当的安全性令牌（security token）以获得访问该域的权限，然后通过那个目的地与消息传递服务器进行交互。

从概念上来讲，这与现实生活中真实邮件的传递方式没什么不同。消息的发送方只负责使用正确的包装，提供正确的地址，并附上适当的邮资。 邮局（这里是一个MOM系统）处理 与消息的安全可靠的传递相关的所有问题，而不 管出现在他们面前的任何障碍（机器故障，天气恶劣，等等）。

在一个MOM系统中，客户机之间的耦合性比较弱，这允许它们不必真正地全天“在线”便能维持服务的最佳质量。如果能够去掉应用一直处于可用状态这一需求，那么维护和伸缩性将变得更加易于管理。可以在一天中的任何时候将应用离线，更新应用，或者作为例行的维护工作刷新应用，而不必担心会影响服务的质量。

Java 消息服务

MOM 服务器允许不同类型的系统交换消息，但是每个MOM供应商都有其特有的处理消息的API。这种标准化的缺乏对于Java技术开发范例来说是不可接受的。为了充分利用已有的MOM基础设施，同时又不失标准化，J2EE平台提供了JMS。

Java 标准化
为了提供平台无关的和供应商无关的解决方案，所有Java技术都可以分成两个部分：

一份（或一套）定义该项技术的 规范说明书，指出了开发者和实现该技术的工具供应商的目标和责任。

一套中立接口，作为应用开发者与工具供应商之间的契约。
不管您使用的是何种Java技术，您首先要编写使用了技术规范中提供的接口的应用组件，然后在运行时提供某一特定供应商对这些接口的实现。在J2EE中，企业消息传递的规范和API是JMS。



JMS 定义了在Java企业系统中传递消息的规则，并且声明了一些方便应用组件和消息传递系统（通常是MOM）之间的消息交换的接口。JMS客户机向MOM服务器上的目的地开放连接，然后在那个目的地上发送和接收消息。JMS卸下了 保证传送（guaranteed delivery）、消息通知（message notification）、消息耐久性（message durability）以及消息传递系统中所有底层网络和路由问题的负担。JMS和MOM能够很好地协同工作，因为它们都划清了消息传递客户机和服务器之间的责任界限。

消息传递的类型

JMS 支持两种基本的消息传递机制。第一种机制是点到点的消息传递（point-to-point messaging），在这种机制下，消息由一个发布者（发送方）发送，由订阅者（接收方）接收。另一种机制是发布-订阅式的消息传递（publish- subscribe messaging），在这种机制下，消息由一个或多个发布者发送，由一个或多个订阅者接收。尽管这两种机制是JMS的实际基础，很多人还是按照三种消息传递模型来看待这项技术：

一对一的消息传递（One-to-one messaging ）是一种点到点的模型。消息由一个JMS客户机（发布者）发送到服务器上的一个目的地，即一个队列（queue）。而另一个JMS客户机（订阅者）则可以访问这个队列，并从该服务器获取这条消息。在队列中可以存放多条消息，但每次只能获取一条消息。

一对多的消息传递（One-to-many messaging）是一种发布-订阅模型。这里仍然是由一个JMS客户机将一条消息发布到服务器上的一个目的地上，但是这次这个目的地叫做一个主题（topic）。这里关键的不同在于放在一个主题中的消息包括了一个参数，这个参数定义了该消息的耐久性（它能够在服务器上等待订阅者多长时间）。该消息将一直维持在主题中，直到这个主题的所有订阅者都取走了该消息的一个副本，或者该消息的耐久性时间已到期，不管发生的是上述中的哪种情况，该消息都将被从这个主题中删除。

多对多的消息传递（Many-to-many messaging），这也是一种发布-订阅模型，同时还扩展了一对多的消息传递模型。除了支持多个订阅者外，该模型还支持一个主题有多个发布者。多对多消息传递的一个很好的例子就是e-mail listserve：多个发布者可以将多条消息投递到一个主题，而所有的订阅者将获取每一条消息。
JMS消息的结构相当直观。其中有一个部分（section）用于路由、寻址和消息识别；还有一个可选的部分，在这个部分中可以传递一些特定于应用（application-specific）的参数；第三个 部分存放的是消息的有效负荷（文本 、字节、值映射（value map）、对象，等等）。这三个部分分别被称为头部、属性和主体，如图 1 所示。

图 1. JMS 消息结构


您所使用的消息传递模型的类型取决于您企业的需要。在一个企业中同时使用不止一个的消息传递策略并不少见。在后面的一些小节中，我们将研究一下用于Java 平台的三种JMS解决方案：简单JMS客户机，结合JMS使用的会话bean，以及消息驱动bean。我们将重新回顾每种类型，它们各自的优点和缺点，以及它们对不同企业场景的适用情况。

简单JMS客户机
尽管JMS是与Java 2 Enterprise Edition一起发布的一种企业级的技术，您仍可以轻松地将一个标准Java客户机转换成一个支持JMS的应用。将企业消息传递功能添加到Java applet、命令行应用程序、Swing应用程序或者Java WebStart都非常简单。您只需简单地将少量方法调用添加到J2SE应用代码中，然后将一个包含了JNDI（也是J2EE的一部分）的接口和实现类的JAR文件添加到类路径（classpath）中。如果您已经在客户机上装载了这个JAR文件，并且将它添加到了您的应用的类路径中，那么您就可以使用JNDI来访问JMS提供者（参见下面的参考资料 ，以获得关于JMS消息传递的更多信息的链接）。

简单JMS 客户机的优点和缺点
简单JMS 客户机方法有许多优点，最明显的优点就是它的简单性和普遍性。所有的J2SE应用都可以毫不费力地扩展为可以与一个JMS消息传递系统进行交互。此外，使用JMS的新应用部署起来只需对客户端进行少量的配置，甚至不需要配置。简单JMS客户机是对几乎任何Java体系结构的简单、灵活和轻量级的一个扩展。

从消极的方面来看，我们会遇到安全性、事务处理以及可伸缩性等问题。对于一个简单JMS客户机，您只能选择将安全性和事务处理外包给某个供应商，也就是说，这些问题将是以一种特定于供应商的方式来处理的。如果您的简单JMS客户机既要处理传进来的消息，又要发送消息，那么就会碰到可伸缩性问题。JMS没有能够一次处理多于一个传进来的请求的内建机制。为了支持并发请求，您需要扩展JMS客户机，使其产生多个线程，或者启动多个JVM实例，让这些线程或实例各自运行应用。此外，还需要将JMS提供者配置为在一些适当的目的地上可以有多个订阅者。这时，您（或者您的开发小组）就会质疑简单JMS客户机解决方案是否真的具有简单性。

会话bean与JMS
将会话bean与JMS结合起来使用是一种可行的面向企业的解决方案。会话bean被设计用来履行对业务服务的请求。必须查询企业消息传递系统来履行这样的一个请求，就这一点来说，企业消息传递系统可以由一个会话bean透明地来访问。使用会话bean作为JMS客户机还允许将JMS通信合并到一个大型企业事务的上下文环境中。例如，可以建立一个J2EE事务来从一个JMS提供者那里获取一条消息，从该消息中提取数据，并尝试更新数据库。如果更新操作失败并且事务回滚 （rollback），则再发送一条消息到一个单独