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.
