Gründe für den Einsatz von Event-Channels

Der CORBA-Event-Service schreibt die Verwendung von Event-Channel-Objekten nicht vor. Man könnte also Ereignismeldungen direkt ,,an die Plattform`` verschicken. Dennoch ist es aus folgenden Gründen sinnvoll, für das Versenden von Systems-Management-Events einen oder mehrere spezielle Event-Channels zu verwenden:

• Supplier, die Ereignismeldungen verschicken wollen, brauchen nur eine Objektreferenz für den Event-Channel. Sie verschicken alle Ereignismeldungen an den Event-Channel. Es ist transparent für sie, ob die Ereignismeldungen von der Managementplattform oder von anderen Consumern empfangen werden.
• An einen Event-Channel können sich beliebig viele Consumer-Objekte anschließen, um Ereignismeldungen zu empfangen. Auf der Seite der Managementplattform kann es mehrere Consumer für unterschiedliche Event-Arten geben. Es können sich auch Consumer, die zu verschiedenen Managementplattformen gehören, an einen Event-Channel anschließen. Bei der direkten Kommunikation ohne Event-Channel müßte ein Client eine Ereignismeldung an jeden Consumer einzeln verschicken.
• Bei der Kommunikation zwischen Suppliern und dem Event-Channel und zwischen Consumern und dem Event-Channel kann zwischen dem Pull- und dem Push-Modell ausgewählt werden. Es ist z.B. denkbar, daß die Supplier alle Ereignismeldungen durch Push-Methoden an den Event-Channel übertragen. Der Event-Channel leitet aber nur besonders kritische Ereignismeldungen durch Push-Kommunikation an die Plattform weiter. Weniger kritische holt die Plattform sich nur dann aus dem Event-Channel (durch Pull-Methoden), wenn sie freie Verarbeitungskapazität hat.
• Durch entsprechende Implementierung besteht die Möglichkeit, Managementfunktionalität in den Event-Channel zu verlagern. Denkbar ist z.B. eine Event-Channel-Implementierung mit Filter- und Log-Möglichkeiten, um die Plattform bei der Verarbeitung der Events zu entlasten.
• Es kann eine Zuordnung von Event-Channels zu verschiedenen Managementdomänen stattfinden. Beispiele für Domänen können Managementszenarien (Anwendungs-, Netz- oder Systemmanagement), Funktionsbereiche (Konfigurations-, Leistungs- oder Fehlermanagement, etc.) oder geographische Regionen bzw. Verwaltungsbereiche sein. Die vorhandenen Event-Channels können in einem Name-Service registriert sein, um sie für Supplier und Consumer (Managementplattformen oder andere) zugänglich zu machen.

Ein Aspekt, der beim Einsatz von Event-Channel-Objekten zu berücksichtigen ist, besteht in der Zuordnung von Suppliern, Consumern und Event-Channels. Wenn es, wie oben angedeutet, mehrere Event-Channels gibt, könnte z.B. folgendes Szenario auftreten:

Eine Managementanwendung will alle Security-Events aus der Managementdomäne X (z.B. ein bestimmter Verwaltungsbereich) empfangen. An welche Event-Channels muß sie sich ,,anschließen`` um diese Ereignismeldungen zu empfangen ?

Bei der Implementierung wurde dieses Problem dadurch gelöst, daß alle managementrelevanten Ereignismeldungen an einen bestimmten Event-Channel geschickt und von da an die Plattform weitergeleitet werden. Managementanwendungen können sich dann bei der Plattform für den Empfang von bestimmten gefilterten Ereignismeldungen registrieren.

Ein ähnliches Problem tritt auch bei der Zuordnung von Suppliern zu Event-Channels auf. Woher weiß ein Supplier, der Ereignismeldungen an bestimmte Consumer verschicken will, an welchen Event-Channel er sie weiterleiten soll ?

Als Lösungsansatz für diese Problematik kann der Einsatz von Trader-Diensten (vgl. dazu Kapitel 6) dienen. Event-Channels können sich mit einer Beschreibung des von ihnen angebotenen Dienstes (z.B. Namen (Name-Service) der registrierten Supplier und Consumer, unterstützte Ereignismeldungen bei TypedEventChannels , ,,Quality of Service`` etc.) beim Trader registrieren. Supplier und Consumer können dann den Trader nutzen, um die für ihre Anforderungen geeigneten Event-Channels zu finden.