Design

The design works with the following entities:

  • OSGi Listener An interface which implements a listener for specific OSGi events (e.g. ConfigurationListener).

  • Event The object that contains all the required information required to describe the event (e.g. PID changed).

  • Event Topic The distributed topic used to broadcast events. It is common for all event types.

  • Shared Map The distributed collection that serves as shared resource. We use one per event type.

  • Event Handler The processor which processes remote events received through the topic.

  • Event Dispatcher The unit which decides which event should be processed by which event handlers.

  • Command A special type of event that is linked to a list of events that represent the outcome of the command.

  • Result A special type of event that represents the outcome of a command. Commands and results are correlated.

event flow

The OSGi specification uses the Events and Listener paradigm in many situations (e.g. ConfigurationChangeEvent and ConfigurationListener). By implementing such a Listener and exposing it as an OSGi service to the Service Registry, we can be sure that we are "listening" for the events that we are interested in.

When the listener is notified of an event, it forwards the Event object to a Hazelcazst distributed topic. To keep things as simple as possible, we keep a single topic for all event types. Each node has a listener registered on that topic and gets/sends all events to the event dispatcher.

When the Event Dispatcher receives an event, it looks up an internal registry (in our case the OSGi Service Registry) to find an Event Handler that can handle the received Event. The handler found receives the event and processes it.