JavaMessageService 2.0 API：规范与应用

需积分: 10 106 浏览量更新于2024-07-23 收藏 1.6MB PDF 举报

"jms2.0 API - Java Message Service 2.0 规范" Java Message Service (JMS) 2.0 是一个应用程序接口（API），它允许Java程序员访问企业消息传递系统。这个API是Java平台的标准部分，主要用于在分布式环境中实现异步通信和解耦应用程序。JMS 2.0是JMS规范的最新版本，由Java社区进程（JSR-343）定义，并在2013年3月发布了最终版本。在JMS 2.0中，有以下几个核心知识点： 1. **消息模型**：JMS支持两种基本的消息模型，即点对点（Point-to-Point, P2P）和发布/订阅（Publish/Subscribe, Pub/Sub）。点对点模型中，消息由一个生产者发送到一个队列，然后被一个消费者接收。发布/订阅模型中，消息发布者将消息发送到主题，多个订阅者可以接收到这些消息。 2. **消息对象**：JMS提供了几种消息对象，包括`Message`、`TextMessage`、`ObjectMessage`、`BytesMessage`和`MapMessage`，用于封装不同类型的数据。 3. **生产者与消费者**：`MessageProducer`类用于创建并发送消息，而`MessageConsumer`类用于接收消息。JMS 2.0引入了简化API，允许直接在`Queue`或`Topic`上创建生产者和消费者，无需创建单独的会话对象。 4. **会话**：`Session`对象是线程安全的，用于管理事务和创建消息的生产者和消费者。会话可以配置为事务性或非事务性，以控制消息的确认策略。 5. **连接与连接工厂**：`Connection`对象代表到JMS提供者的连接，而`ConnectionFactory`则用于创建连接。JMS 2.0引入了预定义的连接工厂，使得配置更加简单。 6. **持久化与非持久化消息**：持久化消息即使在服务器重启后也能保留，而非持久化消息在消息传递失败时可能会丢失。用户可以根据业务需求选择消息的持久性。 7. **消息选择器**：在订阅者端，可以使用消息选择器来过滤接收的消息，只处理满足特定条件的消息。 8. **共享订阅**：在发布/订阅模型中，JMS 2.0支持共享订阅，允许多个订阅者共享同一个订阅，所有订阅者都能接收到消息，但每个订阅者只能看到自己的副本。 9. **幂等性**：考虑到分布式系统中的重复消息问题，设计消息处理逻辑时通常需要确保消息的幂等性，即多次处理同一消息应得到相同的结果。 10. **JMSContext**：JMS 2.0引入了`JMSContext`接口，它是`Session`和`Connection`的组合，简化了API的使用，提供了一种更简洁的方式来创建消息和管理会话。通过JMS 2.0 API，开发者可以构建高度可扩展、容错性强的系统，实现组件之间的解耦，提高系统的灵活性和可靠性。JMS 2.0规范的实施允许不同供应商的消息中间件产品之间具有互操作性，使得选择合适的JMS实现变得更加容易。

16 Java Message Service Version 2.0

2. Architecture

2.1. Overview

This chapter describes the environment of message based applications and

the role JMS plays in this environment.

2.2. What is a JMS application?

A JMS application is composed of the following parts:

 JMS Clients - These are the Java language programs that send and

receive messages.

 Non-JMS Clients - These are clients that use a message system’s native

client API instead of JMS. If the application predated the availability of

JMS it is likely that it will include both JMS and non-JMS clients.

 Messages - Each application defines a set of messages that are used to

communicate information between its clients.

 JMS Provider - This is a messaging system that implements JMS in

addition to the other administrative and control functionality required of

a full featured messaging product.

 Administered Objects - Administered objects are preconfigured JMS

objects created by an administrator for the use of clients.

2.3. Administration

It is expected that each JMS provider will differ significantly in its

underlying messaging technology. It is also expected there will be major

differences in how a provider’s system is installed and administered.

If JMS clients are to be portable, they must be isolated from these

proprietary aspects of a provider. This is done by defining JMS

administered objects that are created and customized by a provider’s

administrator and later used by clients. The client uses them through JMS

interfaces that are portable. The administrator creates them using provider-

specific facilities.

There are two types of JMS administered objects:

 ConnectionFactory - This is the object a client uses to create a

connection with a provider.

 Destination - This is the object a client uses to specify the

destination of messages it is sending and the source of messages it

receives.

Administered objects are placed in a JNDI namespace by an administrator.

A JMS client typically notes in its documentation the JMS administered

objects it requires and how the JNDI names of these objects should be

provided to it. Figure 2-1 illustrates how JMS administration ordinarily

works.

2. Architecture 19

 ConnectionFactory - an administered object used by a client to

create a Connection. This interface is also used by the classic API.

 JMSContext - an active connection to a JMS provider and a single-

threaded context for sending and receiving messages

 JMSProducer - an object created by a JMSContext that is used for

sending messages to a queue or topic

 JMSConsumer - an object created by a JMSContext that is used for

receiving messages sent to a queue or topic

Figure 2-3 Overview of simplified API

In the simplified API a single JMSContext object encompasses the

behaviour which in the classic API is provided by two separate objects, a

Connection and a Session. Although this specification refers to the

JMSContext as having an underlying “connection” and “session”, the

simplified API does not use the Connection and Session interfaces.

2.8.1. Goals of the simplified API

The simplified API has the following goals:

 To reduce the number of objects needed to send and receive messages,

and in particular to combine the JMS Connection, Session objects

into a single object.

 To maintain a consistent style with the existing API where possible so

that users of the old API feel it to be an evolution which they can learn

quickly. In particular the simplified API will continue to use the

concepts of connection and session even though it doesn’t require the

use of Connection or Session objects.

 To be capable of use in both Java EE and Java SE applications.

 To allow resource injection to be exploited in those environments which

support it.

 To provide the option to send and receive the message body directly

without the need to use javax.jms.Message objects.

 To remove where possible the need to catch JMSException on method

calls

 To be functionally as complete as the classic API, so that users of the

simplified API will not have the need to switch back to the classic API

Message

creates

JMSProducer

JMSConsumer

JMSContext

creates

receives

from

sends to

Destination

Connection

Factory

creates

20 Java Message Service Version 2.0

in order to perform an operation that is unavailable in the simplified

API.

 To be an alternative to, but not a replacement for, the classic API. The

classic API remains and is not deprecated. Developers who are familiar

with the classic API, or who prefer it, may continue to use the classic

API.

2.8.2. Key features of the simplified API

The main object in the simplified API is javax.jms.JMSContext. This

combines in a single object the functionality of several separate objects from

the classic API. In particular it combines the functionality of a Connection

and a Session in a single object.

Although the JMSContext does not expose constituent Connection and

Session objects to applications, the concepts of connection and session

remain important. A Connection represents a physical link to the JMS

server, a Session represents a single-threaded context for sending and

receiving messages, and a JMSContext represents both.

Applications that send messages will use the JMSContext method

createProducer to create a javax.jms.JMSProducer object. This

provides an API to send messages. Although it provides similar

functionality to an anonymous MessageProducer (one with no destination

specified) it provides a more convenient API for configuring delivery

options, message properties and message headers.

Applications that consume messages will use one of several methods on

JMSContext to create a javax.jms.JMSConsumer object. This provides a

similar API to a MessageConsumer for consuming messages from a

particular queue or topic. Messages may be consumed either synchronously

or asynchronously, except in a Java EE web or EJB container where

messages may be consumed only synchronously.

Applications running in the Java EE web and EJB containers are not

permitted to create more than one active session on a connection (see

Section 12.2 “Restrictions on the use of JMS API in the Java EE web or EJB

container”. Since a JMSContext contains a single connection and a single

session it is ideally suited for use by such applications.

Applications running in a Java SE environment or in the Java EE application

client container are permitted to create multiple active sessions on the same

connection. This allows the same physical connection to be used in multiple

threads simultaneously. Such applications which require multiple sessions to

be created on the same connection should use the factory methods on the

ConnectionFactory interface to create the first JMSContext and then

use the createContext method on JMSContext to create additional

JMSContext objects that use the same connection:

To simplify application code, methods on JMSContext throw unchecked

exceptions rather than checked exceptions.

2.9. Legacy domain-specific API interfaces

Although the domain-specific API remains part of JMS for reasons of

backwards compatibility it should be considered to be completely

superseded by the classic and simplified APIs.

剩余155页未读，继续阅读

yangqicong

粉丝: 45
资源: 13

JavaMessageService 2.0 API：规范与应用

JMS规范教程(中文)

jms规范2.0（中英文都有）

JMS之ActiveMQ工具类+使用例子.zip

JMS_2.0_API.chm

ejb2.0 api文档快速开发

JMS 2.0规范详解：Java企业消息系统接入

Spring 2.0中文API（chm格式）

JavaEE5 API、 Commons-dbutils、CSS2.0、JDK API_1.6、j2ee6、javax.servlet_api

JMS 介绍及其在 EJB 2.0 中的用法

Spring 2.0学习文档 和Spring API文档

最新资源

Spring 2.0学习文档和Spring API文档