Das JDMK war die zweite zentrale Thematik der Diplomarbeit. Nach dem Testen der einzelnen
Komponenten und Dienste, wie sie in Kapitel 3 beschrieben werden,
war die Frage zu klären, inwieweit dieses Managementtool die Anforderungen, welche durch
die Theorie der Flexiblen Management Agenten, wie sie in Kapitel
2
beschrieben werden, erfüllt. Die Anforderungen, welche in dieser Theorie formuliert werden und
die Erfüllung durch JDMK sind in Tabelle 7.1 für die
Systemeigenschaften und in Tabelle 7.2 für die
Agenteneigenschaften gegenübergestellt. Falls die Eigenschaften von JDMK mit den Forderungen
der Theorie der Flexiblen Management Agenten übereinstimmen, dann ist dies mit einem ``+''
gekennzeichnet, andernfalls zeigt ein ``-'' das Fehlen eines Mechanismusses auf Seiten von
JDMK an. Ist die Eigenschaft ``teilweise'' erfüllt, so hat dies die Bedeutung, daß es zwar keinen
expliziten Mechanismus in JDMK gibt, es jedoch möglich ist, mit der durch JDMK gelieferten
API einen solchen Mechanismus zu realisieren.
| Anforderungen des Systems | Erfüllung durch JDMK | ||
| Systemeigenschaften | Organisatorische Merkmale | Agenten | + |
| Flexible Management Agenten | + | ||
| Manager | + | ||
| Domänen | teilweise | ||
| Gruppen | - | ||
| Kommunikationsmerkmale | Tasks | + | |
| Information | + | ||
| Funktionalität | + | ||
| Dienste | Delegation Service | + | |
| Event Service | teilweise | ||
| Group Service | - | ||
| Location Service | teilweise | ||
| Security Service | teilweise | ||
| Management Service | + | ||
[FMA Systemeigenschaften und JDMK] FMA Systemeigenschaften und JDMK
| Anforderungen des Agenten | Erfüllung durch JDMK |
| Plattformunabhängigkeit | + |
| Flexibilität | + |
| Push/Pull Mechanismus | + |
| Management by Delegation | + |
| Kaskadierende Aufrufe | teilweise |
| Kooperationsfähigkeit | teilweise |
| Kontrollmechanismen | + |
| Module | + |
[FMA Agenteneigenschaften und JDMK] FMA Agenteneigenschaften und JDMK
Der zweite Punkt war die Realisierung eines Prototypen, welcher auf qualitative Art die Verwendbarkeit von JDMK für das Management des TIS prüfen sollte. An dieser Stelle war die Wahl des Design von zentraler Bedeutung. Es mußte beachtet werden, daß zum einen die TIS-MIB schon vorhanden war und sich noch in Veränderung befand (bzw. noch befindet) und somit ein Ansatz, welcher die Generierung von Dateien aus der MIB ermöglicht große Vorteile bringt. Die Wahl fiel auf das Generierungstool MIBGEN (vgl. Kapitel 3.8.2) , welches von JDMK zu Verfügung gestellt wird. Dieses Tool generiert aus einer gegebenen MIB die erforderlichen Java-Dateien als M-Beans nach einem bestimmten Schema, welches in Kapitel 5.3.2 anhand des Prototypen erläutert und vorgestellt wird. In den dadurch erstellten Rahmen wurde die eigentliche Implementierung des Prototypen erstellt. Die Erstellung des Prototypen ist in Abbildung 7.1 zu sehen.
Abbildung 7.1: Phasen der Prototyperstellung
Wie in der Abbildung zu ersehen, spielte die proprietäre Schnittstelle eine entscheidende Rolle bei der Integration des Prototypen in die bestehende TIS-Umgebung. Um diese Schnittstelle zu erstellen, war es notwendig, das Java Native Interface (JNI) zu verwenden. Diese API für die Erstellung von proprietären Schnittstellen, welche in C oder C++ erstellt sind, wird in Kapitel 7.1.3 einleitend vorgestellt. Um die Dienste anhand der TIS-Management-Umgebung zu testen war es notwending, einerseits Elemente der TIS-MIB zu überprüfen, anderseits künstlich eine Notwendigkeit einer JDMK-Dienstnutzung zu erzeugen. So wurde beispielsweise der Cascading Service (vgl. Kapitel 3.7.13) verwendet, um eine Master/Slave-Agentenhierarchie aufzubauen, auch wenn nicht explizit die Verwendung notwendig gewesen wäre. Der Aufbau der Agenten und deren Struktur ist in Kapitel 6.8 beschrieben.