Erweiterung eines CORBA-basierten Event-Management-Dienstes zur Realisierung eines Unified-Messaging-Systems

Transkript

1 Fachhochschule Wiesbaden Fachbereich Informatik Diplomarbeit zur Erlangung des akademischen Grades Diplominformatiker (FH) Erweiterung eines CORBA-basierten Event-Management-Dienstes zur Realisierung eines Unified-Messaging-Systems vorgelegt von Frank Köhler am 27. August 2001 Referent: Prof. Dr. R. Kröger Korreferent: Prof. Dr. K.-O. Linn

2

3 Erklärung Hiermit erkläre ich an Eides statt, daß ich die vorliegende Diplomarbeit selbständig und nur unter Verwendung der angegebenen Hilfsmittel und Literaturquellen verfaßt habe. Taunusstein, Frank Köhler Hiermit erkläre ich mein Einverständnis mit den im folgenden aufgeführten Verbreitungsformen dieser Diplomarbeit: Verbreitungsform ja nein Einstellung der Arbeit in die Bibliothek der FHW Veröffentlichung des Titels der Arbeit im Internet Veröffentlichung der Arbeit im Internet Taunusstein, Frank Köhler

4

5 Inhaltsverzeichnis 1 Einleitung 1 2 Grundlagen Ereignisbasierte Kommunikation Kommunikationsmodell CORBA Event Service Ereigniskanäle Ereignistypen CORBA Notification Service Strukturierte Ereignisse Ereignisfilterung Quality-of-Service-Unterstützung Persistenz Event Management Service des Labors für verteilte Systeme der FH Wiesbaden Ereigniskommunikation Ereignisfilterung Quality-of-Service-Unterstützung Service Monitoring Vorstellung weiterer Kommunikationsmodelle Java Distributed Event Model Das Cambridge Event Model ECO

6 iv Inhaltsverzeichnis JEDI SIENA Unified Messaging Systeme Einleitung Architektur Eigenschaften Medienanbindung Medienkonvertierung Filterung Profilmanagement Sicherheit Persistenz Skalierbarkeit Fehlertoleranz Anwendungsbeispiel Konzept Analyse Anforderungen an das Unified Messaging System Leistungsumfang des Event Management Service Erweiterung des Event Management Service Zusammenfassung Designentscheidungen Zustellgarantie Anbindung von Unified Messaging Sendern und Empfängern Speicherung empfangener Nachrichten Nachrichtenkonvertierung Repositories Entwurf Systemarchitektur

7 Inhaltsverzeichnis v Extended Event Management Service Gateways Konverter Repositories und Resource Management Verbindungspersistenz Neustart und Wiederherstellung der Konfiguration des EMS Objektreferenzen Datenbanktabellen Ereignispersistenz Ereignisformat Ereignistransport Performance-Betrachtungen Datenbanktabellen Neustart des EMS und Wiederherstellung von Ereignisnachrichten Unified Messaging Komponenten Gateways Konverter Repositories Implementierung Implementierungsumgebung Systemplattformen, Compiler und Werkzeuge CORBA-Plattform und Datenbanksystem Der Extended Event Management Service Einführung einer Datenbank-Klasse zur Realisierung der Persistenzeigenschaften Methoden zum Anlegen, Öffnen und Schließen der Datenbank Methoden zum Hinzufügen neuer Datensätze Methoden zum Aktualisieren von Datensätzen

8 vi Inhaltsverzeichnis Methoden zum Lesen von Datensätzen Methoden zum Löschen von Datensätzen Rückgabewerte Verbindungspersistenz Änderungen zur Gewährleistung persistenter Objektreferenzen Änderungen an der Klasse EventChannelFactory Änderungen an der Klasse EventChannel Änderungen an den Klassen SupplierAdmin und ConsumerAdmin Änderungen an den Klassen vom Typ ProxySupplier und ProxyConsumer Änderungen an den Klasse ForwardingFilter und Mapping- Filter Änderungen an der Klasse FilterSlot Änderungen am Hauptprogramm Ereignispersistenz Änderungen an der Klasse EventRec Änderungen an der Klasse EventChannelFactory Änderungen an den Klassen vom Typ ProxyConsumer und ProxySupplier Änderungen am Hauptprogramm Ereigniswiederherstellung Implementierung der Unified Messaging Schicht Gateways Konverter Repositories und Resource Management Performance-Messungen Meßumgebung Ereignistypen Durchsatzmessung

9 Inhaltsverzeichnis vii Bewertung Implementierungsaufwand Extended Event Management Service Unified Messaging Schicht Zusammenfassung Literaturverzeichnis 105 A Berkeley DB Datenbankbibliothek 107 B Die Klasse EMSDatabase 113 C Vollständige Tabellen der Messergebnisse 123

10 viii Inhaltsverzeichnis

11 Abbildungsverzeichnis 2.1 Vergleich von Client/Server und ereignisbasierter Kommunikation Modelle für die ereignisbasierte Kommunikation CORBA Event Channel Architektur CORBA Notification Channel Architektur Aufbau eines strukturierten Ereignisses Architektur des EMS Architektur eines Unified Messaging System Unified Messaging System mit Store and Forward Queue CANBOX Unified Messaging Systemarchitektur Anbindung der Unified Messaging Konverter an den Event Management Service Event Management Service UMS Architektur Entity Relationship Modell der EMS-Objektabhängigkeiten EMS Ereignistransport Ein- und Ausgabeformate des Unified Messaging Systmes Beispiel einer SMTP Verbindung aus Sicht des SMTP Clients EMS Datenbankarchitektur Objekt- und Verbindungswiederherstellung Unified Messaging Converter Architektur UMS Resource Management A.1 Vereinfachte Architektur der Berkeley DB Datenbankbibliothek A.2 Architektur der Berkeley DB Transactional Data Store Datenbankbibliothek 110

12 x Abbildungsverzeichnis

13 Tabellenverzeichnis 2.1 CORBA Notification Service Dienstgüteparameter EMS Constraint-Sprache Attribute für die Datentabelle Event Channel Attribute für die Datentabelle Admin Objects Attribute für die Datentabelle Proxy Objects Attribute für die Datentabelle Filter Objects Attribute für die Datentabelle Filter Mapping Attribute für die Datentabelle Filter Constraints/Rules Übersicht der Ein- bzw. Ausgabeformate des Unified Messaging Systems Attribute für die Datentabelle User Profiles Attribute für die Datentabelle Abonnement Profiles Verwendete generische Ereignisse Verwendete strukturierte Ereignisse generische Ereignisse Messreihe 1: Ereignispersistenz deaktiviert generische Ereignisse Messreihe 2: Ereignispersistenz aktiviert strukturierte Ereignisse Messreihe 1: Ereignispersistenz deaktiviert strukturierte Ereignisse Messreihe 2: Ereignispersistenz aktiviert Implementierungsaufwand - Extended Event Management Service Implementierungsaufwand - Extended Event Management Service C.1 generische Ereignisse Messreihe 1: Ereignispersistenz deaktiviert C.2 generische Ereignisse Messreihe 2: Ereignispersistenz aktiviert C.3 strukturierte Ereignisse Messreihe 1: Ereignispersistenz deaktiviert C.4 strukturierte Ereignisse Messreihe 2: Ereignispersistenz aktiviert

14 xii Tabellenverzeichnis

15 Listings 4.1 Klasse EMSDatabase: Anlegen, Öffnen und Schließen der Datenbank Klasse EMSDatabase: Hinzufügen neuer Datensätze Klasse EMSDatabase: Aktualisieren von Datensätzen Klasse EMSDatabase: Lesen von Datensätzen Klasse EMSDatabase: Löschen von Datensätzen Ausschnitt aus dem Programm EMSServer.cc Ausschnitt aus der Klasse EventChannel Ausschnitt aus der Klasse EventChannelFactory - Channel-Wiederherstellung Ausschnitt aus der Klasse EventChannelFactory - Filter-Wiederherstellung Ausschnitt aus der Klasse EventChannel - Löschen eines Ereigniskanals Ausschnitt aus der Klasse SupplierAdmin - Einfügen eines Admins Ausschnitt aus der Klasse SupplierAdmin - Löschen eines Admins Ausschnitt aus der Klasse SupplierAdmin - Wiederherstellen von Proxy- Objekten Ausschnitt aus der Klasse ProxyPullSupplier - Verbinden eines Consumers Ausschnitt aus der Klasse ForwardingFilter - Constraint löschen Ausschnitt aus der Klasse FilterSlot - Filter löschen Ausschnitt aus der Klasse FilterSlot - Filter wiederherstellen Ausschnitt aus der Klasse EventRec Ausschnitt aus der Klasse EventChannelFactory - globale Optionen Ausschnitte aus den ProxyConsumer Klassen - Ereignisempfang Ausschnitte aus den ProxySupplier Klassen - Ereigniszustellung Ausschnitt aus der Klasse StructuredProxyPushConsumer - Ereigniswiederherstellung

16 xiv Listings 4.23 Versand einer Ereignisnachricht Empfang einer Ereignisnachricht im Konverter Konvertierung einer Ereignisnachricht IDL-Beschreibung der Resource Management Komponente B.1 EMSDatabase - Datenbank Anlegen, Öffnen oder Schließen B.2 EMSDatabase - Datensätze hinzufügen B.3 EMSDatabase - Datensätze aktualisieren B.4 EMSDatabase - Datensätze lesen B.5 EMSDatabase - Datensätze löschen

17 Kapitel 1 Einleitung Die wachsende Konvergenz zwischen Telefonnetzen, Datennetzen und mobilen Netzen führt zu der zentralen Vision, Informationen zu jeder Zeit, an jedem Ort und in beliebiger Form empfangen zu können. Diese Vision bildet die Grundlage für eines der größten Anwendungsgebiete der Informatik. Seit einigen Jahren beschäftigen sich Forschungs- und Entwicklungseinrichtungen mit dem Problem der nahtlosen Integration einzelner Kommunikationssysteme in eine vom Trägermedium abstrahierten Kommunikationsumgebung für mobile Benutzer. Ein Teilbereich dieser Forschungsaktivitäten wird heute unter dem Begriff Unified Messaging zusammengefaßt. Ein Unified Messaging System (UMS) soll die Produktivität eines Benutzers dadurch steigern, daß die bisherige, in der Regel aus verschiedenen Applikationen bestehende Infrastruktur des Benutzers durch eine Kommunikationsumgebung ersetzt wird, die alle Nachrichtentypen empfängt und diese an einem logisch zentralen Ort zur Verfügung hält. Eine solche, in der Regel auf Internet-Protokollen basierende Umgebung soll es dem Benutzer ermöglichen, unabhängig von seinem Aufenthaltsort und dem gerade zur Verfügung stehenden Kommunikations-Endgerät auf seine Nachrichten zugreifen zu können. Hierbei kann es sich zum Beispiel um eine Web-Applikation, ein Telefon, ein Faxgerät oder einen PDA (Personal Digital Assistant) handeln. Eine notwendige Voraussetzung für die Integration verschiedener Kommunikationssysteme ist die Modularität in Hinblick auf Austauschbarkeit und Erweiterbarkeit von Komponenten, d.h. die Vereinheitlichung von Interfaces auf verschiedenen Ebenen (extern und intern). Hierfür wird eine Integrationsplattform benötigt, die möglichst skalierbar ist und sowohl eine Implementierung des Systems auf einem einzelnen Rechner als auch auf einem verteilten System mit unterschiedlichen Betriebssystemplattformen ermöglicht. Eine solche, auf der Basis verteilter Objekttechnologien basierende Integrationsplattform ist die Common Object Request Broker Architecture (CORBA) der Objekt Management Group (OMG).

18 2 Einleitung Ein wesentlicher Aspekt einer solchen Integrationsplattform sind die zugrundeliegenden Kommunikationsprinzipien, die nach verschiedenen Eigenschaften klassifiziert werden können. Ein Klassifikationsmerkmal ist zum Beispiel die Unterscheidung zwischen Punktzu-Punkt-Kommunikation und Gruppenkommunikation. Neben der im CORBA-Standard definierten synchronen Punkt-zu-Punkt-Kommunikation wird für die Realisierung eines Unified Messaging Systems eine asynchrone Gruppenkommunikation benötigt. Im Rahmen der Common Object Services Specification (COSS) wurde hierfür der standardisierte CORBA Event Service entworfen. Dieser enthält bereits die grundlegenden Konzepte und Schnittstellen zur ereignisbasierten asynchronen Kommunikation zwischen Mengen anonymer Erzeuger und Konsumenten in verteilten Systemen. Auf den Schnittstellen des COR- BA Event Service wurde später der CORBA Notification Service aufgebaut. Dieser stellt eine Erweiterung des CORBA Event Service um Merkmale wie strukturierte Ereignisse, Ereignisfilterung und Quality-of-Service-Unterstützung dar. Im Labor für Verteilte Systeme der FH Wiesbaden wurde im Rahmen der Diplomarbeit [Bro98] von Erik Broßler ein Event Management Service (EMS) entwickelt, der ebenfalls auf den Schnittstellen des CORBA Event Service aufsetzt und als Ereignisform generische Ereignisnachrichten unterstützt. Unter Berücksichtigung der damals existierenden Entwürfe für den CORBA Notification Service wurde die Funktionalität gegenüber dem CORBA Event Service entscheidend erweitert. Neben der Einführung von Prioritäten und Lebenszeiten wurden auch die Konzepte zur Filterung von Ereignissen übernommen. Durch die gemeinsame Nutzung von Filterpunkten an Administrationsobjekten, die eine Gruppierung der Erzeuger und Konsumenten erlauben, wurde die interne Struktur des Dienstes optimiert. Im Rahmen der Diplomarbeit [Mac00] von Holger Machens wurde ein Redesign des Event Management Service zur Anpassung an die Bedürfnisse einer Automatisierungsumgebung durchgeführt. Um eine möglichst schnelle Nachrichtenvermittlung zu gewährleisten, wurde der Dienst zusätzlich um die im CORBA Notification Service spezifizierten strukturierten Ereignisse erweitert. Das primäre Ziel dieser Diplomarbeit ist die Erweiterung des im Labor für Verteilte Systeme der FH Wiesbaden entwickelten Event Management Service zur Realisierung eines Unified Messaging Systems. Die durch die Architektur eines Unified Messaging Systems gestellten Anforderungen an den Event Management Service werden hierbei im Vordergrund stehen. Eine Kernforderung in diesem Zusammenhang ist die Gewährleistung von Zustellgarantien für zu empfangende Ereignisnachrichten, da diese für die Realisierung eines solchen Systems von essentieller Bedeutung sind. Ausgehend von dieser Forderung wurden dazu im CORBA Notification Service die Eigenschaften der Verbindungspersistenz und der Ereignispersistenz spezifiziert. Der grundlegende Ansatz dieser Arbeit besteht darin, eine zweischichtige Systemarchitektur für die Realisierung des Unified Messaging Systems auf der Basis des Event Management Service vorzusehen.

19 3 Das funktionale Ziel der unteren Schicht ist ein erweiterter Event Management Service (Extended Event Management Service, EEMS), der den existierenden EMS um die Eigenschaften der Verbindungs- und Ereignispersistenz ergänzt. Nach einer Analyse des Leistungsumfangs der aktuellen Version des Event Management Service in Hinblick auf die Realisierung eines Unified Messagig Systems werden die Anforderungen für die Gewährleistung von Zustellgarantien betrachtet. In diesem Zusammenhang werden insbesondere die entsprechenden Spezifikationen des CORBA Notification Service untersucht, um die CORBA-Kompatibilität auch bei Erweiterung des Dienstes zu erhalten. Anschließend werden verschiedene Verfahren zur persistenten Datensicherung vorgestellt und diskutiert. Aus den gewonnenen Ergebnissen wird die Architektur des Extended Event Management Service (EEMS) entworfen und implementiert. Dieser bildet die Grundlage für das zu entwickelnde Unified Messaging System. Daran anschließend erfolgt in einem zweiten Schritt die Realisierung des Unified Messaging Systems auf der Basis des Extended Event Management Service. Dazu erfolgt die exemplarische Entwicklung relevanter Komponenten eines Unified Messaging Systems. Hierbei handelt es sich beispielsweise um Gateways für den Nachrichtenempfang bzw. Nachrichtenversand und Module für die Konvertierung der verschiedenen Nachrichtenformate. Alle diese Komponenten werden in Form von Konsumenten bzw. Erzeugern des Extended Event Management Service entwickelt. Zusätzlich werden die Unified Messaging Gateways mit einer Schnittstelle zu einer Resource Management Komponente versehen. Diese Schnittstelle ermöglicht eine Abfrage von benutzerspezifischen Daten (wie zum Beispiel Adressen des Unified Messaging Benutzers). Die Konsumenten bzw. Erzeuger, die innerhalb des Systems als Gateway oder Konverter dienen, werden ebenfalls um die bereits beschriebenen Persistenzeigenschaften erweitert. Nach dieser Einführung beschreibt Kapitel 2 die für das Verständnis der Arbeit notwendigen Grundlagen. Abschnitt gibt zunächst eine Einführung in die klassischen Kommunikationsmodelle verteilter Anwendungen. Dabei werden insbesondere die Unterschiede der klassischen Client/Server-Kommunikation und der ereignisbasierten Kommunikation betrachtet. Abschnitt befaßt sich mit dem CORBA Event Service, der die COR- BA Architektur um Schnittstellen zur ereignisbasierten asynchronen Kommunikation erweitert. Eine Vorstellung des CORBA Notification Service mit seinen Eigenschaften der Verbindunspersistenz und Ereignispersistenz erfolgt in Abschnitt In Abschnitt wird die aktuelle Version des Event Management Service des Labors für Verteilte System der FH-Wiesbaden beschrieben. Abgeschlossen wird das Kapitel 2 mit einer kurzen Betrachtung weiterer Kommunikationsmodelle. In Kapitel 3 werden die im Rahmen dieser Arbeit entwickelten Konzepte für die Erweiterung des Event Management Service und deren Integration in eine Unified Messaging Architektur dargestellt. Abschnitt 3.1 faßt zunächst die Anforderungen an ein Unified Messaging System und die daraus resultierenden Anforderungen für die Modifikation und

20 4 Einleitung Erweiterung des Event Management Service zusammen. In Abschnitt 3.2 werden verschiedene Entwurfsalternativen diskutiert. Die konkrete Architektur des Unified Messaging Systems und die Realisierung der Verbindungspersistenz und Ereignispersistenz wird in Abschnitt 3.3 vorgestellt. Die Umsetzung des Konzepts wird in Kapitel 4 besprochen. Abschnitt 4.1 beschreibt zunächst die Implementierungsumgebung. Die zwei folgenden Abschnitte befassen sich mit den konkreten Implementierungsdetails. In diesen Abschnitten werden die Modifikationen für die Erweiterung des Event Management Service um die Eigenschaften der Verbindungspersistenz bzw. Ereignispersistenz und die Implementation der Unified Messaging Komponenten vorgestellt. Die im Rahmen der Diplomarbeit erreichten Ergebnisse werden in Kapitel 5 zusammengefaßt und bewertet. Darüber hinaus werden Empfehlungen für Verbesserungen und Erweiterungen des Event Management Service aufgezeigt.

21 Kapitel 2 Grundlagen Das Kapitel Grundlagen soll die Konzepte und Techniken vermitteln, die für das Verständnis dieser Arbeit notwendig sind. Im ersten Abschnitt erfolgt eine Einführung in die Grundlagen der ereignisbasierten Kommunikation. In diesem Zusammenhang werden der CORBA Event Service und der CORBA Notification Service näher erläutert. Abschließend erfolgt eine Einführung in die Architektur des Event Management Dienstes des Labors für Verteilte Systeme der FH Wiesbaden. Der zweite Abschnitt gibt einen Einblick in die Architektur eines Unified Messaging Systems und betrachtet die für den Betrieb notwendigen Eigenschaften. 2.1 Ereignisbasierte Kommunikation Kommunikationsmodell Das klassische Kommunikationsmodell in verteilten Anwendungen basiert auf der, in Abbildung 2.1 dargestellten, Client/Server-Architektur. In diesem Modell wird innerhalb eines Servers ein Dienst bereitgestellt, der von einem oder mehreren Clients über ein zuvor definiertes Interface aufgerufen werden kann. Die Kommunikation zwischen Client und Server erfolgt in der Regel über eine synchrone Punkt-zu-Punkt Verbindung. Ein Beispiel für eine Client/Server-Kommunikation ist ein Abbildung 2.1 dargestellt. Eine Client ruft einen Dienst des Servers auf (Request) und blockiert dann so lange, bis er die Rückgabe der aufgerufenen Funktion erhält (Response). In großen verteilten Systemen stößt dieses Modell schnell an seine Grenzen, da durch den Versand der Empfangsbestätigungen eine nicht unerhebliche Netzlast erzeugt wird. Im Gegensatz zum Client/Server-Modell ermöglicht die ereignisbasierte Kommunikation eine Entkopplung von Aufrufer (Caller) und Aufgerufenem (Callee) und stellt damit ein asynchrones Kommunikationsmodell bereit. In diesem Modell wird für den Aufgerufenen

22 6 Grundlagen Server Event Consumer Event Consumer Event Consumer Request Response Client Client/Server Kommunikation Event Supplier ereignisbasierte Kommunikation Abbildung 2.1: Vergleich von Client/Server und ereignisbasierter Kommunikation die Rolle des Erzeugers (Supplier) und für den Aufrufenden die Rolle des Konsumenten (Consumer) eingeführt. Ein Kommunikationsbeispiel ist in Abbildung 2.1 dargestellt. Der Supplier generiert ein Ereignis und stellt dieses einem einzelnen Konsumenten oder einer Gruppe von Konsumenten zu. Hierbei hat der Supplier in der Regel keine Information über die Postion und die Anzahl der Consumer. Die Zustellung von Ereignissen kann nach den, in Abbildung 2.2 dargestellten Ansätzen erfolgen. Push Supplier push Push Consumer Pull Supplier pull Pull Consumer Push-Modell Pull-Modell Abbildung 2.2: Modelle für die ereignisbasierte Kommunikation 1. Nach dem Push-Modell erfolgt bei Vorliegen eines Ereignisses eine Benachrichtigung vom Supplier zum Consumer. Der Supplier verhält sich in diesem Fall aktiv, der Consumer passiv. 2. Das Pull-Modell sieht ein kontinuierliches Ereignis-Polling des Consumers vor. Der Consumer verhält sich in diesem Fall aktiv, der Supplier passiv. Durch die Definition unterschiedlicher Interfaces für jede Kombination von Kommunikationsmodell und Rolle wird eine Verbindung zwischen Supplier und Consumer unterschiedlichen Kommunikationstyps verhindert.

23 2.1 Ereignisbasierte Kommunikation CORBA Event Service Der CORBA Event Service [Obj01] wurde mit dem in Abschnitt beschriebenen Ziel der Entkopplung von Aufrufer und Aufgerufenem entwickelt. Die Kommunikation zwischen dem Supplier und dem Consumer erfolgt über die standardisierten CORBA-Aufrufe Ereigniskanäle Das im Abschnitt vorgestellte Modell erlaubt zwar die Kommunikation zwischen einem Supplier und einem Consumer, es ist aber nicht möglich, ein Ereignis an mehr als einen Consumer zu senden. Zu diesem Zweck wurde das Konzept des Ereigniskanals (Event Channel) eingeführt. Er dient als Bindeglied zwischen einer Anzahl von Erzeugern und Konsumenten und ist somit das zentrale Objekt eines Event Service. Ein Ereigniskanal ermöglicht die anonyme Kommunikation einer beliebigen Anzahl von Erzeugern mit einer beliebegen Anzahl von Konsumenten. Hierzu werden die Meldungen von den Erzeugern in den Ereigniskanal eingespeist und von den Konsumenten auf der entgegengesetzten Seite entnommen. Consumer Side Supplier Side Event Consumer Proxy Supplier Consumer Admin Event Channel Supplier Admin Proxy Consumer Event Supplier Event Consumer Proxy Supplier Abbildung 2.3: CORBA Event Channel Architektur Die Event Channel Architektur ist in Abbildung 2.3 dargestellt. Jeder Ereigniskanal enthält zwei Administrationsobjekte (Consumer Admin und Supplier Admin), die zur Generierung und Installation der Proxy-Objekte für Erzeuger und Konsumenten benötigt werden. Diese Proxy-Objekte werden benötigt, um den Kommunikationspartnern die gewohnte Schnittstelle zum Versand und Empfang von Ereignissen bereitzustellen. Die Kommunikation mit den Proxy-Objekten kann sowohl über das Pull-Modell, als auch über das Push-Modell erfolgen. Auf Empfängerseite übernehmen die Objekte ProxyPushSupplier und ProxyPullSupplier die aktive bzw. passive Zustellung von Ereignissen. Die Aufgabe des aktiven bzw. passiven Konsumenten auf Empfängerseite übernehmen die Objekte ProxyPullConsumer und ProxyPushConsumer.

24 8 Grundlagen Für die Kommunikation über einen Ereigniskanal muß keine Festlegung auf ein bestimmtes Modell erfolgen, da auch Mischformen unterstützt werden. Beispielsweise kann die von einem ProxyPullConsumer empfangene Ereignismeldung auch einem ProxyPushSupplier zugestellt werden, der seinerseits die Meldung an den Push Consumer weitergibt Ereignistypen Mit dem Event Service wurden zwei verschiedene Ereignistypen eingeführt: 1. Generic Events können eine beliebige Datenstruktur vom Datentyp Any enhalten. 2. Typed Events stellen ein zuvor definiertes Interface bereit. Dieses Interface kann mittels der IDL beschrieben werden. Bei der Definition der Schnittstelle gelten die gleichen Einschränkungen wie bei CORBA Oneway-Calls. Zusätzlich müssen die mittels der IDL beschriebenen Interfaces je nach Rolle und Kommmunikationsmodell über eine Methode verfügen, die nach der Push- oder Pull-Semantik arbeitet. Wird ein Ereigniskanal vom Typ Generic angelegt, so können durch diesen nur Ereignisse des gleichen Typs versendet werden. Ein Ereigniskanal vom Typ Typed unterstützt die Ereignisarten Generic und Typed CORBA Notification Service Der CORBA Notification Service [Obj00] wurde auf der Schnittstelle des CORBA Event Service aufgebaut und ergänzt diesen um Merkmale wie strukturierte Ereignisse, Ereignisfilterung und Quality-of-Service-Unterstützung. Die Architektur des Notification Channels ist in Abbildung 2.4 dargestellt. Wie aus Abbildung 2.4 ersichtlich, wurden die im Event Service existierenden Beschränkungen bezüglich der Anzahl der Administrationsobjekte aufgehoben Strukturierte Ereignisse Mit dem CORBA Notification Service wurden die sogenannten strukturierten Ereignisse eingeführt. Gegenüber den vom CORBA Event Service bekannten Typed Events zeichnen sich diese durch eine vereinfachte Handhabung aus. Strukturierte Ereignisse ermöglichen die direkte Abbildung von Ereignissen auf eine zuvor definierte Datenstruktur. Durch neu eingeführte Supplier und Consumer Interfaces ist es nicht mehr notwendig, die Daten in einem Any-Datentyp zu kapseln. Strukturierte Ereignisse können dadurch direkt an den oder die Konsumenten zugestellt werden.

25 2.1 Ereignisbasierte Kommunikation 9 Consumer Side Supplier Side Event Consumer Proxy Supplier Consumer Admin Supplier Admin Proxy Consumer Event Supplier Event Consumer Proxy Supplier Notification Channel Proxy Consumer Event Supplier Event Consumer Proxy Supplier Consumer Admin Supplier Admin Proxy Consumer Event Supplier Event Consumer Proxy Supplier Proxy Consumer Event Supplier Abbildung 2.4: CORBA Notification Channel Architektur domain_name type_name Fixed Header Event Header ohf_name ohf_name ohf_name event_name 1 2 n... ohf_value ohf_value ohf_value 1 2 n Variable Header fd_name 1 fd_value 1 Event Body fd_name 2... fd_value 2 Filterable Body Fields fd_name n fd_value n remainder_of_body Remaining Body Abbildung 2.5: Aufbau eines strukturierten Ereignisses