Überblick über den OMG Notification Service

Da in diesem Kapitel ein Vergleich des JMAPI Event Services mit dem OMG Notification Service vorgenommen werden soll, wird zunächst auf letzteren kurz eingegangen.

Der OMG Notification Service [BEA98] erweitert den CORBA Event Service [OMG97] um folgende Möglichkeiten:

• Unterstützung von strukturierten Events
• Definition von Filtern, die festlegen, an welchen Events ein Client interessiert ist.
• Event Supplier können feststellen, an welchen Event-Typen Clients eines Channels interessiert sind, um nur solche Events weiterzuleiten.
• Event Consumer können ermitteln, welche Event-Typen von einem Supplier angeboten werden, um sich so für neue Event-Typen zu registrieren.
• Möglichkeit der Konfiguration verschiedener Quality-of-Service Parameter (beispielsweise Delivery Guarantee, Event Aging und Event Prioritization).
• Ein Event Type Repository kann angelegt werden, welches Information über die Struktur von Events eines Event Channels zugänglich macht.

  

Abbildung 5.5: Architektur des Notification Service

Abbildung 5.5 stellt das Architekturmodell des Notification Service dar.

Events werden von Suppliers generiert und an den Event Channel weitergeleitet. Dieser nimmt Events über eines der Proxy Consumer Interfaces entgegen. Auf der anderen Seite erhalten Consumer von Proxy Suppliern des Channels die Events.

Sowohl auf der Supplier- als auch auf der Consumer-Seite wird jeweils ein Push Model und ein Pull Model unterstützt. Beim Pull Model erhält der Consumer die Events mittels eines Polling-Mechanismus. Beim Push Model geht die Initiative zur Event-Übermittlung vom Supplier aus.

Der Notification Service enthält als Teilmenge die Interfaces des Event Service. Sollen die Möglichkeiten des Event Filtering und der Quality-of-Service-Konfiguration genutzt werden, müssen jedoch die entsprechenden Interfaces des Notification Service eingesetzt werden.

Proxy Supplier und Proxy Consumer werden von Supplier-Admin-Objekten und Consumer-Admin-Objekten erzeugt. Innerhalb eines Channels können zudem mehrere Supplier-Admin- und Consumer-Admin-Objekte existieren. Es ist nun möglich, Filter- und Quality-of-Service-Parameter für den ganzen Channel, für Admin-Objekte innerhalb eines Channels oder aber für einzelne Proxy-Objekte zu konfigurieren. Hierbei gilt die Regel, daß die Filter- und QoS-Einstellungen, die für ein Admin-Objekt gelten, auch für alle Proxy-Objekte, die von diesem Admin-Objekt erzeugt wurden, Gültigkeit haben. Analog vererben sich auch die Filter- und QoS-Parameter, die auf Channel-Basis gesetzt wurden, auf alle Admin-Objekte, und damit auf die Proxy-Objekte, innerhalb des Channels. Durch die hierdurch resultierende Möglichkeit der hierarchischen Konfiguration wird die Administration der Event Channels erheblich vereinfacht.