The Event Admin Service provides a publish-subscribe model for handling events. It is implemented according to the OSGi Event Admin Service Specification.
Overview
The Event Admin Service dispatches events between Event Publishers and Event Handlers through interposing an event channel. Publishers provide events to the channel and the event channel determines which handlers need to be notified. Thus publishers and handlers have no direct knowledge of each other, which simplifies the event management.
Contains the complicated logic of the changes monitored in the event handlers. It simplifies the sending and receiving of an event.
Provides synchronous and asynchronous event delivery. Events can be delivered synchronously or asynchronously with the caller.
Ensures that the events will be delivered regardless of the handlers quality.
Applies different optimizations. (Flexible Event Filtering - Event handler can receive only a selected subset of all sent events)
Guarantees secure access to the event channel.
Event Admin – Event broker, which is responsible for the event delivery.
Event Publisher – The Event publisher is completely decoupled from the handlers.
Event Handlers – Handlers receive events without direct knowledge of the publisher.
Events
An event is represented by an org.osgi.service.event.Event object. It has two attributes: topic and properties.
Topics define the type of the event and are used for matching the event with the appropriate Event Handler. They are case-sensitive and are used as a service registration property by the Event Handlers. (Tokens separated by slash '/', represent a hierarchical namespace: org/osgi/framework/BundleEvent/STARTED)
The properties attribute of the event provides information about the actual event in the form of a key-value pairs. The key is a case-sensitive String and the value can be any object.
There are two ways in which events can be delivered: synchronous and asynchronous.
When an event is published synchronously, the Event Admin service finds all Event Handlers subscribed to the topic of this event and notifies each one of them. After each interested Event Handler is successfully notified of the event, the method returns to the Event Publisher.
Asynchronous event publishing is used when it is irrelevant for the Event Publisher when the Event Handlers will receive and process a specific event. The Event Admin service determines which Event Handlers are registered for the specified topic at the time the event is published. Then each Event Subscriber receives notifications for the events in the order in which they were published.
Additional Checks on the Event Properties
EventPropertiesPermission allows the Event Admin to check the sender and the receiver of the event based on the event properties of the event to be sent/delivered. Note, that this check is additional to the standard check for the org.osgi.service.event.TopicPermission with target the topic of the event.
An EventPropertiesPermission consists of a filter which should be matched against event properties and an action.
EventPropertiesPermission has two actions: PUBLISH and SUBSCRIBE.
If a caller wants to post/send event, he should have com.prosyst.mbs.services.eventadmin.EventPropertiesPermission with action PUBLISH and target the event properties of the event (described as a LDAP filter) he would like to send.
On the receiver side, if someone would like to receive an event with specific properties, he should have com.prosyst.mbs.services.eventadmin.EventPropertiesPermission with action SUBSCRIBE and target the event properties of the event he would like to receive.
By default the permission checks on event properties are disabled, so that the current software can work in a compliance with the OSGi R5 specification. Setting the mbs.eventadmin.eventProps.strict system property to true, enables the Event Admin bundle to make these additional checks on the event properties while sending/posting and receiving of events.
