Why Events?

Adam Rifkin, http://www.ifindkarma.com/attic/phd/

In this note, we motivate announcing and listening for events, as a useful high-level programming communication and coordination mechanism.

Events: An Intuitive Abstraction

Events represent an intuitive way of modelling when something happens, as in physics:

In physics, the fundamental concept is EVENT. The collision between one particle and another is an event, with its own location in spacetime. Another event is the emission of a flash of light from an atom. A third is the impact of the pebble that chips the windshield of a speeding car. A fourth event, likewise fixing in and by itself a location in spacetime, is the strike of a lightning bolt on the rudder of an airplane. An event marks a location in spacetime; it is like a steel stake driven into spacetime.

-- Taylor and Wheeler, Spacetime Physics: Introduction to Special Relativity, second edition, New York: W.H. Freeman and Company, 1992, page 10

Distributed control using computers has traditionally employed procedural programming using fetch-execute feedback cycles:

while (true) do begin

probe-environment;
react-accordingly

end

By contrast, event-oriented programming offers the benefits of direct notification instead of busy-probing; the program tells the environment to inform it when something happens, and when something happens it reacts accordingly.

Note that events also afford a natural way of implementing concurrency. A program can set up multiple event handlers to deal with different things happening independently, and these event handlers can operate in different threads concurrently. Also, since the program does not waste cycles busy-probing, the program itself is free to do other useful things.

Events: A Simple but Useful Model

Event-oriented programming provides a simple model for component interaction that is useful for distributed control problems such as resource reservation and allocation.

Aspects of the model include:

1. Events represented as a hierarchy of classes.
2. Event delivery using the source-listener paradigm, with the potential of using adapters as "middlemen". Sources announce events, and listeners subscribe for event notification.
3. Event listeners register with one or more sources or adapters to receive events from them.
4. Event sources each maintain a list of listeners. Events are sent to listeners by calling an individual method on each listener.
5. Event adapters can behave as event listeners or as event sources as needed. They can subscribe on other sources' event lists, and they can maintain event lists to send events to other listeners by calling an individual method on each listener.

Applied Delegation

Adapters are often employed as intermediary event listeners that can reside between event sources and the event listeners that actually want to act on the events generated. Adapters themselves can be chained compositionally, setting up customizable event-triggering networks.

As middlemen, adapters can be delegated one or more useful applications including:

1. Filtering events.
2. Aggregating events.
3. Forwarding and/or translating events.
4. Archiving events.
5. Maintaining access control to one or more listeners.
6. Wiring events from a source to trigger methods on listener.
7. Demultiplexing multiple event sources to a single listener.
8. Providing default behavior for event listener methods.
9. Controlling the order that an event is delivered to multiple listeners.
10. Controlling the throughput that multiple events are delivered to a single listener.

Last modified: Wed Mar 11 19:07:15 PST 1998