Systemdefinition als eine Managementarchitektur

Die in 7.1 beschriebene Grundstruktur soll in diesem Abschnitt mit geeigneten Mitteln in eine formale Struktur gefasst werden. Durch Zuordnung von Aspekten der Anforderung zu den Teilmodellen (siehe Kapitel IT-Management) soll eine Definition als Managementarchitektur als Grundlage für das weitere Vorgehen erarbeitet werden. Gleichzeitig werden in diesem Zusammenhang die wichtigsten Elemente der Teilmodelle umrissen und zusammengetragen. Damit entsteht ein Rahmenwerk als Grundlage für das spätere Vorgehen, das die Vorgaben in einem Entwurf konkretisiert und umsetzt.

Die zu definierende Managementarchitektur lehnt sich dabei anforderungsbedingt an die Object Management Architecture an, die zwar in erster Linie ortsungebundene Koorperation von Objekten in verteilten Umgebungen erlaubt, aber im weiteren Sinn bereits als Managementarchitektur angesehen werden kann [LAN01,AK97]:

1. Informationsmodell: Das zentrale Element einer Managementarchitektur ist das Informationsmodell, das auf abstrakter Ebene Syntax und Semantik der auszutauschenden Managementinformationen definiert und damit durch die geforderten abstrakten Beschreibung der JMX-Funktionalität gegeben ist. In diesem Zusammenhang muss eine grundsätzliche Entscheidung getroffen werden, ob aus Gründen der Interoperabilität die allgemein denkbaren Möglichkeiten objektorientierter Spezifikation weiter einzuschränken und zu spezialisieren sind oder ob aus Gründen der Flexibilität des Ansatzes darauf verzichtet werden soll. Folgende Eigenschaften der Modelle können unterschieden werden: Struktur der Informationen, Datentypen, Semantik der Zugriffe und Semantik der Objekte selbst [AK97]. Da das Informationsmodell eine Abbildung der darunterliegenden JMX-Architektur auf einer allgemeinen und abstrakteren Ebene darstellt, wird die Syntax und Semantik des Informationnsmodells durch JMX-Charakteristiken geprägt und bestimmt. Das zu erstellende Informationsmodell muss dabei in der Lage sein, die JMX-Agentenschnittstelle mit all den zugehörigen und benötigten Objekten und Datentypen in dem Umfang beschreiben zu können, dass beliebige, CORBA-konforme Systeme auf die Schnittstelle zugreifen und sie nutzen können. Für die Modellierung des Informationsmodells kommen zwei Alternativen in Frage: Entweder das Einbinden in bestehende Informationsmodelle oder das Neuerstellen. Eine Abwägung dieser Alternativen soll in dem nächsten Abschnitt geschehen.
2. Organisationsmodell: Die in der Anforderung festgelegte Erhaltung der Objektorientiertheit wird durch die CORBA-Interoperabilitätsarchitektur gewährleistet. Sie legt ein Domänenkonzept und als Kooperationsform eine symmetrische Beziehung gleichberechtigter Objekte fest. Die Managementplattform nimmt im Anforderungsszenario eine Klientrolle ein, während der Adapter stellvertretend für den Agenten als Server auftritt. Dabei wird beiden Seiten aufgrund der symmetrischen Beziehung die Möglichkeit zum Wechseln der Rollen bzw. gleichzeitigem Ausfüllung beider Rollen gegeben. Diese Voraussetzungen erfüllen damit den Anspruch eines Organisationsmodells.
3. Kommunikationsmodell: CORBA-ORBs leiten als Kommunikationsmedium Anfragen und Ereignisse in offener, verteilter und heterogener Umgebung zwischen beliebigen Objekten ortstransparent weiter. Die herstellerübergreifende Spezifikation dieses ''Objektbus'' erfolgt in CORBA und ab Version 2.0 [OMG01] muss eine Produktimplementierung die IIOP-Protokollspezifikation für die Kommunikation zwischen ORBs umsetzen, um konform zu CORBA zu sein. Diese unabhängige Kommunikationsebene mit ORB und IIOP bietet sich somit ideal für einen Integrationsansatz zwischen verschiedenen Plattformen und Architekturen an und bildet damit das Kommunikationsmodell, dessen Elemente in den nächsten Schritten entworfen und umgesetzt werden müssen.
4. Funktionsmodell: Mit CORBA als Grundlage können die in der OMA definierten CORBA Services und CORBA Facilities genutzt werden, wobei nur der Namensdienst zum Auffinden des Adapters mit dem dahinterliegenden Agenten und der Ereignisdienst zum Weiterleiten der Nachrichten benötigt werden, die damit ein Funktionsmodell definieren.

Diese Zuordnung von Anforderungsaspekten zu den Teilmodellen einer Managementarchitektur zeigt, dass eine solche Gliederung in diesem Zusammenhang sinnvoll ist und das Zielsystem als Managementarchitektur definiert werden kann.