Sun Java Center J2EE Patterns

Print-friendly Version

Context

Enterprise beans and other business services need a way to be activated asynchronously without user intervention.

Problem

Enterprise beans implemented prior to the EJB 2.0 specification do not support asynchronous invocation. EJB 2.0 introduces integration with JMS by providing a Message Driven Bean, which is a new type of stateless session bean. When a client needs to access the services offered by an enterprise bean, it does so by first looking up the bean's home interface, then calling create/find/remove on the home. All interactions between the client and the enterprise beans components are remote and synchronous. The EJB specification permits the container to passivate an enterprise bean to secondary storage. As a result, the EJB container has no mechanism by which it can provide a process-like service where an enterprise bean is always in activated and ready state. Because the client must interact with the bean using the bean's remote interface, even if the bean is always activated in the container, the client still needs to obtain its remote interface via the lookup process and still interacts with the bean in a synchronous manner.

If application needs are synchronous processing for server-side business components, then enterprise beans are the appropriate choice. Some application clients may require asynchronous processing for the server-side business objects because the clients do not need to wait or do not have the time to wait for the processing to complete. In such cases, the bean functionality provided by pre-EJB 2.0 specification implementations fails to offer the required solution.

In EJB 2.0, the newly introduced message-driven bean is a special type of stateless session bean. However, the new specification does not offer asynchronous invocation for other types of enterprise beans such as stateful or entity beans.

In general, any business service that provides only synchronous processing may be a limitation to implement asynchronous processing.

Forces

• Enterprise beans are exposed to their clients via their remote interfaces, which allow only synchronous access (pre-EJB 2.0 specification implementations).
• The container manages enterprise beans, allowing interactions only via the remote references. The EJB container does not allow direct access to the bean implementation and its methods. Thus, implementing the JMS message listener in an enterprise bean is not allowed since this violates the pre-EJB 2.0 specifications by permitting direct access to the bean implementation. The EJB 2.0 specification specifies a new type of bean called Message Driven Bean that allows a special type of stateless session bean to implement the JMS Message Listener interface and listen to messages.
• An application needs to provide a publish/subscribe framework where clients can publish requests to enterprise beans, which can process these requests in an asynchronous mode.
• Clients need asynchronous processing capabilities from the enterprise beans and other synchronous business service components so that the client can send a request for processing without waiting for the results.
• Clients want to use the message-oriented middleware (MOM) interfaces offered by the Java Messaging Service (JMS). These interfaces are not integrated into EJB server products that are based on the pre-EJB 2.0 specification.
• Need to provide daemon-like features so that an enterprise bean can be in a quiet mode until an event (or a message) triggers its activity.
• Enterprise beans are subject to passivation due to time outs and stale references.
• EJB 2.0's Message Driven Bean is a stateless session bean. It is not possible to invoke other types of entity beans asynchronously.

Solution

Use a Service Activator to receive asynchronous client requests and messages. On receiving a message, the Service Activator locates and invokes the necessary business methods on the business service components to fulfill the request asynchronously.

The ServiceActivator is a JMS Listener and delegation service that requires implementing the JMS message listener-making it a JMS listener object that can listen to JMS messages- and it can be implemented as a standalone service. Clients act as the message generator, generating events based on their activity.

Any client that needs to asynchronously invoke a business service, such as an enterprise bean, may create and send a message to the Service Activator. The Service Activator receives the message and parses it to interpret the client's request. Once the client's request is identified, the Service Activator locates the necessary business service components and invokes the business services to complete processing the client's request asynchronously.

The Service Activator may optionally send an acknowledgement to the client after successfully completing the request processing. The Service Activator may also notify the client or other services on failure events if it fails to complete the asynchronous request processing.

The Service Activator may use the services of a Service Locator to locate a business component (see Service Locator pattern).

Structure

The following class diagram represents the relationships for the Service Activator pattern.

Participants & Responsibilities

The following sequence diagram shows the interaction between the various participants in this pattern.

Client
The client requires an asynchronous processing facility from the business objects participating in a workflow. The client can be any type of application that has the capability to create and send JMS messages. The client can also be an enterprise bean that needs to invoke another enterprise bean's business methods in an asynchronous manner. The client can use the services offered by the Service Locator pattern to look up or create enterprise beans, JMS services and JMS objects as necessary.

Request
The Request is the message object created by the client and sent to the ServiceActivator via the message-oriented middleware. According to the JMS specification, the Request is an object that implements the javax.jms.Message interface. The JMS API provides several message types, such as TextMessage, ObjectMessage, and so forth that can be used as request objects.

ServiceActivator
The ServiceActivator is the main class of the pattern. It implements the javax.jms.MessageListener interface, which is defined by the JMS specification. The ServiceActivator has an onMessage() method that is invoked when a new message arrives. The ServiceActivator parses (unmarshals) the message (request) to determine what needs to be done. The ServiceActivator may use the services offered by a Service Locator (see Service Locator) pattern to look up or create Business Service components such as enterprise beans.

BusinessObject
BusinessObject is the target object to which the client needs access in an asynchronous mode. The business object is a role fulfilled by either a session or entity bean. It is also possible that the BusinessObject an external service instead of an entity bean. In most EJB applications, a Session Façade (see Session Façade pattern) may fulfill the role of the BusinessObject to provide the required services. In such cases, the Service Activator activates the workflow encapsulated in a Session Façade.

Strategies

Strategies for BusinessObject

Session Bean vs. Entity Bean:

In simple applications with minimal workflow, an entity bean may fulfill the BusinessObject role. However, it is not recommended that the Service Activator deal directly with multiple entity beans. Such workflow is usually encapsulated in a Session Façade instead.

Stateful vs. Stateless Sesson Bean as the BusinessObject:

When a Session Bean fulfills the role of the BusinessObject, the business requirements determine whether the bean should be stateful or stateless. Since the client for the BusinessObject is a ServiceActivator that activates the BusinessObject on receiving a new message, the workflow to process the message can define whether the bean should be stateful or not. In most cases, a message delivery simply activates a single method in the BusinessObject that delegates the processing of the message within. This is typical when the BusinessObject is a Session Façade that provides coarse-grained business services in an EJB application. A stateless session bean can be used in these cases. If the ServiceActivator needs to invoke multiple methods in the BusinessObject or to work with more than one BusinessObject to fulfill the processing requirements for a message, it may be useful to consider a stateful session bean to retain state between multiple invocations.

Strategies for ServiceActivator

The most straightforward strategy for the listener or ServiceActivator is to implement it as a standalone JMS application that listens and processes JMS messages.

An alternative is to implement the ServiceActivator as a service of the application server. This may make it easier to manage the ServiceActivator, because it uses the application server features to monitor the ServiceActivator state, and to start, restart, and stop the ServiceActivator as needed, either manually or automatically.

Strategies for Clients

The Client can be type of any client, including another enterprise bean, that requires asynchronous processing from the enterprise bean. When integrating legacy applications to the J2EE platform, Java application clients are a logical choice to act as the message generators based on the activity in the legacy system. The ServiceActivator can receive messages and perform the necessary enterprise bean invocations to process the request from the legacy system.

Consequences

• Integrates JMS into pre-EJB 2.0 implementations
  Prior to the EJB 2.0 specification, there was no integration between enterprise bean and JMS components. This pattern provides a means to integrate JMS into an EJB application and enable asynchronous processing. The EJB 2.0 specification defines a new type of session bean, called a message-driven bean, to integrate JMS and enterprise beans. This special bean implements the JMS Message Listener interface and it receives asynchronous messages. In this case, the application server plays the role of the ServiceActivator. This pattern makes it possible to run applications in EJB 2.0 implementations as well as pre-EJB 2.0 implementations.
   
• Provides asynchronous processing for any enterprise beans 
  In EJB 2.0, the message-driven bean is a stateless session bean. Using the Service Activator pattern, it is possible to provide asynchronous invocation on all types of entity beans such as stateless session bean, stateful session bean and entity bean. As previously explained, since the ServiceActivator is implemented in its own right, without any limitations of the message driven bean, the Service Activator can perform asynchronous invocations on any type of business service. Thus, this pattern provides a way to enable asynchronous processing for applications that either have no need to wait for the results or do not want to spend time waiting for processing to complete. The processing can be deferred and performed at a later time, enabling the client to complete the service in less time.
  
• Standalone process
  The ServiceActivator can be run as a standalone process. However, in a critical application, ServiceActivator needs to be monitored to ensure availability. The additional management and maintenance of this process can add to application support overhead.

Related Patterns

• Session Facade [SJC]
  The Session Facade pattern encapsulates the complexity of the system and provides coarse-grained access to business objects. This Service Activator pattern may access a Session Façade as the primary business object to invoke business service methods in the Session Façade asynchronously on behalf of the client.
• Business Delegate [SJC]
  The Service Activator pattern employs the delegate pattern because it delegates the received message's work to the ServiceActivator object. The ServiceActivator acts as a listener. On receiving a new message, the Service Activator fulfills the role of a delegate to get the work done for the message.
• Service Locator [SJC]
  The client can use the Service Locator pattern to look up and create JMS-related service objects. The ServiceActivator can use the Service Locator pattern to look up and create enterprise bean components.

(c) 2000-2001 Sun Microsystems, Inc. All Rights Reserved.

Version 1.0 Beta