JMS的原版PDF(翻译,若有不准请指出,谢谢~~~)
JMS的介绍
JMS的概述
- 企业级的消息传递产品(当然也通常被称为消息中间件)是一个必要的组件,对于集成公司内部业务的操作来说。这些消息中间件允许多个独立的业务组件组合成一个可靠的且灵活的系统。
- JMS最初的开发目的是为已经存在的已经建立的消息中间件提供一个标准的Java API。自从那以后,很多消息中间被开发出来。
- JMS为Java客户端应用程序和java中间层服务提供一个通用的方法来使用消息中间件。JMS定义了一些消息传递的语义以及一些相应的接口。
- 由于消息中间件是对等的技术,JMS的用户通常被指为客户端。一个JMS应用程序由一些应用程序定义的消息和交换消息的客户端组成。
- 实现了JMS的消息传递产品通过提供一个是实现了JMS的接口的提供者来达到此目的。消息中间件还可能支持除了java变成语言的客户端。即使这样的支持已经超出了JMS的范围,但是JMS的设计总是适应支持非Java语言的消息中间的需求。
总结一下:其实JMS就是一个消息中间的规范,只是纯java编写而已。基于JMS实现的消息中间件的客户端可以不是使用Java编程语言编写的。
什么是消息传递(messaging 意为消息收发)
- 消息传递的术语被定义的十分广泛在计算机工作中。它被用来描述各种操作系统的概念;也用于描述传真和邮件系统;还用来描述企业级的应用程序的异步交互。
- 这里的消息是企业消费的异步请求、报告或事件而不是人类的。消息包含协调这些系统所需的重要信息,包含了描述特殊业务行为的精确地格式化的数据。通过交换这些消息,每个应用程序可以追踪业务的进展。
举个例子:产品部生产系统将产品生产完毕的消息传入中间件。仓库部从中间件接受产品生产完毕的消息。仓库部的存储系统可以追踪产品生产完毕的进度,并且派出人员接受产品进行存放。
JMS的宗旨
- 为Java应用程序实现复杂的企业应用程序提供消息传递功能;
- 定义一组通用的消息传递概念和工具;
- 为java程序员最小化使用企业级消息中间件的概念;
- 最大化Java消息传递应用程序不同消息中间件之间的可移植性。
JMS 消息传递方式
通过企业消息中间件JMS提供两种主要的消息传递的方式:
- 点到点式的消息传递允许一个客户端经由一条队列的中间抽象发送一条信息到其他的客户端。发送消息的客户端发送消息到这条特殊的队列。接受消息的客户端从那条队列中提取消息。(一个发送者,多个接收者,一个接受者)
- 发布和订阅式的消息传递经由一条话题的中间抽象发送一则消息给多个客户端。发送消息的客户端发布消息到这个特殊的话题。然后消息被发表到所有订阅了话题的客户端。(一个发送者,多个接受者)
什么不在JMS范畴中
JMS不处理以下问题:
- 负载均衡和容错。很多的消息中间件为多个实现决定性服务的协作客户端提供支持。JMS API并没指定这些客户端如何协作,使得它们像单一的、统一的服务;
- 错误通知/报告通知。大多数的消息中间件定义了问题的异步通知和系统消息给客户端;JMS没有尝试标准化这些消息。通过遵循JMS的定义,客户可以避免使用这些消息,从而避免使用它们带来的可移植性问题;
- 管理。JMS没定义管理中间件的API;
- 连接协议。JMS并没定义消息中间件的协议;
- 消息类型库。JMS没有定义存储消息类型定义和没定义一种常见消息类型定义的语言。
Java SE和Java EE的支持
JMS API被设计用于使用Java™平台标准版(Java SE)的Java客户机应用程序和使用Java™平台企业版(Java EE)的Java中间层服务。
一个JMS提供者必须支持使用Java SE的Java客户端应用程序使用JMS。给定JMS提供程序是否支持使用Java EE的中间层应用程序使用它是可选的。
Java EE规范要求完整的Java EE平台实现包含消息传递提供程序,该提供程序支持Java SE和Java EE应用程序中的JMS API。
Java EE为消息传递应用程序提供了许多超出JMS规范本身定义的附加特性,最显著的是消息驱动bean (mdb)和JTA事务。Java EE还对JMS API的使用施加了许多限制。
JMS 2.0 新特性
JMS 2.0规范现在要求JMS提供者实现PTP和发布/订阅。
- 传递延迟:消息生成器现在可以指定在指定的时间间隔之后才能传递消息。
- 添加了新的发送方法,以允许应用程序异步发送消息。
- JMS提供程序现在必须设置JMSXDeliveryCount消息属性。
为了帮助可伸缩性,进行了以下更改:
- 创建持久或非持久主题订阅的应用程序现在可以将它们指定为“共享”。共享订阅可能有多个使用者。
对JMS API做了几个改变,使其更简单更容易使用:
- Connection, Session 和其他具有 close()方法的对象现在实现了java.lang.AutoCloseable接口,允许它们在Java SE 7中使用try-with-resources 声明。
- 添加了一个新的“简化API”,它为以前的API提供了一个更简单的替代方案,特别是在Java EE应用程序中。
- 添加了新方法来创建会话,而不需要提供冗余参数。
- 尽管在创建非共享持久订阅时,设置客户机ID仍然是强制的,但在创建共享持久订阅时,它是可选的。
- 添加了一个新的getBody方法,允许应用程序直接从Message中提取消息体,而不需要首先将其转换为适当的子类型。
新方法添加了一个返回一个在持久性话题订阅中的MessageConsumer的Session。应用程序应该事先仅包含特定领域的TopicSubscriber,即使这是不被鼓励的。
JMS 结构
概述
本章描述了基于消息的应用程序的环境以及JMS在该环境中扮演的角色。
什么是JMS应用程序
JMS应用程序由以下部分组成:
- JMS Clients (消息生产者、消息消费者) - 这些是发送和接收消息的Java语言程序。
- Non-JMS Clients - 这些客户机使用消息系统的本地客户机API,而不是JMS。如果应用程序早于JMS的可用性,那么它很可能同时包括JMS和非JMS客户机。
- Messages (消息)- 每个应用程序都定义了一组用于在其客户端之间通信信息的消息。
- JMS Provider(消息中间件、消息服务器MQ) - 这是一个消息传递系统,除了实现功能齐全的消息传递产品所需的管理和控制功能外,还实现了JMS。
- Administered Objects - 受管理对象是管理员为客户端使用而创建的预配置JMS对象。
JMS 的管理
预期每个JMS提供程序在其基础消息传递技术方面将有显著差异。此外,供应商系统的安装和管理方式也有很大的不同。
如果JMS客户机是可移植的,那么它们必须与提供者的专有方面隔离开来。这是通过定义JMS受管理对象来实现的,这些对象由提供者的管理员创建和定制,然后由客户机使用。客户端通过可移植的JMS接口使用它们。管理员使用特定于提供程序的工具创建它们。
有两种类型的JMS受管理对象:
- ConnectionFactory - 客户机使用该对象创建与提供程序的连接。
- Destination - 客户端使用这个对象来指定要发送的消息的目的地和接收的消息源。
受管理对象由管理员放置在JNDI名称空间中。JMS客户机通常在其文档中说明它需要的JMS管理对象,以及应该如何将这些对象的JNDI名称提供给它。一下说明了JMS管理通常是如何工作的。
Administrative Tool — Bind —> JNDI Namespace(CF、D)
JMS Client — Lookup —> JNDI Namespace(CF、D)
JMS Client — Logical Connection —> JMS Provider
两种消息传递方式
JMS应用程序可以使用点到点(PTP)或发布-订阅(pub/sub)风格的消息传递,稍后将在本规范中详细描述。应用程序还可以在一个应用程序中组合这两种消息传递样式。这两种类型的消息传递通常称为消息传递域。JMS提供了这两个消息传递域,因为它们表示两个通用的消息传递模型。
当使用JMS API时,开发者可以使用支持这两个消息传递模型间的接口和方法。当时使用那些接口时,消息传递系统的行为可能稍微不同,因为两个消息传递域有着不同的语义。
JMS APIs
由于历史原因JMS提供了四组可供选择的接口用来发送和接收消息。
JMS1.0定义了两个特定领域的APIs,一个用于PTP(队列),一个用于pub/sub(话题)。尽管由于向后兼容它们依然是JMS的一部分,但是应该认为它们完全被以后的API代替了。
JMS1.1引入了一个提供一组可以用于点到点和订阅发布的消息传递之间的接口的新的统一的API。在这里称它为经典的API。
JMS2.0 引入了一个简化的API,提供经典API的所有特性,但需要的接口更少,使用更加简洁。
每个API提供不同的一组接口用于连接到一个JMS提供者(所谓的消息中间件)和用于发送与接收消息。然而它们全都共享一组通用的接口用来代表消息和消息目的地还有各种实用的特性。
上面提到的接口全部都在javax.jms包下。
多个API通用的接口
多个API主要的通用接口如下:
- Message、ByteMessage、MapMessage、ObjectMessage、StreamMessage和TextMessage(消息) - 一个消息发送到或来自消息中间件。
- Queue(队列)- 一个将消息的目的地的标识封装进内部的受管理对象,用于点到点的消息模型。说白了就是存放Message的地方。