Previous | Next | Trail Map | Building a Service Provider | Miscellaneous

Adding Event Notification Support

Prerequisite: You should be familiar with the event model used by the JNDI before reading this section. The event model is covered in the Event Notification (in the Beyond the Basics trail) lesson.
A service provider typically supports event notification only when the underlying naming/directory service provides such a feature. However, a service provider may support event notification even if the underlying service does not. It simply needs to do more work and perhaps offer the feature by polling the underlying service for changes.

Architectural Overview

Event notification can be implemented in several different ways. Following is one sample architecture. However, the one that works for your service provider will depend on the features of the underlying naming/directory service.

To add event notification support, you need the following three components.

To implement event notification, your context implementation must implement either the EventContext or EventDirContext interface. The bookkeeper might be a part of the context implementation or a utility used by the context implementation. When a program registers a listener, the bookkeeper records the listener and the target in which it is interested. It then uses--creates or uses one from a thread pool--a notifier to track the target. Typically, the notifier is a thread that listens for changes to the target. When the notifier detects a change that will trigger an event, it creates an event that contains the appropriate information and puts it in the event queue. The notifier then returns to listening for future changes. The event queue is monitored by an event queue manager thread, whose job is to remove an event from the queue and dispatch it to the appropriate listeners.

Implementation Tips

Here are some tips to keep in mind when developing your context implementation.

Previous | Next | Trail Map | Building a Service Provider | Miscellaneous