In vielen Rechner-Netzen wurde beim Aufbau nicht an den Einsatz spezieller Management-Tools gedacht. Diese werden häufig erst dann in Betracht gezogen, wenn es sich um ein großes Netz (einige hundert Rechner, über mehrere Standorte verteilt) handelt. Die meisten Netze wurden für wenige Hosts designed und sind im Laufe der Zeit gewachsen. In ihnen wird traditionell jeder Dienst einzeln dort installiert, konfiguriert, überwacht und manipuliert, wo er läuft (d.h. wo er erbracht werden soll). Dabei ist es nicht vorgesehen, diese Aufgabe zentral zu managen. Oder von einem Managementsystem überwachen zu lassen. Diese Notwendigkeit wird meist erst sehr viel später festgestellt.
In den Anfängen des Internet (und Intranet) zum Beispiel sind solche gewachsenen Netzwerke die Regel. Somit haben auch fast alle Service-Server keinerlei Schnittstellen, die über eigene, lokale Konfigurationsfiles hinausgehen oder für ein umfangreiches Management designed worden wären.
Das Problem, welches sich daraus ergibt, ist die Frage, wie man in die vorhandenen Dienste eine zusätzliche Management-Schnittstelle integrieren kann. Dabei hat man grundsätzlich zwei Lösungsansätze:
Dies geht nur bei Diensten (speziell bei deren Servern), die man auf diese Art und Weise einfach abkapseln kann, d.h. von der Außenwelt abschneiden kann, so daß sie selbst keinen direkten Zugriff mehr auf das Netz und die dort übertragenen Daten haben (Abb. 5.6. Bei manchen Diensten (Services) muß man bei dieser Entscheidung nochmls zwischen dem Service allgemein und den einzelnen existierenden Servern mit dazugehörigen Protokollen unterschieden. Es ist möglich, daß bei einem Dienst zwar eine Kapselung des Servers mit ProtokollA möglich ist, beim ServerB des gleichen Services aber nicht, da das dazugehörige Protokoll dies nicht zuläßt. In der Abbildung wird der Service dargestellt, dessen Interface als SServer bezeichnet wird, und somit als Server zu diesem Service fungiert. Damit soll verdeutlicht werden, daß diese Kapselung theoretisch mit jedem Server eines Services möglich sein kann.
Bei normalen Services läßt sich die Kapselung realisieren, indem der Original-Server auf einem Nicht-Standard-Port auf Daten wartet und das neue Interface auf dem Standardport agiert und die Daten bei Bedarf entsprechend an den anderen Port weiterleitet und anders herum ebenfalls wieder zu sich senden läßt und dann erst 'ausliefert'. Es fungiert sozusagen als Proxy für das Nomadische System. Das zusätzliche Konfigurationsinterface greift dann direkt auf das Konfigurations-File des Services zu, manipuliert es und veranlaßt, daß der Service selbst bei Bedarf neu gestartet wird oder anderweitig dazu veranlaßt wird, die neue Konfiguration einzulesen. Alle Konfigurations-Aspekte, die im Original-Service (und somit auch Server) nicht vorgesehen sind (Verwendung von Policies, Kommunikation mit einem Policy-Service), muß das neu erstellte, dem Original-Service vorgestellte, Interface leisten.
Ansatz eins hat den Vorteil, daß man bereits existierende Server weiterverwenden kann. Diese muß man eventuell umkonfigurieren, ansonsten werden keine weiteren Veränderungen benötigt. Allerdings ist der Ansatz, durch ein Zusatzprogramm auf eines oder mehrere Konfigurations-Files zuzugreifen, sehr fehleranfällig.
Ansatz zwei würde die Kapselung des Servers verhindern. Dafür muß man die komplette Implementierung des jeweiligen Servers neu vornehmen.
In beiden Ansätzen muß man darauf achten, daß das verwendete Protokoll der Schnittstelle für die Kommunikation mit dem Managementsystem und die Konfiguration von allen anderen benötigten Diensten und Komponenten verwendet werden kann (also passende Implementierungen dieser Dienste vorhanden sind) Siehe dazu auch Abbildung. 5.7: In der Abbildung werden nur die verschiedenen Services gekennzeichnet, die dazugehörigen Server werden nicht weiter angegeben, sie werden mit der ServiceX-Angabe mit assoziiert.
Dem Nomadischen System stehen zur Nutzung des ServicesB zwei Protokolle zur Verfügung (PA und PB). ServerB des ServicesB reicht seine vom Nomadischen System mit Protokoll PA empfangene Daten an den Server des ServicesC weiter. Dies geschieht über Protokoll PC. ServveC kommuniziert auf seiner 'internen' Seite mit ServiceA über Protokoll PD und der wiederum über Protokoll PD mit ServiceC. Wichtig bei der Installation einer solchen Service-Kette ist es, daß, soll ServiceB ServiceC nutzen können, die 'interne' Schnittstelle von ServiceB (also der entsprechende Serverr des Services) jeweils Protokoll PC 'sprechen' muß, da sonst die Kette unterbrochen wird.
Dieses Problem vermeidet man, indem man ein einheitliches Protokoll innerhalb der Management-Komponenten (alle Services zusammen, ohne dem Nomadischen System bilden das Managementsystem) ein einheitliches Protokoll verlangt (siehe Abbildung 5.8).
Service-Konfiguration]Service-Konfiguration
Die Konfiguration des einzelnen Services kann jetzt (im Objektmodell
gedacht) direkt am Server angesetzt werden, da jeder Server nur ein
Interface 'nach außen' und eines 'nach innen' mit integriertem
Management-Interface besitzt.
Jeder Service-Server soll, je nach internen Managementsystem, ein eigenes Konfigurationsinterface besitzen. Dieses Interface soll folgende Grundfunktionen anbieten: