An event is an asynchronous notification from an external source, such as a thread or another application. Commands from a user, a timer signaling completion of a specified time period, and the arrival of a message in a queue are examples of events. Two components that are generally involved in event-based processing are the event producer and the event consumer.

The event producer generates events; the event consumer processes them by taking an action. Event-consumer functionality can be divided into two subcomponents: the listener and the consumer. The listener continuously waits for an event to occur. The moment the event occurs, the listener passes it to the consumer for processing.

The event listener's relationship to the consumer can be either one-to-one or one-to-many. The one-to-many relationship is used mostly in scenarios in which the listener listens for multiple types of events and, based on type, dispatches events to the appropriate consumers. Application requirements determine the choice of one model over the other.

Whatever the model, the event-based system allows asynchronous processing, in which the event producer doesn't have to wait for the consumer to finish processing. Listeners can collect events in a queue and process them later. The producer component doesn't have to worry about the availability of the consumer.

Figure 1 shows a basic event-producer/event-consumer model. There are two message producers; one produces messages of Type A and the other of Type B, and both put messages into the message queue Q1. One listener listens for multiple types of messages, and there are separate consumers for each message type. The listener dispatches messages to the appropriate consumers.

EJB and Event-Driven Processing
Invocation of an enterprise bean in EJB 1.1 specifications is limited to synchronous calls from a servlet or standalone Java client. EJB 1.1 standards lack the support for asynchronous invocation of EJBs on an event such as the arrival of a message or a timer alarm. This limits the use of EJB technology for back-end systems where there's no user interaction, and event-based invocation of EJBs is desirable. This takes the power of asynchronous processing away from the J2EE environment. Although EJB 2.0 specifications provide support for message events, support for timer events is missing. In addition, many application servers on the market still aren't fully compliant with EJB 2.0 standards.

In this article, I'll discuss message and timer events in detail, along with how to implement EJBs based on these two event models.

Timer-Driven Bean
Many applications need to do processing at regular intervals. An example is a system that periodically processes orders from a database and sends invoice messages to a queue for printing. This kind of application uses a timer-based processing model.

You can easily implement this in a non-EJB environment by starting a timer thread that generates timer events at regular intervals. Additional threads act as the event listener and the consumer that processes the orders. The only disadvantage is that the database and the message queue operations can't be put in a single transaction because there is no Distributed Transaction Coordinator (DTC). A great feature of J2EE application servers is the support for distributed transactions. It's advisable to use an EJB hosted under an application server to do the job and maintain transactional integrity.

To implement the same functionality in an EJB environment, the most common approach is to write a Java client that acts as the event producer and listener, running outside the application server and invoking an EJB, which consumes the event by taking an action (see Figure 2). Moving the client functionality inside the application server is generally not advised because EJB specifications don't recommend spawning user threads inside an EJB container.

This model would work fine, except that if 50 different consumer EJBs are required, this system will need a client application with 50 threads running outside the application server to act as listeners. You might wonder why the listener can't be a single thread that queues all the events and consumes them one by one by invoking the event-consumer EJB serially. Actually, this can be done, but with the loss of the parallel consumption of the events. This wouldn't be acceptable in most real-world applications. The only practical solution is to have 50 listener threads, but this too has limitations. It adds another chance for failure because each call from the client JVM is a remote call to the JVM hosting the consumer EJBs. Also, the system has to run an extra JVM.

The easiest way to avoid having a client running outside the application server in a separate JVM is to use an EJB as a user thread. Each EJB runs in a separate thread. EJB specifications prevent creation of user threads inside an EJB container. The trick is using an EJB as a user thread. Whatever functionality is provided by the external client thread can easily be moved inside the application sever using an EJB as a thread.

You can easily implement this solution by developing the Timer-Driven Bean (TDB) component. This comprises two EJBs, one acting as the timer event producer and the other acting as the consumer (see Figure 3). In this solution, the external Java client is required only to start and stop the TDB component and doesn't need to be running all the time. All remaining components run inside an application server.

Timer-Producer Bean
This EJB acts as timer-event producer (see Listing 1). (Listings 1-11 are available for download at www.sys-con.com/websphere/sourcec.cfm.). On a timer event, it invokes the onTimer() method of the timer-consumer bean. After the onTimer() method returns, it sleeps for a specified time period to generate the next event and invokes the onTimer() method on the consumer bean again. The timer-producer bean is a simple component that doesn't contain any business logic. It can be safely deployed as a stateful session bean with the transaction attribute set to TX_NOT_SUPPORTED because it has no interaction with transactional systems.

Timer-Consumer Bean
This EJB acts as timer-event consumer and contains the actual business logic (see Listing 2). In the example scenario, it would be responsible for processing orders from a database and placing invoice messages in a message queue. Because this bean may interact with transactional systems such as databases and message queues, it should be deployed as a stateful session bean with transaction attributes based on application requirements such as TX_BEAN_MANAGED.

Controller Bean
This EJB is required to shut down the timer-driven component gracefully (see Listing 3). It holds the running state of the TDB component. The timer-producer bean checks its state by querying the controller bean after every timer-event handling. If the state is set to shut down, the timer-producer bean exits the while loop gracefully.

It's important to stop the system gracefully - abruptly shutting down the application server may leave some transactions in an in-doubt state. The correct procedure is to shut down all TDB components gracefully before stopping the application server. Listing 3 shows a single static variable controlling the state of all TDB components. If you have different kinds of consumer beans and want to selectively shut them down based on type, you can maintain bean types and their corresponding state in a hashtable with the controller bean. Since the controller bean isn't involved with any transactional systems, it can be deployed as a stateful session bean with the transaction attribute set to TX_NOT_SUPPORTED.

TDB Launcher and TDB Invoker
These two classes are required to start the TDB component (see Listings 4 and 5).The TDB Launcher requires two parameters: the number of beans to start and the timer frequency. The TDB Launcher spawns multiple TDB invoker threads. The TDB Invoker creates an instance of the timer-producer bean and invokes the startBean() method on the producer. Each invoker must run as a separate thread since the startBean() method is a blocking call. Because the timer-producer bean goes into an infinite while loop, there's no reason for the invoker to wait for the startbean() method to return, so the TDB launcher exits the JVM.

TDB Shutdown Agent
This class invokes the shutdown() method on the controller bean, which sets the static variable Controller.running to false (see Listing 6). After processing each event, the timer-producer bean checks the value of Controller.running by invoking the checkRunning() method on the controller bean. As the variable is a static, the TDB shutdown agent only needs to create a single instance of the controller bean and set this variable to false in order to shut down all the TDBs.

Although the sample listings and description of TDB are based on a separate timer-producer and consumer bean, you can merge the functionality of the consumer and the producer into a single EJB.

Message-Driven Bean
Message-driven technology is most commonly used in areas where the complete processing can be broken down into smaller asynchronous processing units, each interacting with another through message queues.

A typical example is the system shown in Figure 4, in which a timer-based component (such as TDB) picks up orders from Database 1 and puts them in Q1. A message-handler component picks up order messages from Q1, generates invoices, and puts them in Q2. Another message-handler component reads invoice data from Q2, sends confirmation e-mails to customers, and updates order status in Database 2.

You can easily implement a message handler in a non-EJB environment by writing a listener and a consumer. The listener thread waits for messages and on arrival passes them to the consumer for processing. If the processing requires interaction with another transactional resource, such as a database, then the consumer running outside the J2EE environment lacks the transactional integrity provided by a DTC. To achieve transactional integrity, the message consumer should be implemented as an EJB that uses the DTC provided by a J2EE application server.

The most common approach to implementing message-driven bean (MDB) functionality in EJB 1.1-based application servers is to provide an external listener to the message queue and an EJB as a message consumer. The listener waits for a message to arrive in the queue. On message arrival, it invokes the message-consumer EJB, passing on the messageID as a parameter (see Figure 5). The listener doesn't process the message itself, but depends upon the consumer EJB to process it. Disadvantages of this type of implementation are:

Timer accuracy: If the time to process the timer event is high in the TDB system, the timer frequency will be affected by the event-processing time. To keep the timer accurate, the events can be sent to a separate queue. The queue can be either in memory or on a messaging system. In this case, the timer-producer bean will put a message in the queue instead of calling the onTimerEvent() method of the consumer bean. If an external queuing system is used, the TDB can be used in conjunction with the MDB system.

Published Sep. 25, 2002 — Reads 12,574
Copyright © 2008 SYS-CON Media. All Rights Reserved.

Related Links

▪ Figure 1

▪ Figure 2

▪ Figure 3

▪ Figure 4

▪ Figure 5

▪ Figure 6

▪ Source Code

About Amit Poddar
Amit Poddar is a principal engineer with a large Internet-based company. He has 10 years of IT experience with expertise in the development of networking protocols and server-side JAVA and has designed and implemented large-scale fault-tolerance systems using IBM MQSeries, Websphere, and SUN HA cluster.