Next: Lösungskonzept
Up: 5.2 Der CORBA-Event-Service
Previous: 5.2.2 Event-Channels
Zusätzlich zur Differenzierung zwischen Push- und Pull-Modell wird beim CORBA-Event-Service zwischen generischer und typisierter Kommunikation von Ereignismeldungen unterschieden.
Bei der generischen Kommunikation haben die Push- und Pull-Methoden der Supplier- bzw. Consumer-Objekte jeweils nur einen Parameter vom Datentyp any, in dem alle Daten der Ereignismeldung verpackt werden.
Bei der typisierten Event-Kommunikation erfolgt die Übermittlung von Ereignismeldungen durch Methodenaufrufe auf Objekten, die eine ,,anwendungsspezifische`` IDL-Definition haben können
. Für die Methoden dieser Objekte werden folgende Beschränkungen gefordert (vgl. [OMG 93c S. 17f.]):
- TypedConsumer:
- es sind nur in-Parameter zulässig
- es sind keine Rückgabewerte erlaubt
- TypedSupplier:
Ein TypedSupplier-Interface wird aus einem bestehenden TypedConsumer-Interface erzeugt. Dabei werden folgende Abwandlungen der Methoden vorgenommen:
- Für jede Methode X wird eine Methode pull_X definiert, bei der alle in-Parameter in out-Parameter umgewandelt werden.
- Für jede Methode X wird eine Methode try_X definiert, bei der alle in-Parameter in out-Parameter umgewandelt werden, und die entweder true oder false als Rückgabewert hat, je nachdem, ob der Supplier eine Ereignismeldung vorrätig hat oder nicht.
Die Übermittlung von Ereignismeldungen erfolgt durch den Aufruf der Methoden, die die Objekte zur Verfügung stellen.
Die Zuordnung zwischen Suppliern und Consumern ist bei der typisierten Kommunikation komplizierter als bei der generischen. Folgende Schritte sind z.B. für die Registrierung eines PullConsumers bei einem TypedEventChannel nötig (vgl. Abb. 5.3):
Abbildung 5.3:
Registrierung bei einem TypedEventChannel
 |
- Der PullConsumer ruft die Methode for_consumers des TypedEventChannel auf und erhält daraufhin eine Referenz auf ein Objekt der Klasse TypedConsumerAdmin.
- Auf diesem Objekt ruft er dann die Methode obtain_typed_pull_supplier auf. Diese Methode hat einen Parameter supported_interface vom IDL-Typ Key. Über diesen Parameter gibt der Consumer die gewünschte Aufrufschnittstelle des TypedProxyPullSuppliers an, dessen Referenz er durch den Methodenaufruf erhält.
- Durch Aufruf der Methode get_typed_supplier des TypedProxyPullSupplier erhält der PullConsumer eine Referenz auf ein Objekt, auf dem er die entsprechenden pull-Methoden für die Übermittlung der Ereignismeldungen aufrufen kann.
Next: Lösungskonzept
Up: 5.2 Der CORBA-Event-Service
Previous: 5.2.2 Event-Channels
Copyright Munich Network Management Team