An object behavioral design pattern for general-purpose type-based event notification.
Suchitra Gupta
Jeff Hartkopf
Suresh Ramaswamy
This article was originally published in Java Report, July 1998, Volume 3, Number 7, by SIGS Publications.
In our complex world, events are constantly occurring. Any one person is only interested in a very small subset of all these events, so humans have worked out ways of getting just the information of interest, which works to a degree. We may periodically check to see if the event has occurred, or we ask someone to notify us when the event occurs. Often there is more than one source of a particular type of event such as disaster related events, but we do not typically care about whonotifies us, just that the event has occurred. Ideally, we would subscribe to just those types of events in which we are interested, and be notified of them when they occur.
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
Enable components to react to the occurrence of particular events in other components without knowledge of one another, while allowing dynamic participation of components and dynamic introduction of new kinds of events.Also Known As
Dispatcher, Decoupler, Publish-SubscribeMotivation
To understand the need for Event Notifier, we will take a simple example of a network management system, and implement it in a simplistic way. Then we will look at the problems with this approach, and incrementally show how we might solve them using Event Notifier.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.
(a) Simplistic Approach | (b) Mediator Approach |
(c) Observer Approach | (d) Event Notifier Approach |
