Event Notifier, a Pattern for Event Notification

Event notification is a useful communication paradigm in computing systems as in real life. This article documents general event notification in the form of a design pattern, which provides a useful way of exposing readers to the important concepts and issues involved in event notification, and provides a language-neutral pattern for implementing event notification in a variety of scenarios. Concurrently, we discuss design issues using examples as appropriate to demonstrate effective use of event notification. Diagrams use the Unified Modeling Notation (UML) [1].

Intent

Also Known As

Motivation

Consider a large network of distributed components, such as computers, hubs, routers, software programs, and so forth. We wish to monitor and manage these components from a central location. We will refer to the components being managed as managed objects. Problems are typically infrequent and unpredictable, but when they do occur we wish to be notified without having to constantly poll the managed objects. The notification may appear on a management system such as a central console, pager, or electronic mail reader. For our example, suppose we have both a console and a paging system. In the simplistic implementation, shown in Figure 1a, a managed object must send notification of problems to both the console and the paging system. If we later wish to change the interface to the console or paging system, or add an electronic mail system, every managed object must be modified. Apart from being unscalable, this approach is very error prone, since each managed object must essentially duplicate the same sequence for notification, making consistency difficult to achieve. Encapsulating the notification behavior in a common superclass only partially mitigates the problem.
 

Figure 1: Approaches to a Network Management System

(a) Simplistic Approach	(b) Mediator Approach
(c) Observer Approach	(d) Event Notifier Approach

In a system of any size, we would like to minimize the number of dependencies and interconnections between objects to keep the system from becoming brittle and hard to change. The more dependencies there are, the more a change in any particular point in the system propagates to other points in the system. The simplistic approach requires each managed object to maintain a reference to each management system. The number of these references increases geometrically with the number of managed objects and management systems. A better approach that keeps this to a linear increase is to have a mediator that encapsulates and coordinates the communication, as shown in Figure 1b. To report a problem, each managed object notifies the mediator, which in turn notifies the console and paging system as appropriate. Now, to modify an existing management system or add a new one, such as an electronic mail system, we need only to modify the mediator. This is a use of the Mediator design pattern [2].

An alternative approach to solving the dependency problem is to introduce the notion of notification to the system in a generic way, using the Observer design pattern [2]. As shown in Figure 1c, each managed object implements a common "subject" interface which allows interested observers such as the paging system and console to register interest in its events. When a managed object has a problem to report, it traverses its internal list of interested observers, calling each in turn. Unlike in the simplistic approach, the managed object does not need to know a priori which systems to notify; the management systems themselves are responsible for dynamically registering with the managed objects for notification. However, we have introduced a new problem: now the management systems need to know about each managed object, to register interest in them. If anything, this is worse, because there may be an arbitrarily large number of managed objects on a large network, and they may come and go frequently. We need a mechanism that requires neither the managed objects nor the management system to have a priori knowledge of each other, but to be able to still communicate problems.

The Observer approach has the benefit of allowing more dynamic behavior than the Mediator approach: new management systems may be added without impacting the rest of the system, although we cannot do the same with managed objects. It also does not require the presence of an omniscient mediator that understands and controls the flow of interactions: behavior that naturally fits in the managed objects or management systems may stay there. However, each subject has the burden of maintaining a list of observers and calling them as necessary, which the mediator approach nicely centralizes. It is possible to implement the system in a way that combines the benefits of both the Mediator and Observer approaches, as shown in Figure 1d. Like in the Mediator approach, we have a central event service that mediates notification, so that managed objects and management systems do not need to know about each other. Like in the Observer approach, a registration system allows us to add and remove observers (called subscribers) dynamically. Unlike the Observer approach, however, this functionality is centralized in the event service, relieving subjects (called publishers) of this burden. We give the name Event Notifier to this best-of-both-worlds approach.

Event Notifier derives many of its benefits from the fact that subscribers only know about events, not about publishers. For example, routers and hubs might both generate events of the same type, say FaultEvent, when problems occur. In an Observer implementation, each management system needs to know which managed objects generate fault events and register with each. The same is essentially true of Mediator, except that the mediator encapsulates this knowledge. However, using Event Notifier, a management system needs only to register interest in the FaultEvent type to get all fault events, regardless of who publishes them.

Applicability

• When an object should be able to notify other objects of an event without needing to know who these objects are or what they do in response.
• When an object needs to be notified of an event, but does not need to know where the event originated.
• When more than one object can generate the same kind of event.
• When some objects are interested in a broader classification of events, while others are interested in a narrower classification.
• When an object may be interested in more than one kind of event.
• When you need to dynamically introduce new kinds of events.
• When objects participating in notification may be dynamically introduced or removed, as in distributed systems.
• When you need to filter out events based on arbitrary criteria.

Structure

Figure 2: Event Notifier Structure

The EventService class contains the aggregations filters, subscribers, and eventTypes. Although not readily apparent from the structure, corresponding elements from these aggregations comprise a tuple. Each tuple corresponds to the parameters passed to a single call to subscribe.

Participants

• Event A common ancestor type for all events.
• ConcreteEvent (FaultEvent) Represents a specific occurrence, possibly containing data about that occurrence.
• Publisher (Hub, Router) Emits or produces events.
• Subscriber Defines an interface for all objects that need to handle events.
• ConcreteSubscriber (Console, PagingSystem) Registers for events, and handles events by implementing the Subscriber interface.
• EventService Brokers events between subscriber and publisher.
• Filter Responsible for discarding events not of interest to a subscriber.
• Class A metaclass (a class whose instances are classes). Event Notifier uses an instance of this class to identify the type of event of interest.

Collaborations

Figure 3: Event Notifier Collaboration Diagram

The subscriber invokes the subscribe method on the event service (1) specifying the event type it is interested in and passes a reference to itself (or possibly another object) and a filter. The eventType argument represents the type of the event. When an event occurs, the publisher invokes the publish method on the event service (2) passing an event object. The event service determines which subscribers are interested in this event, and for each of them applies the filter (3) provided by the subscriber. If no filter is provided, or if application of the filter results in true, then the event service invokes the inform method of the subscriber (4), passing the event as an argument.

Notice that all publication and subscription is done through the event service. The event service maintains all information about which subscribers are interested in which events, so that publishers and subscribers need not be aware of each other. Moreover, anyone may publish or subscribe to events using the well-defined interface provided by the event service without having to implement any special logic to handle interaction with other entities for which it has no other reason to communicate.

Consequences

Subscription is based on event type rather than publisher. In some event notification models, a subscriber registers interest in receiving events from a particular publisher or type of publisher. This is useful when subscribers have knowledge of the publisher. When processing events from a graphical user interface (GUI), for example, the event handler knows about the individual controls that can publish events. In Event Notifier, a subscriber registers interest based solely on event type, without regard to publisher. This is more suitable for services in a distributed environment that are not coupled and may cooperate using an enterprise-wide event hierarchy without any knowledge of each other at compile time or run time. For those cases where subscribers are interested in events from a particular publisher, include an event attribute that identifies the source, and define a filter that uses this attribute to discard uninteresting events.

Subscribing to an event type automatically subscribes to all its subtypes. Because event types are structured in an inheritance hierarchy, when a subscriber subscribes to a particular event type, the event service notifies it of all events of that type or any subtype in the hierarchy. This enables subscribers to specify interest in events as broadly or narrowly as necessary. This feature is easier to implement in languages like Java and Smalltalk that provide rich run-time type information.

Events can be filtered. Filtering allows a subscriber to programmatically select the events of interest. By specifying an event type at subscription time, the subscriber narrows its interest to a certain class of events. An explicit filter allows further selection of events prior to notification, based on custom criteria such as the values of certain event attributes. For example, a filter might use an event source attribute to restrict events to those from a certain source. In the network management example described earlier, regional monitoring centers could use filters to limit events to those received from the regions of interest.

Subscribers and publishers can vary independently. Event subscribers and publishers do not have knowledge of each other and can vary independently. The understanding between the two is via agreement on a set of legal event types, the semantics of what an event means, and event data associated with an event type.

There can be multiple publishers and subscribers for a given kind of event. Some patterns for event notification require a subscriber to "know" each publisher of an event type. This can be difficult or impossible if the publishers of an event cannot be determined at compile time.

Subscribers can be interested in events for a limited duration. They can subscribe and unsubscribe at will. Support for dynamic registration and unregistration allows for this freedom.

Subscribers and publishers may be transient. A new subscriber or publisher can appear or disappear without impacting other components of the system. This is particularly important because it allows relocation of services in a distributed environment.

Event types can be introduced with minimal impact. In languages like Java that support dynamic loading of classes, one can add new event types to an existing application dynamically. Existing subscribers will receive events of the new event type if they are already subscribing to a supertype. One can dynamically add publishers for the new event type without having to rebuild the entire application. In environments without support for dynamic class loading, one may need to rebuild the application to add new event types, but no changes to subscriber or event service code are required.

Event Notifier makes a tradeoff between genericity and static type safety. In large distributed systems, change can entail recompilation and redistribution of many components to multiple locations in a network. It is imperative to design such systems to be resilient to change, minimizing the impact of change to the smallest number of components possible. Using Event Notifier helps accomplish this goal by keeping components decoupled from the beginning and allowing for change by keeping interfaces generic in terms of the types they deal with. However, this genericity and extensibility comes at the cost of some type safety provided by compile-time type checking. If the same event can emanate from one of many sources then this flexibility pays off. The Reclaiming Type Safety subsection under Implementation describes one way to mitigate the lack of static type checking for events.

The event service could be a single point of failure or bottleneck. This could be the case if a single event service brokers all events. However, we can mitigate these and other problems associated with centralization by distributing the work without changing the semantics, as discussed in the Enhancing Fault Tolerance and Performance section of Implementation.

Implementation

Accessing the Event Service

Modeling Events

Figure 4: Example Event Hierarchy

The natural way to implement an event hierarchy in an object-oriented language is by using inheritance. However, it could also be implemented using a string representation, with the levels of the hierarchy separated by colons. For example, the event types in Figure 4 might be represented as Event, Event:ManagementEvent, Event:ManagementEvent:FaultEvent, and so forth. The inheritance mechanism, not surprisingly, has several advantages. Principally, it allows an event subscriber to more easily subscribe to all events in a subtree of the type hierarchy. One subscriber may want all management events, while another may only be interested in data events. This is expressed simply by subscribing to the event at the root of the hierarchy of interest. Furthermore, since events are objects, attributes may be packaged naturally with them, so the subscriber need not invoke methods on (say) the publisher to retrieve those attributes. The inheritance mechanism also takes advantage of compile-time type checking. The compiler will not catch errors in string representations, such as a misspelled event type, but it will catch errors in class names. The advantages to the string technique are that it works in languages that are not object-oriented, and strings may be generated dynamically, while in many languages, objects in an event hierarchy must have classes that are defined at compile time.

Events can have various characteristics, which may lead to alternative ways of arranging them into a single hierarchy. Figure 5 shows two ways to model management events. To take advantage of type-based event notification, it is useful to choose a model based on the kind of events in which one anticipates subscribers having interest. If subscribers may need to be informed of all fault events, regardless of whether they are hardware or software faults, then modeling the events as in Figure 5a would be appropriate. On the other hand, if subscribers are interested in all hardware events regardless of whether they are fault or performance events, devising an event hierarchy as shown in Figure 5b makes sense.
 

Figure 5: Alternative Event Hierarchies

(a) Alternative 1

(b) Alternative 2

Event characteristics may appear as attributes of events instead of being modeled as types in the event hierarchy. However, this approach prevents subscription based on that characteristic. Filters can be used to achieve a similar effect, although they are less efficient and not as type safe.

Identification of event source (publisher) is useful in certain situations. As alluded to earlier, when processing events from a GUI, the action taken by a subscriber in response to an event may depend on the source of the event. On a button click event, the subscriber would want to known which button was clicked. Event source could also be used to advantage in situations where one would otherwise need to specify a number of attributes that have information related to the source. In this case, storing an event source handle as an event attribute will allow a subscriber to get the information it needs about the event source from the event source directly. The tradeoff is that including the event source as an attribute leads to coupling between subscriber and publisher.

Determining Event Type at Run Time

In Java, the Class class is like a metaclass. One can check whether an object is of a certain type by invoking the isAssignableFrom method on the type's Class object, passing the Class object for the object in question. If an instance of the class specified as an argument to isAssignableFrom could be assigned to an instance of the class on which this method is invoked, then the class specified in the argument must be the same class as, or a subclass of, the class on which the method is invoked. This is the essential mechanism for supporting type-based notification in Event Notifier.

Smalltalk supports a similar mechanism as part of its Class class for determining if an object is of a certain type.

C++ also provides run-time type information. To check if an event object is of a certain event type, one might think of using the dynamic_cast operator. However, this is not sufficient, since the event service only knows the event type to which to cast at run time. We would prefer to implement the event service generically, without the need to modify it each time we use it in a different environment with a different set of event types. Even in a single environment, we would prefer not to have to alter the implementation of the event service whenever we introduce a new event type, so as to promote reuse.

A second alternative for C++ uses the type_info class as an approximation of a metaclass. Using the typeid operator, the event service can check whether an event is of the same type as that specified by the type_info object. This technique, however, does not fully address the requirement since the published event could be a subtype of the type in the type_info object. Dealing with this issue requires type information beyond that supported in C++. However, there are well-known ways to accomplish getting the additional type information. One technique is for each class in the event hierarchy to implement an isKindOf method. The NIH class library [3] provides a good example of how this can be done. Every NIH class has a private static member variable named classDesc that is an instance of a class named Class. This class descriptor object contains items of information about an object's class such as its name and superclass(es). Objects instantiated from NIH classes support an isKindOf method that in turn relies on information in the corresponding Class object to ascertain whether an object is of a certain type.

Reclaiming Type Safety

The subscriber receives an event of type Event, which it must downcast to the type of event it is expecting. If a subscriber subscribes to more than one type of event, it first needs to check the event type. Even if it subscribes to only a single event type, it should first validate the event type to prevent run-time errors due to improper coding. For example, the subscriber may inadvertently have given the wrong event type at the time of subscription.

In a language like Java, it is possible to eliminate the need for each subscriber to downcast by relying on the extensive run-time type information and the reflection API provided by the language. For each event type to which a concrete subscriber subscribes, it implements a type-specific inform method that takes as an argument an event of that type. The abstract Subscriber class implements an inform method that takes a parameter of type Event. When an event occurs, the event service calls this inform method. The inform method uses the reflection API to invoke the appropriate type-specific inform method provided by the concrete subscriber, passing the event as an argument. If there is no appropriate type-specific inform method, the abstract subscriber throws an exception. Alternatively, this error could be caught even earlier by the event service at subscription time. Figure 6 illustrates a paging system that subscribes to two event types and provides type-specific inform methods to handle them. Note that the concrete subscriber must not override the inform method that takes an Event type as a parameter, since this will neutralize the dispatching mechanism described.
 

Figure 6: Type Safety

Advertisement and Discovery

Support for this capability requires a simple modification to Event Notifier. Publishers could explicitly advertise the types of events they can publish with the event service by calling an advertise method, and the event service could provide an interface that allows subscribers to discover the list of advertised events.

Distributed Event Notification

Figure 7: Event Proxy Structure

The RemoteEventService is an event service in a distributed environment. An EventProxy resides locally and serves as a proxy for the remote event service, and is implemented as a singleton. It maintains a list of local subscriptions, and subscribes to events from the remote event service on behalf of the local subscribers.

For simplicity, we show the common EventService superclass maintaining the aggregations. It may be necessary to actually implement EventService as an abstract class, with the aggregations implemented in the subclasses RemoteEventService and EventProxy. For example, the event proxy may choose not to maintain a list of subscribers, but to delegate all operations directly to the remote event service. Alternatively, the type of objects stored in the aggregations may be different for the event proxy and the remote event service: the former may store local subscribers, and the latter may store remote subscribers (proxies).

Figure 8 shows a typical interaction between the various objects.
 

Figure 8: Event Proxy Collaboration Diagram

Use of an event proxy insulates publishers from the issues that arise in a distributed environment. In particular, an event proxy can yield the following benefits:

• Encapsulates failures that result in the inaccessibility of the remote event service. For example, if the network or event service is down, the event proxy can queue events and publish them later.
• Ensures that events are delivered to the remote event service in the order in which they are published. This could be used to ensure that events from a specific proxy are delivered from the event service to the subscriber in the order they were published.
• Eliminates the need for publishers and subscribers to know about the location of the remote event service.
• Simplifies the implementation of subscribers by eliminating the need to be remotely accessible by the remote event service.
• Provides a place to add additional behavior such as logging or security, in a manner transparent to subscribers and publishers.
• Reduces network traffic by subscribing for an event on behalf of multiple local subscribers.
• Improves performance from the point of view of the publisher in a multithreaded environment, because the event proxy can return control to the publisher before publishing the event remotely.

Enhancing Fault Tolerance and Performance

Another way to deal with the problem is to use a variation of Event Notifier in which the subscription list is not stored in the event service, but is instead distributed across publishers. One can achieve this without breaking the semantics of a centralized event service by having publishers advertise the event types they intend to publish. The event service would maintain this association of publishers and event types. On subscription to an event type, the event service would pass the subscriber to the publishers of that event type. Now publishers can inform subscribers directly.

Since the subscription list is distributed among the set of publishers instead of being stored centrally in the event service, failure of any single component is likely to have less impact on the system as a whole. Since the frequency of publication is typically much higher than the frequency of subscription, and at publication time events are not being channeled through a single point, there is no single point that could become a bottleneck.

Since the publication list changes less frequently than the subscription list, it is feasible to maintain a "hot spare" for the event service. Whenever an advertisement occurs, the event service updates the hot spare, thus keeping the information current in both places. If the event service goes down, the hot spare can take over.

Asynchronous Notification

Push and Pull Semantics

Subscriber Anchoring

Sample Code

Event Service

public class EventService {
  // Prevents direct instantiation of the event service
  private EventService() throws ClassNotFoundException {
    eventClass = Class.forName("Event");
    subscriptions = new Vector();
  }

  static private EventService singleton = null;

  // Provides well-known access point to singleton EventService
  static public EventService instance() throws ClassNotFoundException {
    if (singleton == null)
      singleton = new EventService();
    return singleton;
  }

  public void publish(Event event) {
    for (Enumeration elems = subscriptions.elements(); elems.hasMoreElements(); ) {
      Subscription subscription = (Subscription) elems.nextElement();
      if (subscription.eventType.isAssignableFrom(event.getClass())
          && (subscription.filter == null || subscription.filter.apply(event)))
        subscription.subscriber.inform(event);
    }
  }

  public void subscribe(Class eventType, Filter filter, Subscriber subscriber)
    throws InvalidEventTypeException {
      if (!eventClass.isAssignableFrom(eventType))
        throw new InvalidEventTypeException();

      // Prevent duplicate subscriptions
      Subscription subscription = new Subscription(eventType, filter, subscriber);
      if (!subscriptions.contains(subscription))
        subscriptions.addElement(subscription);
  }

  public void unsubscribe(Class eventType, Filter filter, Subscriber subscriber)
    throws InvalidEventTypeException {
      if (!eventClass.isAssignableFrom(eventType))
        throw new InvalidEventTypeException();
      subscriptions.removeElement(new Subscription(eventType, filter, subscriber));
  }

  private Class eventClass;
  protected Vector subscriptions;
}

// Stores information about a single subscription
class Subscription {
  public Subscription(Class anEventType, Filter aFilter, Subscriber aSubscriber) {
    eventType = anEventType;
    filter = aFilter;
    subscriber = aSubscriber;
  }

  public Class eventType;
  public Filter filter;
  public Subscriber subscriber;
}

public class InvalidEventTypeException extends RuntimeException {}

Event

public interface Event {}
public interface ManagementEvent extends Event {}

public class FaultEvent implements ManagementEvent {
  public static final int CRITICAL = 1;
  public static final int MODERATE = 2;
  public static final int LOW = 3;

  public int severity;

  FaultEvent() {
    severity = LOW;
  }

  FaultEvent(int aSeverity) {
    severity = aSeverity;
  }
}

Filter

public interface Filter {
  public boolean apply(Event event);
}

public class CriticalFaultFilter implements Filter {
  public boolean apply(Event event) {
    // Assumes that this filter is used only with subscriptions to FaultEvent
    FaultEvent faultEvent = (FaultEvent) event;
    return (faultEvent.severity == FaultEvent.CRITICAL);
  }
}

Subscriber

public abstract class Subscriber {
  abstract void inform(Event event);
}

public class PagingSystem extends Subscriber {
  public PagingSystem() throws ClassNotFoundException {
    FaultEvent event = new FaultEvent();
    CriticalFaultFilter filter = new CriticalFaultFilter();
    EventService.instance().subscribe(filter.getClass(), filter, this);
  }

  public void inform(Event event) {
    // Assumes that this subscriber has only subscribed to FaultEvent
    FaultEvent faultEvent = (FaultEvent) event;

    // Respond to the event
    System.out.println("Critical Fault Event occurred:" + faultEvent);
  }
}

Publisher

public class Router {
  public static void triggerPublication() throws ClassNotFoundException {
    Event event = new FaultEvent(FaultEvent.CRITICAL);
    EventService.instance().publish(event);
  }
}

Using Dynamic Typing to Restore Type Safety

public abstract class Subscriber {
  public void inform(Event event) {
    Class paramTypes[] = new Class[1];
    paramTypes[0] = event.getClass();
    try {
      // Look for an inform method in the current object
      // that takes the event subtype as a parameter
      Method method = getClass().getDeclaredMethod("inform", paramTypes);
      Object paramList[] = new Object[1];
      paramList[0] = event;
      method.invoke(this, paramList);
    }
    // Catch appropriate exceptions
  }
}

public class PagingSystem extends Subscriber {
  public void inform(FaultEvent event) {
    // Handle the fault event with no need to downcast
  }
}

Known Uses

JavaBeans

CORBA

The CORBA Event Service supports both pull and push models, which allow suppliers and consumers to play active or passive roles. This results in unnecessary complexity. Furthermore, the CORBA Event Service provides no filtering.

Related Patterns

References

1. Booch, G., I. Jacobson, and J. Rumbaugh. Unified Modeling Language User Guide, Addison-Wesley, Reading, MA, 1997.
2. Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, Reading, MA, 1995.
3. Gorlen, K., S. Orlow, and P. Plexico. Data Abstraction and Object-OrientedProgramming in C++, John Wiley and Sons, 1990.
4. Schmidt, D. and S. Vinoski. "The OMG Events Service," C++ Report, SIGS Publications, New York, NY, Volume 9 Number 2, Feb. 1997.
5. Vlissides, J. "Pattern Hatching: Multicast," C++ Report, SIGS Publications, New York, NY, Volume 9 Number 8, Sep. 1997.