1.1 摘要

本规范描述了JMS的目标和功能。

JMS给java程序员提供了一种通用的方式来创建、发送、接收和查看企业消息系统消息。

1.2 概述

企业消息产品(或者有时称为面向消息的中间件产品)正逐渐成为公司内操作集成的关 键组件。这些产品可以将分离的业务组件组合成一个可靠灵活的系统。除了传统的MOM供应商,企业消息产品也可以由数据库供应商和许多与网络相关的公司来提供。

Java语言的客户端和Java语言的中间层服务必须能够使用这些消息系统。JMS为Java 语言程序提供了一个通用的方式来获取这些系统。JMS是一个接口和相关语义的集合,那些语义定义了JMS客户端如何获取企业消息产品的功能。

由于消息是点对点的,所以JMS的所有用户都称为客户端(clients)。JMS应用由定义 消息的应用和一系列与他们交互的客户端组成。

1.2.1 是Mail API吗?

术语“消息”在计算机领域到处都有。它用于描述各种操作系统概念;用于描述邮件和 传真系统;但在这里用于描述企业应用间的异步通讯。

这里描述的消息是由企业应用而不是人来处理的异步请求、报告或事件。他们包含了协 同这些应用所必需的信息。他们包含了描述特定业务动作的格式化的数据。应用通过交换消息来跟踪企业的过程。

1.2.2 现存的消息系统

消息系统是点对点的工具。通常情况下,每个客户端可以发送消息到另一个客户端,也 可以从任何客户端接收消息。每个客户端连接到提供创建、发送和接受消息的消息代理。

每个系统都提供了定位消息的方式。每个系统都提供了创建消息并给他填充数据的途径。

有些系统可以想多个目的地广播消息。其他的系统也可以只支持向一个目的地发送消息。

某些系统提供了异步接收消息的功能(当消息到达时被转发到客户端)。其他的系统可 以支持同步接收(客户端必须请求每个消息)。

每个消息系统通常提供多种服务供不同的消息来选择。重要的问题是系统能保证转发的长度是多少。它们可能不是一次就能转发完全的。其他重要的问题是消息是有时效、有优先级和是否要求响应。

1.2.3 JMS目标

如果JMS提供了现有消息系统的所有特性,那么对用户来讲它就太复杂了。在另一个方面,JMS 更多是所有消息产品公共特性的交集。重要的是JMS要包含实现专业企业应用需要的功能。

JMS定义了一系列通用的企业消息概念和工具。它试图最小化Java语言程序员使用企业消息产品而必须了解的概念集。它致力于最大化消息应用的可移植性。

1.2.3.1 JMS提供商

正如前面提到的,JMS提供商是一个在消息产品实现JMS的实体。理想情况下,JMS提供商用纯Java来实现消息产品,这样它就能运行在applet中,简化安装,并且可以架构和OS工作。JMS的一个重要目标是最小化实现一个提供商所需要的工作。

1.2.3.2 JMS消息

JMS定义了一系列消息接口。客户端使用由JMS提供商提供的消息实现。JMS的一个主要目标是客户端使用统一的API来创建和与独立于JMS提供商的消息一起工作。

1.2.3.3 JMS域

消息产品可以广义上可以分为点对点或发布‐订阅系统。

点对点(PTP)产品围绕着消息队列创建。每个消息被放置在一个特定的队列中;客户端从队列中取出消息。

发布和订阅(Pub/Sub)客户端将消息放置到某个内容继承层次上的节点上。发布者和 订阅者通常都是匿名的,通常可以动态的发布或订阅内容层级。系统关注将来自一个节点的 多个发布者的消息分发到这个节点的多个订阅者。

JMS提供了一系列的接口来让客户端在两种域下发送和接收消息,同时支持每个域的语义。JMS 也为每个域提供了相应的客户端接口。JMS1.1规范以前的版本,只有对应于每个域 的客户端接口。这些接口继续被支持以提高向后的兼容性。实现客户端的最好方式是使用不 依赖域的接口。这些接口称为“通用接口”是域特有接口的父类。

1.2.3.4 可移植性

最主要的可移植目标是新的只有JMS的应用可以在同一个消息域内可以跨产品。另外,JMS客户端跨机器架构和操作系统是期望的可移植性(当时有同一个JMS提供商时)。尽管设计JMS的目的是让客户端可以和现存的在混合语言应用中使用的消息格式一起 工作,但是这种客户端通常是不可移植的(将一个混合语言应用从一个产品移植到另一个产品超出了JMS 的范围)。

1.12.4 JMS不包含什么

JMS没有包含下列功能:

• 负载均衡/容错(Load Balancing/Fault Tolerance)——许多产品为对多个协同的客户端提供了关键的服务。JMS API 没有指定这种客户端协同如何作为一个单独的统一的服务出现。

• 错误/劝告通知(Error/Advisory Notification)——多数消息产品定义系统消息来向 客户端提供问题或系统事件的异步通知。JMS没有试图标准化这些消息。通过遵循由JMS 定义的指南,客户端可以避开这些消息,这样就可以防止由于使用这些消息而引入的可移植性问题。

• 管理——JMS没有定义管理消息产品的API。

• 安全——JMS没有定义用于控制消息私密性和完整性的API。它也没有指定数字签名或密钥如何被分发到客户端。安全是由JMS提供商要考虑的问题——由管理员配置这些特有的特性,而不是由客户端使用JMS API来控制。

• 通讯协议(Wire Protocal)——JMS没有定义消息的通讯协议。

• 消息类型存储池——JMS没有定义存储消息类型定义的存储池,也没有定义创建消息类型定义的语言。

1.3 JMS的要求是什么

在这个规范内讨论的功能都是对JMS提供商的要求,除非它被显式的指出。

JMS点对点功能的提供商不要求提供发布/订阅功能,反之亦然。

JMS也可以用在J2EE平台。