5.4.5 Fehlermeldungen aufgrund von Exceptions

Wenn während einem Methodenaufruf auf einem CORBA-Objekt eine Fehlersituation eintritt, erhält der Aufrufer eine Fehlermeldung in Form einer Exception als Rückgabewert. Exceptions sind in IDL definierte Datenstrukturen, die Information über die aufgetretenen Fehler beinhalten.

CORBA unterscheidet zwischen System_Exceptions und User_Exceptions. Erstere zeigen interne Systemfehler des ORBs an, während letztere vom Benutzer objektklassenspezifisch definiert werden können. Die System_Exceptions sind im CORBA-Standard vordefiniert (vgl. [IBM 94f S. 4-25]).

Es wurde ein Verfahren entwickelt, damit beim Auftreten von Exceptions automatisch Ereignismeldungen erzeugt werden, die durch die oben beschriebenen Mechanismen an NetView weitergeleitet werden. Damit kann jede Fehlersituation, die während einem Methodenaufruf auf einem beliebigen Objekt auftritt, von der Plattform registriert werden, wodurch die Grundlage für das Fehlermanagement einer CORBA-Umgebung gegeben ist.

Das entwickelte Verfahren beruht auf folgendem DSOM-spezifischen Mechanismus der Weiterleitung von Methodenaufrufen von Clients an Zielobjekte (vgl. Abb. 5.9):

 

Abbildung 5.9: Die Verarbeitung von Methodenaufrufen bei DSOM

• Ein Client macht einen Methodenaufruf auf einem Proxy-Objekt (oder einen dynamischen Methodenaufruf).
• Der ORB lokalisiert anhand der Objektreferenz den Server, in dem sich das Zielobjekt befindet.
• Beim Server erreicht der Methodenaufruf zunächst den Object Adapter (SOMOA).
• Der SOMOA ermittelt anhand der Objektreferenz, für welches SOM-Objekt der Methodenaufruf bestimmt ist. Dazu ruft er die Methode somdSOMObjectFromRef des SOMDServer-Objekts auf.
• Anschließend ruft der SOMOA die Methode somdDispatchMethod des SOMDServer auf. Die Parameter der Methode sind u.a. das Zielobjekt und der Identifikator der Methode, die auf diesem aufgerufen werden soll.
• Der SOMDServer führt mittels somDispatch den Methodenaufruf auf dem Zielobjekt durch.

Es wurde eine Subklasse von SOMDServer entwickelt, bei der u.a. die Methode somdDispatchMethod überschrieben wurde (vgl. auch Kapitel 6). Jedesmal, wenn ein Methodenaufruf auf einem Zielobjekt durchgeführt wird (mit somDispatch), wird jetzt überprüft, ob bei dem Methodenaufruf eine Exception aufgetreten ist. Wenn ja, wird eine Ereignismeldung an den Event_Dispatcher verschickt, der sie wiederum an die Plattform weiterleitet. Durch Setzen von Filter-Attributen beim Server-Objekt könnte man erreichen, daß nur bestimmte Exceptions Ereignismeldungen bewirken.

Es besteht also grundsätzlich die Möglichkeit, anwendungsspezifische Funktionalität in die Verarbeitung von Methodenaufrufen zu integrieren. Dazu muß nur eine einzelne Methode (somdDispatchMethod des SOMDServer) überschrieben werden.

Dieses Prinzip kann nicht nur für die Fehlerüberwachung eingesetzt werden. Drei weitere Ansätze seien hier genannt:

• Performance Messungen:
  Das Server-Objekt kann die Zeit messen, die es selbst zum Ausführen von somDispatch und der aufgerufenen Methode benötigt. Danach können bei Überschreiten einer kritischen Zeitdauer Ereignismeldungen ausgelöst werden. Schwellwerte können objektspezifisch und methodenspezifisch (durch die methodId) mittels Setzen von Attributen beim Server-Objekt definiert werden.
• Accounting:
  Es kann der Principal jedes Methodenaufrufs überprüft werden. Der Principal ist eine Datenstruktur, die in dem Environment-Parameter von Methodenaufrufen übermittelt wird. Sie enthält den Namen des Rechners und den Namen des Benutzers, der den Methodenaufruf ausgelöst hat. Dadurch ist ein Accounting mit der Granularität einzelner Methodenaufrufe möglich. Die Accounting-Daten können in einer Datei oder in internen Datenstrukturen des Server-Objekts gespeichert und von Clients abgefragt werden.
• Sicherheitsüberprüfungen:
  Das Überprüfen des Principals kann auch dazu genutzt werden, Zugriffsbeschränkungen für einzelne Methoden eines Objekts zu definieren und durchzusetzen. Dabei wird vor dem Aufruf einer Methode mit somDispatch überprüft, ob der in dem Principal angegebene Benutzer Zugriffsrecht auf die Methode des speziellen Objekts hat. Die Zugriffsrechte können zur Laufzeit beim Server-Objekt definiert und geändert werden.

Allerdings ist zu bedenken, daß die Ausführung der eigentlichen Methodenaufrufe um so langsamer werden wird, je größer der ,,Overhead`` durch die integrierte Managementfunktionalität ist. Aus diesem Grund ist es sinnvoll, die zusätzlichen Funktionen durch Setzen von Attributen bei den Server-Objekten ,,an- und ausschaltbar`` zu machen.

Die in diesem Kapitel beschriebenen Mechanismen zur Verarbeitung von CORBA-Ereignismeldungen durch die Managementplattform spielten auch bei der Integration des Topologiemanagements eine Rolle. Es wurden u.a. Komponenten entwickelt, die eine ereignisgesteuerte Aktualisierung von CORBA-Topologiedaten in der Plattformdatenbank ermöglichen. Das nächste Kapitel beschreibt diese Komponenten.