Event Service Demo

Download: swb.zip (18.04.1999, 167 KByte)

CORBA-Anwendungen arbeiten normalerweise mit synchronen Methodenaufrufen. Dabei wartet der Client solange, bis eine Server-Methode mit der Verarbeitung fertig ist. Im Fall eines Kommunikations- oder Programmfehlers wird der Aufrufer benachrichtigt. Um zu verhindern, daß ein Client-Programm für die Dauer eines Methodenaufrufs blockiert wird, kann man oneway oder deferred-synchrone Aufrufe verwenden. Bei oneway-Kommunikation bekommt der Sender eines Ereignisses keine Rückmeldung vom Empfänger und hat somit keine Garantie, daß die Daten wirklich angekommen sind und verarbeitet wurden. Den goldenen Mittelweg zwischen oneway und synchronen Aufrufen stellt deferred (engl. aufgeschoben)-synchrone Kommunikation dar. Das Client-Programm verschickt einen Aufruf und kann sofort mit der Verarbeitung fortfahren. Zu einem späteren Zeitpunkt läßt sich jedoch überprüfen, ob der Aufruf erfolgreich durchgeführt wurde.

Bei allen der genannten Kommunikationsmodi gibt es jeweils nur einen Sender (Client) und einen Empfänger (Server-Objekt). Außerdem wählt der Aufrufer den Empfänger aus. Nachrichten beziehungsweise Ereignisse werden nicht zwischengepuffert. Ist der Empfänger gerade nicht verfügbar, geht das Ereignis »verloren«. Manche Anwendungen benötigen aber eine n:m-Kommunikation, bei der es mehrere Sender sowie mehrere Empfänger gibt. Dabei sollte der einzelne Sender nicht unbedingt alle Empfänger kennen. Wünschenswert wäre auch, daß Ereignisse nicht sofort gelöscht werden, sondern auch Empfänger, die sich später »dazuschalten«, erreichen.

Prinzipiell kann der Event Service der OMG diese Forderungen erfüllen. Dieser Dienst definiert jedoch keine neue Kommunikationsart sondern benutzt abhängig von der Implementierung einen oder mehrere der obigen Aufrufmodi. Vom Aufbau her stellt der Event Service eine Netzwerkvariante des Observer-Musters dar. Sender und Empfänger sind nicht direkt aneinander gekoppelt. Der asynchrone Datenaustausch wird vielmehr durch eine Zwischeninstanz, einen Event Channel ermöglicht. Dieser empfängt die Daten von den Sendern und leitet sie - eventuell zeitlich versetzt - an die angeschlossenen Empfänger weiter. Gemäß der Event Service-Spezifikation werden Sender Supplier und Empfänger Consumer genannt.

Es gibt zwei Arten von Suppliern und Consumern, sogenannte PushSupplier und PushConsumer sowie PullSupplier und PullConsumer. Im Sinne von CORBA sind PushSupplier Clients, die Daten automatisch zum Event Channel »schieben«. Der Channel übernimmt in diesem Fall die Rolle eines Servers. Beim Weiterleiten der Daten an die PushConsumer fungiert der Ereigniskanal dagegen als Client. Genau umgekehrt funktioniert die Pull-Variante. PullConsumer sind Clients, die von Zeit zur Zeit den Event Channel nach neuen Ereignissen »befragen«. Im Gegenzug führt der Channel Aufrufe auf den PullSuppliern durch, wobei nicht definiert ist, zu welchem Zeitpunkt diese Aufrufe erfolgen sollen. Hinsichtlich der Skalierbarkeit, der Filterung oder der Geschwindigkeit beim Versenden der Ereignisse legt sich die OMG ebensowenig fest. Die Tatsache, daß jede Implementierung andere Leistungsmerkmale besitzen kann, wird als Quality of Service (QoS) bezeichnet. Somit legt die Spezifikation nur die grundlegenden Interfaces fest, was angesichts unterschiedlicher Anwendungsgebiete durchaus sinnvoll ist.



Anhand eines Shared Whiteboards, mit dem mehrere Benutzer gleichzeitig an einer Grafik arbeiten können, möchten wir die Push-Variante eines Event Services zeigen. Änderungen, die ein Benutzer an einem Bild vornimmt, werden sofort allen anderen Benutzern mitgeteilt und die Bilder auf deren Rechnern aktualisiert.

Um das Shared Whiteboard auszuprobieren, startet man zuerst das Programm »SWBChannel« im gleichnamigen Unterverzeichnis. Dieses Programm erzeugt ein neues EventChannel-Objekt und schreibt dessen IOR in die Datei »SWBChannel.ior«. Die eigentliche Implementierung des Shared Whiteboards enthält das Unterverzeichnis »SWBApp«. Der CORBA-spezifische Code steckt in der Datei »SWBApp.java«. Das Programm liest die IOR des EventChannel-Objekts und registriert sich beim Channel sowohl als PushSupplier als auch als PushConsumer.

   
   

© 1997-2007 Entrance Software GmbH