Kommunikationsmodell

 

Im Gegensatz zu anderen Managementarchitekturen erfordert CORBA kein dediziertes Managementprotokoll, da hier Objekte durch das wechselseitige Aufrufen von Methoden interagieren. Ein Managementagent besteht in CORBA grundsätzlich aus jeweils individuellen Objekten, die per se weder über eine Enthaltenseinshierarchie verfügen, noch über hierarchische Namen. Kommunikationsinfrastruktur ist der Object Request Broker, der Client-Aufrufe an Server-Objekte ortstransparent weiterleitet. Somit spielt es aus Client-Sicht keine Rolle, ob das Server-Objekt lokal erreichbar ist oder sich auf einem entfernten System befindet. Voraussetzung ist hierbei natürlich die Konformität der ORBs zum CORBA-Standard [#!corba22!#], der unter anderem Mechanismen zur Interoperabilität unterschiedlicher ORBs spezifiziert. Der Kommunikationsmechanismus des ORB entspricht einem verbindungslosen Remote Procedure Call, der in der Regel auf einem TCP/IP-Protokollstack aufsetzt und jeweils eine Anfrage (bzw. die Rückantwort) an ein spezifisches Objekt weiterleitet. Folglich ist es bisher nicht möglich, eine Operation auf mehrere Objekte simultan anzuwenden; ein CORBA-Analogon zu den effizienten Scoping- und Filteringmechanismen, wie sie vom OSI-Management bekannt sind, existiert nicht. Dies würde auch nicht zuletzt am Fehlen hierarchischer Namen (siehe oben) scheitern.

Für das Management bedeutet das Vorhandensein des Dynamic Invocation Interface (DII) , daß das Interface Repository (die Gesamtheit der MIBs aller Objekte des ORB-Systems)  jeweils die aktuellen Schnittstellen der Managed Objects beinhaltet und zur Laufzeit nach bestimmten syntaktischen (nicht nach semantischen) Kriterien durchsucht werden kann, um anschließend Abfragen auf den so ermittelten MOs auszuführen. Es ist daher nicht erforderlich, daß einem Managementsystem explizit eine neue MIB bekanntgegeben werden muß; dies geschieht implizit durch das Vorhandensein der neuen Schnittstellen im Interface Repository. Eine neue Version eines Agenten kann beispielsweise ohne Unterbrechung des Gesamtsystems und ohne Neuübersetzung der entsprechenden Anwendung in das Laufzeitsystem eingefügt werden. Wie wir in Abschnitt aufzeigen werden, ist beispielsweise bei der Internet-Managementarchitektur eine solche Vorgehensweise oft nur durch manuelle Konfiguration durch den Administrator möglich und erfordert im OSI-Management einen durch die Management Knowledge Management Function realisierten Abfragemechanismus. Die Verwendung des DII durch eine Managementapplikation bietet ferner den Vorteil, daß diese nicht modifiziert werden muß, falls sich die Server-Objekte ändern.

Um akzeptable Antwortzeiten des Gesamtsystems zu garantieren, ist es notwendig, daß für einen Client die Möglichkeit besteht, asynchrone  Aufrufe an ein Server-Objekt zu richten. Da asynchrone, nicht blockierende Aufrufe derzeit nicht Gegenstand der CORBA-Spezifikation sind, ist die Nutzung von sogenannten deferred synchronous  Aufrufen vorgesehen; synchrone  Aufrufe sind ebenfalls möglich. Erstere Aufrufart ist für Managementbelange eindeutig die geeignetere Methode, da ein aufrufendes Managementsystem eine sogenannte Handle für das Zielobjekt enthält, um zu einem späteren Zeitpunkt den Status der Operation zu erfragen bzw. das Ergebnis anzufordern. Während der Zeitspanne der Bearbeitung durch den Server kann der Client weitere Aufrufe absetzen.

Treten beim Zugriff auf Attribute eines Objekts Fehler auf, bietet CORBA (im Gegensatz zu OSI) hierfür nur Standardfehlermeldungen; benutzerdefinierte, attributbezogene Fehlermeldungen sind - im Gegensatz zum OSI-Management - nicht vorgesehen.