HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

The notion of events is quite overloaded and various event models have been suggested, standardized and implemented. In this article, I explain the event models in Java, CORBA and ORBs:

  • JavaBeansª and Java events
  • Kona InfoBus
  • CORBA Event Service
  • Visibroker's Event Handlers
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:

  • Participation - A Java component connects to the InfoBus and subsequent InfoBus notifications occur at Java events.
  • Rendezvous - The rendezvous has two phases. A data producer first announces the availability of certain data. This announcement is an InfoBus notification expressed as a Java event. In the second phase, the data consumer asks the producer for the data.
  • Data exchange - The InfoBus provides a number of data access interfaces to accommodate the exchange of data of different types.
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.

Figure 1
Figure 1:

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.

Table 1

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 Java events with CORBA
  • Distributing Java events with the CORBA Event Service
  • Distributing ORB events with the CORBA Event Service
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.

Figure 2
Figure 2:

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.

Figure 3
Figure 3:


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

About the Author
Andreas Vogel is a Senior Consultant with Visigenic Software. He holds a MSc and Phd from Humboldt University, Berlin. After holding research positions at the Universityof Montreal and the Distributed Technology Centre (DSTC) in Brisbane, Australia, he joined Visigenic. Andreas has worked on distributed systems for more than six years and published over 30 papers in international conferences and journals. He wrote the recent book, "Java Programming with CORBA," with Keith Duddy.


Listing 1: Extensions.
public class EventObject extends Object 
{// constructor - source is the object the event occurred in    
public EventObject( Object source );    
// getSource() returns the object the event occurred initially upon    
public Object getSource()} 

Listing 2: Client-side Event Handler interface.
struct ConnectionInfo {    string hostname;    long port;};
interface ClientEventHandler 
{void bind_succeeded(in Object obj, in ConnectionIno info);        
void bind_failed( in Object obj );   
void server_aborted( in Object obj );    
void rebind_succeeded( in Object obj, in ConnectionIno info);    
void rebind_failed( in Object obj );}; 

Listing 3: Server-side Event Handler interface.
interface ImplEventhandler ]
{void bind( in ConnectionInfo info, in Principal, in Object obj );    
void unbind( in ConnectionInfo info,in Principal, in Object obj );    
void client_aborted( in ConnectionInfo info, in Object obj );    
void pre_method( in ConnectionInfo info, in Principal,
in string operation_name, in Object obj );    
void post_method( in ConnectionInfo info, in Principal,
in string operation_name, in Object obj );     
void post_method_exception( in ConnectionInfo info, in Principal,
in string operation_name, in string exception_name,in Object obj ); 

Listing 4: JavaBeans event interfaces in IDL.
module TestEvent 
{exception ListenerAlreadyKnown{};    
exception UnknownListener{};    
struct Event {Object source;        
string str;};    
interface EventListener {void handle_event( in Event event );    
interface EventSource 
{void addEventListener( in EventListener listener ) 
void removeEventListener( in EventListener listener )  

Listing 5: Inserting events in Any objects and their  
public class EventHelper 
{// insertion of the event into an Any and issuing of the event  
public static void insert
(org.omg.CORBA.Any any, TestEvent.Event value ) 
{…}  // receiving the event and extraction of the 
event from the Any  public static TestEvent.Event 
extract(org.omg.CORBA.Any any) {…}}


All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.