Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Enterprise JavaBeans™ Specification, Version 2.0 - Sun Microsystems.pdf
Скачиваний:
14
Добавлен:
24.05.2014
Размер:
2.71 Mб
Скачать

Sun Microsystems Inc

Overview

Enterprise JavaBeans 2.0, Public Draft

Message-driven Bean Component Contract

Chapter 14 Message-driven Bean Component Contract

This chapter specifies the contract between a message-driven bean and its container. It defines the life cycle of the message-driven bean instances.

This chapter defines the developer’s view of message-driven bean state management and the container’s responsibility for managing it.

14.1 Overview

A message-driven bean is a JMS MessageListener. A message-driven bean is invoked by the container as a result of the arrival of a JMS message. A message-driven bean has neither a home nor a remote interface. A message-driven bean instance is an instance of a message-driven bean class.

To a client, a message-driven bean is a JMS message consumer that implements some business logic running on the server. A client accesses a message-driven bean through JMS by sending messages to the JMS Destination (Queue or Topic) for which the message-driven bean is the MessageListener.

Message-driven bean instances have no conversational state. This means that all bean instances are equivalent when they are not involved in servicing a client message.

Message-driven beans are anonymous. They have no client-visible identity.

279

5/31/00

Sun Microsystems Inc.

Message-driven Bean Component Contract

Enterprise JavaBeans 2.0, Public Draft

Goals

A message-driven bean instance is created by the container to handle the processing of the messages for which it is the consumer. Its lifetime is controlled by the container.

A message-driven bean instance has no state for a specific client. However, the instance variables of the message-driven bean instance can contain state across the handling of client messages. Examples of such state include an open database connection and an object reference to an EJB object.

14.2 Goals

The goal of the message-driven bean model is to make developing an enterprise bean that is asynchronously invoked to handle the processing of incoming JMS messages as simple as developing the same functionality in any other JMS MessageListener.

A further goal of the message-driven bean model is to allow for the concurrent processing of a stream of messages by means of container-provided pooling of message-driven bean instances.

14.3 Client view of a message-driven bean

To a client, a message-driven bean is simply a JMS message consumer. The client sends messages to the Destination (Queue or Topic) for which the message-driven bean is the MessageListener just as it would to any other Destination. The message-driven bean, like any other JMS message consumer, handles the processing of the messages.

From the perspective of the client, the existence of a message-driven bean is completely hidden behind the JMS destination for which it is the message listener. The following diagram illustrates the view that is provided to a message-driven bean’s clients.

5/31/00

280

Sun Microsystems Inc

Client view of a message-driven bean

Enterprise JavaBeans 2.0, Public Draft

Message-driven Bean Component Contract

Figure 59 Client view of message-driven beans deployed in a container

Container

Messagedriven bean instances

Client

Destination

Message-driven bean

A client locates the JMS Destination associated with a message-driven bean by using JNDI. For example, the Queue for the StockInfo message-driven bean can be located using the following code segment:

Context initialContext = new InitialContext();

Queue stockInfoQueue = (javax.jms.Queue)initialContext.lookup (“java:comp/env/jms/stockInfoQueue”);

281

5/31/00

Sun Microsystems Inc.

Message-driven Bean Component Contract

Enterprise JavaBeans 2.0, Public Draft

Protocol between a message-driven bean

A client’s JNDI name space may be configured to include the JMS Destinations of message-driven beans installed in multiple EJB Containers located on multiple machines on a network. The actual locations of an enterprise bean and EJB Container are, in general, transparent to the client using the enterprise bean.

The remainder of this section describes the message-driven bean life cycle in detail and the protocol between the message-driven bean and its container.

14.4Protocol between a message-driven bean instance and its container

From its creation until destruction, a message-driven bean instance lives in a container. The container provides security, concurrency, transactions, and other services for the message-driven bean. The container manages the life cycle of the message-driven bean instances, notifying the instances when bean action may be necessary, and providing a full range of services to ensure that the message-driven bean implementation is scalable and can support the concurrent processing of a large number of messages.

From the Bean Provider’s point of view, a message-driven bean exists as long as its container does. It is the container’s responsibility to insure that the message-driven bean comes into existence when the container is started up and that instances of the bean are ready to receive an asynchronous message delivery before the delivery of messages is started.

The Bean Provider can use the deployment descriptor to indicate whether a message-driven bean is intended for use with a topic or queue, and, if the former, whether or not topic subscriptions are to be durable.

Durable topic subscriptions, as well as queues, insure that messages are not missed even if the EJB server is not running. Reliable applications will typically make use of queues or durable topic subscriptions rather than non-durable topic subscriptions.

If a non-durable topic subscription is used, it is the container’s responsibility to make sure that the message driven bean subscription is active (i.e., that there is a message driven bean available to service the message) in order to insure that messages are not missed as long as the EJB server is running. Messages may be missed, however, when a bean is not available to service them. This will occur, for example, if the EJB server goes down for any period of time.

Containers themselves make no actual service demands on the message-driven bean instances. The calls a container makes on a bean instance provide it with access to container services and deliver notifications issued by the container.

Since all instances of a message-driven bean are equivalent, a client message can be delivered to any available instance.

14.4.1 The required MessageDrivenBean interface

All message-driven beans must implement the MessageDrivenBean interface.

5/31/00

282