What is the difference between the CORBA Notification Service and the CORBA Event Service?

reposted from the original ORBZone article dd. Monday 14 November 2005

The Notification Service can be considered to be a mature extension of the Event Service. The Event Service provided a model to support decoupled communication, it was and is quite simplistic. It provides two models for supplying events, push and pull, and the event data can either be typed or untyped. The event server itself provides no quality of service or persistence.

So what makes the Notification Service a more mature version of this?

The Notification Service could be looked upon as a much more powerful version of the Event Service. It keeps everything that the Event Service has, but provides many additional and powerful features which enable you to implement sophisticated, intelligent event-based communication.

As well as typed and untyped data events, there is also the new native “structured” event. This allows the transmission of a well-defined data structure in addition to the untyped Any. Due to the well-defined message structure extra information can be associated with the event such as filtering and quality of service (QoS) details.

The Notification Service supports content based filtering on event data. Consumers can indicate what types of events they want to receive by providing a filter constraint. Filter objects can be associated with each proxy and/or with the administration object. Filtering is defined using an extension of the Trading constraint language.

The Notification Service introduces quality of service (QoS). This allows QoS to be assigned at different levels of granularity. For example, QoS can be assigned on an event level using the structured event, or QoS can be assigned on a notification channel basis. QoS properties such as reliability and priority can be used to indicate the delivery characteristics of events.

Notification channel persistence can be obtained using the EventReliability and ConnectionReliability QoS. If these properties are set to persistent then the Notification channel will store all event information and all connection information. On a restart, the channel will use this information to restore itself to its previous consistent state.

Consumers can use the mapping filter to assign priorities to events. Depending on the QoS OrderPolicy this may affect the order in which events are delivered to the consumer.

Using the NotifyPublish interface it is possible to prevent unwanted events being put on the network. Suppliers can determine what types of events are being listened on. If no consumers are interested in receiving a particular event type then the supplier will not send the event to notification channel. New consumers can also use the NotifyPublish interface to find out which types of events are currently available.