I also show how Java events can be distributed using CORBA.

JavaBeans Events
One of the major core features of JavaBeans is an event. The event model is based on JDK 1.1 extensions to the package java.util. These extensions are the class EventObject, the interface EventListener and the exception TooManyListenersException. The extensions are shown in detail in Listing 1.

JavaBeans provides events as a convenient mechanism to propagate state change notifications from a source object to a set of listener objects. JavaBeans events are mainly focused on, but not limited to, events occurring in the context of user interfaces; e.g., mouse events, keyboard actions, etc.

A source event creates and "fires" an event to a number of event listeners. The event itself is an object and its class should extend the class EventObject which is the abstract base class for all events. The listener objects implement the interface EventListener. Firing the event means that the source objects invoke a method on all of the listener objects.

The event object encapsulates the data which is associated with the event and provides access methods. Event targets implement a method which has the event object as an argument. This method is invoked by an event source on all the event sources it wants to notify.

Kona InfoBus
Lotus is developing a set of tools and applications, code-named "Kona", based on Java. One of its components is the Kona InfoBus. The InfoBus is interesting in the context of events as it extends the intra-component communication model provided by the JavaBeans events.

JavaSoft has agreed to incorporate a version of Kona InfoBus into JavaBeans. Although a specification was announced for June, it was not yet available when I wrote this article in mid-July.

The Kona InfoBus provides general mechanisms for data exchange between various components. The roles components can play are data producer and data consumer. The communication between the producers and consumers is decoupled and the information flow is data-driven. This concept, also called rendezvous, is known; e.g., from the Linda programming language. The Kona Infobus is initially targeted for communication between components running within the same Java Virtual Machine.

The Kona InfoBus has three major activities:

CORBA Event Service
The CORBA Event Service provides mechanisms for the asynchronous and de-coupled communication between any number of objects. Components can play the following roles: producer and consumer. Producers and consumers connect to an event channel. All consumers will receive all events supplied by all producers. The Event Service provides a push and pull model for both producers and consumers. Figure 1 shows an event channel with producers and consumers using both the push and the pull model.

An event is of OMG IDL type Any, which means data of any type can be represented in an Any. An Any contains the type information as CORBA Type Code and the data itself. In Java, an Any is an instance of the class org.omg.CORBA.Any. The ORB provides methods for inserting basic IDL data types into Any and extracting them again from an Any. The IDL compiler generates similar methods for user-defined data types. Additionally, the Event Service specification provides interfaces for typed events. That means the type of the events was already known at compile time.

The CORBA Event Service is one of the early adopted CORBAService specifications and implementation is available with most of the leading ORB products. However, only Visibroker provides a pure Java implementation of the Event Service.

CORBA Notification Service
The CORBA Notification Service is a current effort of the OMG to produce a standard on event filtering. Although the RFP for this service has been issued by the Telecommunications Domain Task Force, the result is expected to be generally applicable. It is expected that the Notification Service will build on top of the CORBA Event Service. The final specification is scheduled for fall of this year.

ORB Events
ORB events represent a specific class of the events describing state information about the ORB. They are independent of an event delivery mechanism. ORB events are not specified by CORBA; they are vendor specific. As examples, we consider Visibroker's Event Handlers.

Visibroker's Event Handlers provide a mechanism to obtain information about the state of connections from both the client and the object-implementation side. The events are fired when certain actions occur; e.g., a client binds to an object, the invocation of an operation, the response to an invocation (normal or as exception) or the dropping of a connection from the client or the object.

There are IDL-defined interfaces - one for the client (Listing 2), the other for the object side (Listing 3). You can implement the interfaces according to how you want to react to certain events.

Comparison of the Various Event Models
Table 1 shows a summary of the various event models. It does not include Event Handlers as these are a particular event source but not an event delivery mechanism.

Integrating the Various Event Models and Mechanisms
Although there are plenty of possibilities to integrate the various event models, I concentrate on the following integration models:

Distributing JavaBeans Events with CORBA
The idea of this integration model is to make the JavaBeans event approach and put it on top of the CORBA communication model to enable the notification of events to components beyond Java Virtual Machine boundaries. The interfaces and conventions by the JavaBeans framework are kept wherever possible.

The Event Object is defined as an IDL data type, a struct as shown in Listing 4, which is mapped to a Java interface by the IDL compiler. The methods for the event notification at the event listener's interface and the methods for management of listeners are converted into IDL operations as shown in Listing 4.

Whenever the event's source creates an event, it notifies the registered listeners by invoking the IDL defined operation. The object reference of the source is now a CORBA Interoperable Object Reference instead of the Java Object reference. Figure 2 illustrates this scenario.

Distributing JavaBeans Events with the CORBA Event Service
The event source can avoid the management of event listeners by using a de-coupled communication paradigm which is provided by the CORBA Event Service which was explained above. The event sources publish events to an event channel and the event listeners consume the events from the channel as shown in Figure 3. Event producers and consumers can use the push or the pull model.

The CORBA Event Service uses the IDL type Any for events. Listing 5 shows methods for the insertion of the event, as defined in Listing 4, into an Any and the extraction from the Any.

This model can be further refined by using the forthcoming CORBA Notification Service. This service will allow a data-driven approach similar to the Kona InfoBus but in a distributed fashion. An event source publishes events as before, but the listeners only subscribe to events of a certain type and content. The event selection is controlled by filter objects; listeners can specify the references to filter objects when subscribing to an event channel or using a constraint language to express their filter requirements. Distributing ORB Events via the CORBA Event Service

So far, we have been concerned with the mapping of JavaBeans events and their distribution. Now we take some "arbitrary" events, for example the ones produced by Event Handlers and use the CORBA Event Service as the distribution mechanism. It works exactly the same as in the Bean's case; the Any type of the CORBA events masks the particular details of the various events.

Suggested Readings