Der Notification Service

  Der Notification Service ist eine Erweiterung des Event Service, auf den im vorigen Kapitel eingegangen wurde. An dieser Erweiterung, die noch nicht standardisiert ist, haben sich eine Reihe von Firmen beteiligt. Einige der bekannteren sind unter anderem Borland International, Fujitsu Limited, NEC Corporation und IBM. Die vorliegende Joint Revised Revision [OMG98] sieht folgende Erweiterungen vor:

• Die Möglichkeit, Ereignisse in Form einer wohldefinierten, festgelegten Datenstruktur zu senden. (Der Event Channel bietet im Gegensatz dazu nur den CORBA Any-Datentyp an.)
• Die Clients können selbst genau festlegen, welche Ereignisse sie empfangen wollen. Ermöglicht wird dies durch Filtereinstellungen am Proxy Supplier.
• Die Supplier sind nun in der Lage festzustellen, welche Consumer sich an den Event Channel gebunden haben und welche Event-Typen von diesen angefordert werden. Supplier können somit Events auf Abfrage liefern oder das Verschicken von Events unterlassen, an denen kein Consumer Interesse hat.
• Die Consumer ihrerseits können feststellen, welche Event-Typen von den Suppliern an den Event Channel offeriert werden und so bei Bedarf neue Events ,,abonnieren``.
• Die Möglichkeit, sogenannte Quality of Service-Parameter (QoS) auf Basis des Event Channels, der Proxy-Objekte als auch auf Basis der Events zu definieren. Ein QoS-Paramter ist bspw. die Verlässlichkeit (reliability) der Verbindung, die den Transport der Ereignismeldungen zwischen Client und Server garantiert.
• Das Bereitstellen eines optionalen Event Type Repository mit dessen Hilfe es dem Benutzer erleichtert wird, Filtereinstellungen auf Basis der zur Verfügung gestellten Informationen über die Ereignisstruktur zu tätigen.

Im Rahmen dieser Arbeit soll die Betrachtung der wohldefinierten Datenstruktur der Ereignisse des Notification Service im Mittelpunkt stehen. Grund hierfür ist, daß es einerseits noch keine Implementierung des Notification Service gibt und andererseits der Notification Service dem Event Service sehr ähnlich ist. Weitergehende Unterschiede und nähere Information zu diesen kann in der Spezifikation zum Notification Service [OMG98] nachgeschlagen werden.

Der CORBA Event Service unterstützt zwei Arten der Eventkommunikation: typisierte und untypisierte Events. Letzterer wurden schon im vorigen Kapitel angesprochen und stellen die sogennannten Any-Datentypen dar, die leicht zu implementieren sind. Viele Anwendungen brauchen hingegen strenger typisierte Ereignismeldungen. Der OMG Event Service definiert gewisse Schnittstellen und Konventionen für typisierte Ereignismeldungen.

Aus diesem Grund bietet der Notification Service eine wohldefinierte Event-Datenstruktur, der als Structured Event bezeichnet wird. Im Gegensatz zum Event Service ist es nicht mehr nötig, dieses Konstrukt in eine Any-Datenstruktur umzuwandeln, bevor es an den Event Channel geschickt wird. Leider zwingt uns jedoch das Fehlen einer Implementation des Notification Service noch zu dieser Datenkonvertierung.

  

Abbildung 2.16: Aufbau des Structured Events

Der Aufbau des Structured Event, wie er in Abbildung 2.16 zu betrachten ist, besteht aus zwei Hauptbestandteilen:

Der Event Header

wird aufgeteilt in einen festen (fixed header) und einen variablen (variable header) Teil. Der Vorteil dieser Zerlegung liegt in der Minimierung der Headerinformation, die bei jedem Structured Event benötigt wird und somit der Vermeidung von überflüssigem Overhead.

Der Fixed Header besteht aus drei Feldern vom Typ String: dem domain_type, event_type und event_name. Der domain_type bezeichnet die vertikale Industriezugehörigkeit und kann Werte wie beispielsweise Telekommunikation, Finanz- oder Gesundheitswesen annehmen. Der event_type spezifiziert den Typ der Ereignismeldung und wird somit sinnvollerweise mit Werten wie etwa AgentUp oder AgentDown belegt. Das event_name-Feld identifiziert die Instanz des Events eindeutig.

Der variable Teil setzt sich aus Null oder mehreren Bezeichnern (ohf_name) und deren Wertebelegung (ohf_value) zusammen. Die Bezeichner sind hierbei vom Datentyp String und die Wertebelegung vom CORBA-Datentyp Any.

Der Event Body

ist ebenfalls zweigeteilt. Der filterable body soll die wichtigeren Felder des Ereignisses enthalten. Er ist so angeordnet, daß er es den Consumern erlaubt, Filtereinstellungen vorzunehmen. Gleich dem optional header field teilt sich der filterable body in ein Attributfeld vom Datentyp String (fd_name) und einer Wertbelegung vom Datentyp Any (fd_value) auf.

Der letzte Teil des Body's eines Structured Events, der remainder_of_body, ist vom Datentyp Any. Vorgesehen ist dieses Feld für Daten, die sich aufgrund ihrer Größe nicht zum Filtern eignen oder nicht wichtig genug sind, um sie wohlstrukturiert auszugeben, dem Consumer aber nicht vorenthalten werden sollen. Denkbar ist hier die Ausgabe von Fehlermeldungen bzw. core-Files, die Informationen über einen möglichen Programmabsturz liefern.

Um die Vorteile der wohldefinierten Datenstrukturen nutzen zu können und spätere Portierungen vom Event Channel-Konzept zum Notification Service-Konzept möglichst einfach zu gestalten, werden alle Events in ein Structured Event verpackt. So kann ein später hinzukommender Notification Service diese wohldefinierte Datenstruktur weiter verwenden, ohne Supplier und Consumer noch an den Notification Service anpassen zu müssen. Gleichwohl können dann die Filtermöglichkeiten des Notification Service sofort genutzt werden.