Ereignismeldungen als Objekte

Der Unterschied der beiden Modellierungsarten sei am folgenden Beispiel verdeutlicht. Es handelt sich um eine Ereignismeldung, die das Erzeugen eines Objekts in einem Server anzeigt:

interface object_created : generic_event {
  attribute string server_id;
  attribute string object_reference;
  attribute string object_class;

  void notify(..., 
   in string server_id,
   in string object_reference,
   in string object_class);
};

Die Klasse object_created ist eine Unterklasse von generic_event und erbt von dieser die allgemeinen Attribute einer Ereignismeldung wie z.B. Event-Name, Zeitpunkt, Name des Quell-Rechners, etc. Diese werden um weitere spezifische Attribute ergänzt: der Implementation-Repository-Identifikator des Servers, die Objektreferenz des neu erzeugten Objekts und der Name seiner Klasse.

In der Implementierung der Methode notify erfolgt die Verarbeitung der Ereignismeldung. Die Parameter der Methode entsprechen den Attributen der Event-Klasse (geerbte und eigene Attribute).

Bei diesem Modell erfolgt das Versenden einer Ereignismeldung (Push-Modell) in folgenden Schritten:

• Der Client, der die Ereignismeldung versenden will (beim obigen Beispiel das Server-Objekt, das das neue Objekt erzeugt hat), erhält eine Referenz (ein Proxy-Objekt) auf ein Objekt der Event-Klasse object_created (z.B von einem Event-Channel).
• Der Client ruft die Methode notify auf mit den entsprechenden Parametern.
• Die Implementierung der notify-Methode verarbeitet die Ereignismeldung.

Die Instanz der Event-Klasse ist in diesem Fall das TypedConsumer-Interface. Der Vorteil der Modellierung von Ereignismeldungen als Objektklassen besteht darin, daß eine Vererbungshierarchie (Vererbung der Attribute und Überschreiben der notify-Methode) aufgebaut werden kann.