Members
- Telefónica I+D represented by Juan A. Cáceres (Project coordinator)
- GSyC group from Universidad Rey Juan Carlos represented by Andrés L. Martínez
Contacts
Introduction
The TIDNotif Java service implements the standard CORBA Event Notification Service Specification v.1.1 that extends, in turn, the CORBA Event Service Specification. Not all the functionalities have been implemented, only those that are mandatory in the standard specification or required by Telefónica I+D’s customers. There is another version of TIDNotif written in C++ with the same functionalities but it is not Open Source.
Event Service
The Event Service follows a event distribution scheme where two basic rolls are identified:
- Event Consumers
- Event Providers
There are two event communication models between providers and consumers:
- PUSH: the event provider initiates the communication. The event consumer exports a CORBA interface comprising operations for the reception of events that the provider invokes.
- PULL: the event consumer initiates the communication. The event provider exports a CORBA interface comprising operations for deliver events that the consumer invokes to receive events. The consumer is blocked until the provider has an event to offer.
TIDNotif implements the PUSH model.
An Event Service maintains an Event Channel. The Event Channel is a service that decouples the communication between consumers and providers of events. The Channel of Events is simultaneously a consumer and a provider of events.
The Event Channel provides an asynchronous communication of events between consumers and providers of events by means of supporting a subscription mechanism:
- The consumers and providers communicate with the channel of events using invocations of standard CORBA operations (providers to send and consumers to receive events).
- Consumers (providers) connected to a channel don’t know about identity and number of providers (consumers) connected to a channel.
The Event Channel maintains a queue, where events coming form connected providers are enqueued and finally extracted for distribution across to consumers.
Notification Service
In the specification of the Event Notification Service, the Notification Channel concept is introduced that offers two families of interfaces for consumers and providers subscription. A Notification Channel exports the same administrative operations as a Channel of Events.
A Notification Channel can have more than one ConsumerAdmin object (SupplierAdmin) registered, each one representing a specific group of consumers (providers) connected to the channel.
The ConsumerAdmin objects (SupplierAdmin) and proxy objects export operations that allow:
- Quality of the service (QoS) management
- Event lifecycle control and persistence
- Event Channel elements persistence
- Assignment of Priorities (0 is the Maxima priority) to Events
- Filters definition
- Filtering by restrictions: a filter is a set of restrictions that a event must fulfil to be forwarded to the next element in the Notification Channel
- Transformation rules: some QoS priorities parameters can be associated on the fly for a given event if the event fulfils a specific rule.
Proxy consumer (provider) objects export operations that allow the establishment of filters that affect the way in which the events are notified to the connected consumers (providers).
Notificantion Channel Architecture:
TIDNotif Implementation
The TIDNotif implementation has a pipe-line architecture where event distribution and event reception are managed by different thread pools and, queues (all implemented with CORBA resources) as well as an internal set of asynchronous interfaces that frees the invoking threads outside the service as soon the event is delivered to/from the Notification Channel.
Success Stories
TIDNotif Java service is used in system network and switching boards management systems as well as in workforce management systems. In these kind of systems, Notification Service is usually associated to supervision human/machine interfaces where operators have a control panel where alarms and events are shown and are filtered by the kind of events, devices that has delivered them, geographical area were the event has been produced, etc. These systems make an intensive use of the services (e.g. 200,000 events/day), so performance and robustness are key features.
References
CORBA Event Service Specification CORBA Notification Service Specification
