4.6.2 Einsatz der CORBA-Services

Da das Gateway selbst eine CORBA-Anwendung ist, können die CORBA-Dienste in Anspruch genommen werden. Die folgende Aufzählung beschreibt, an welchen Stellen im Gateway dies vorgesehen ist. Eine kurze allgemeine Einführung in die CORBA-Services findet man in 2.3.1.

LifeCycle Service:

Im Gateway müssen i. d. R. sehr viele Schattenobjekte verwaltet werden. Eine Managementanwendung muß die Möglichkeit haben, Schattenobjekte zu erzeugen und zu löschen. Der CORBA LifeCycle Service ist deshalb ein wichtiges Hilfsmittel. Beim Internet-Management gibt es bis auf eine Ausnahme keine dem CORBA LifeCycle vergleichbare Mechanismen. Es wird ausschließlich die Möglichkeit unterstützt, SNMP-Tabellenzeilen zu erzeugen und zu löschen. Von Managementobjekttypen, die nicht Element einer SNMP-Tabelle sind, kann es nur eine Instanz in einem Agent geben. Weitere Managed Objects desselben Typs können weder erzeugt noch gelöscht werden. Managed Objects können auch nicht über Adreßräume verschoben werden. Operationen auf Schattenobjekten, die mit dem LifeCycle Service zusammenhängen, können also nicht in die SNMP-Umgebung repliziert werden. Ausnahme ist, wenn ein CORBA-Manager ein Schattenobjekt erzeugt, das eine SNMP-Tabellenzeile repräsentiert. In diesem Fall muß der entsprechenden Tabelle eines Agenten eine neue Zeile hinzugefügt werden (mit einer Set-PDU). Analoges gilt für das Löschen von derartigen Schattenobjekten.

Naming Service:

Der Naming Service wird im Gateway an folgenden Stellen eingesetzt:

• Zu einem Managed Object in der SNMP-Umgebung muß eine Factory gefunden werden, die ein geeignetes Schattenobjekt erzeugt. Da eine Factory auch ein Objekt ist, kann ihr der (zusammengesetzte) Name des Managed Objects, für das es ein Schattenobjekt erzeugen kann, in einem Naming Graph zugewiesen werden. Ein Factoryobjekt kann dadurch schnell gefunden werden.
• Erzeugte Schattenobjekte werden in einem Naming Graph eingetragen. Sowohl das Gateway als auch die Managementanwendung können diesen Naming Graph verwenden, um Objektreferenzen auf die Schattenobjekte zu erhalten. Ähnlich wie Managementobjektinstanzen in einem MIB-Baum eines SNMP-Agenten registriert und identifiziert werden, können Schattenobjekte aus einem Naming Graph ausgewählt werden.

Event Service:

Der Einsatz des Event Service ([OMG96]) wurde schon in 4.5 besprochen und soll hier nicht noch einmal behandelt werden.

Concurrency Control Service:

Ein einfacher Object Adapter reicht alle an ihn gerichteten Requests in der Reihenfolge an die (Schatten)objekte weiter, in der sie beim ihm eintreffen. Erst wenn ein Request abgearbeitet wurde, kann der nächste Request behandelt werden. Aus Effizienzgründen ist es wünschenswert, daß mehrere Requests gleichzeitig weitergereicht werden. Dies kann beispielsweise durch den Einsatz von Threads erreicht werden. In einem solchen Fall müssen Inkonsistenzen, die durch den simultanen Aufruf derselben Schattenobjektmethoden von zwei Threads entstehen können, ausgeschlossen werden. Dazu kann der Concurrency Control Service verwendet werden. In der SNMP-Umgebung werden Zugriffskonflikte auf Managed Objects von vornherein durch das Protokoll ausgeschlossen: Die PDUs treffen hintereinander beim Agenten ein und werden von diesem entsprechend sequentiell beantwortet.

Externalization Service:

Bei einem zustandslosen Gateway werden in den Schattenobjekten keine Attributwerte gespeichert. Der ,,Zustand`` des Schattenobjektes entspricht den Werten der Managed Objects, die es repräsentiert. Bei der Externalisierung muß dieser Zustand jedesmal aus der SNMP-Umgebung geholt werden. Die Schnittstelle, welche die Schattenobjekte zur Nutzung des Externalization Service unterstützen müssen, ist dementsprechend aufwendig. Entsprechende SNMP-Dienste für SNMP-Managementobjekte stehen nicht zur Verfügung.

Relationship Service:

Für eine Managementanwendung ist es oft vorteilhaft, bestimmte Beziehungen zwischen CORBA-Managementobjekten (Schattenobjekten) zu definieren. Eine Abhandlung über derartige Relationen ist nicht Thema dieser Diplomarbeit. Beim Internet-Management gibt es keine Entsprechung zum Relationship Service. Eine Abbildung auf SNMP-Dienste kann also nicht stattfinden. Aus diesem Grund wurde der Relationship Service nicht berücksichtigt.

Persistence Object Service:

Der persistente Zustand eines Objektes bleibt auch nach dem Beenden des Prozesses, dem das Objekt zugeordnet war, erhalten. Ein Grund für den Einsatz des Persistence Object Service in einem Gateway ist also sofort ersichtlich: Nach einem Ausfall kann der Zustand des Gateway vor dem Ausfall wiederhergestellt werden. Dies ist allerdings nur für den Teil des Gatewayzustandes sinnvoll, der Steuerinformationen des Gateways betrifft. Managementinformationsinhalte, die im Gateway repliziert werden, müssen nach einem Ausfall neu aus der SNMP-Umgebung geholt werden. Persistent replizierte Werte werden zum Zeitpunkt des Neustarts in der Regel nicht mehr aktuell sein.

Der Persistence Object Service kann aber auch verwendet werden, um Arbeitsspeicher zu sparen (z.B. in dem Attributwerte, die sich selten ändern, auf einer Festplatte gespeichert werden). Für Schattenobjekte, in denen keine Managementinformationswerte gespeichert werden, erübrigt sich allerdings der Einsatz des Persistence Object Service (die Schattenobjekte haben keinen ,,eigenen`` Zustand, s. o.).

Transaction Service:

Transaktionen werden vom SNMP-Protokoll nicht unterstützt, weshalb Zugriffe auf SNMP-Agenten mittels Transaktionen nicht realisierbar sind.

Query Service:

Einen vergleichbaren Dienst von SNMP gibt es nicht. Trotzdem kann eine Managementanwendung Queries definieren Ein denkbarer Query auf Schattenobjekten wäre die Abfrage des Attributs sysName von allen Schattenobjekten, die dieses Attribut besitzen. Ein derartiger Query hätte zur Folge, daß auf allen diesen Schattenobjekten die Methode get_sysName aufgerufen wird. Dadurch werden die entsprechenden Managed Objects mittels einer SNMP-PDU abgefragt. Im Gateway wird also ein Query Service für SNMP-Managementobjekte (automatisch) simuliert. Wie beim Relationship Service müssen die Schattenobjekte dazu keine spezielle Schnittstelle unterstützen. Für das Gatewaykonzept muß der Query Service aus diesen Gründen nicht näher betrachtet werden.

Property Service:

Der Property Service wurde noch nicht standardisiert. Davon abgesehen existiert in der SNMP-Umgebung kein vergleichbarer Mechanismus für Managementobjekte. In dieser Diplomarbeit wurde der Property Service deshalb nicht berücksichtigt.

Insgesamt bieten die CORBA Services zusammen mit den Common Management Facilities (s. 2.3.3) ein mächtiges Framework für die Entwicklung von Managementanwendungen. Als CORBA-Objekte können die Schattenobjekte unter Verwendung aller Dienste verwaltet werden: Sie können z. B. über Adreßräume verteilt, in unterschiedlichen Verfahrensklassen gruppiert oder in Relation zueinander gesetzt werden. Da aber die wenigsten Services eine Entsprechung in einem oder mehreren SNMP-Diensten haben, bleiben derartige Aktionen meist ohne Wirkung auf die SNMP-Umgebung.

In diesem Zusammenhang zeigt sich auch ein weiterer Vorteil, den die Integration von SNMP in die CORBA-Welt durch ein Managementgateway mit sich bringt. Alle Dienste, die in der CORBA-Architektur ein komfortables Management erlauben und die von der Internet-Architektur meist nicht einmal ansatzweise gegeben sind, sind durch die Integration auch für das Management von SNMP Managed Objects einsetzbar. Eine CORBA-Managementanwendung arbeitet bequem mit Schattenobjekten, während das Managementgateway alle notwendigen Abbildungen zwischen den beiden Welten durchführt.