8.1. Events in the Distributed Environment

Java provides a simple but powerful event model based on event sources, event listeners and event objects (see Figure 8.1). An event source is any object that “fires” an event. Events may be fired based on any internal state change in an object. For instance, an object representing a graphical button may fire an event when a user clicks on the button.

An event listener is an object that listens for events fired by an event source. Typically an event source provides a method whereby listeners can request to be added to a list of listeners. Whenever the event source fires an event, it notifies each of its registered listeners by calling a method on the listener object and passing it an event object.

Events in this model are delivered reliably and instantaneously. If a user clicks on “Button A” and then “Button B,” an object that's registered to receive both button clicks will receive both events, and will never receive the second button click before the first. This guarantee is in large part due to the fact that events are occurring within one Java virtual machine (JVM).

Distributed events, on the other hand, must travel from one JVM to another JVM that may be running remotely over a network. Figure 8.2 illustrates how distributed events mirror the use of event sources, event listeners, and event objects. In the distributed environment the semantics of event delivery are not as straightforward because of the possibility of partial failure. Messages traveling from one JVM to another may be lost in transit, or may never reach their event listener. Likewise, an event may reach its listener more than once if the source can't be sure the first event notification made it to the event listener. There is also a possibility two events may take different paths through the network, causing events to arrive out of order. In sum, it is difficult to make the same guarantees in the distributed environment that we take for granted in the single JVM model.

The lack of guarantees in the distributed event environment is present in the Jini™ Distributed Event model: Events may arrive multiple times, or may arrive out of order, or may not arrive at all. The distributed event API gives us a few tools to deal with these problems, but, as we will see, it will be your responsibility to ensure correctness in your applications.

Space-based distributed events are built on top of the Jini Distributed Event model, which extends the Java platform's event model to allow events to be passed from event sources in one JVM to remote event listeners in different, possibly remote JVMs. When using space-based distributed events, the space is an event source that fires events when entries are written into the space that match templates. When the event fires, the space sends a remote event object to the listener.

The Jini Distributed Event model is incorporated into JavaSpaces technology as follows: The JavaSpace interface provides a notify method that allows processes to register an object's interest in the arrival of entries that match a specific template (which is passed as a parameter to notify). When an entry arrives that matches the template, an event is generated by the space and sent to the registered object in the form of a remote event object, by calling a notify method on the listener.

To avoid confusion, it's important to take note right away that two notify methods come into play in the distributed event model. One is a method in the JavaSpace interface, while the other is a method that listeners must implement. The fact that both have the same name is unfortunate, but their use should become clear as we progress through the chapter.

Before getting into these details, we are going to introduce space-based distributed events by building a simple example that uses notify. Then we'll dive down deeper by taking a look at the technical details surrounding event notification in JavaSpaces software development.