5.2 Integration verschiedener Protokolle in einem Managementsystem

Die bisherige Entwicklung und Beschreibung von Managementsystemen beschränkt sich auf die Existenz einzelner Komponenten, Hierbei stand die Frage: 'Welche Komponenten muß das System besitzen?' im Vordergrund. Weiterhin wurde beschrieben, inwieweit einzelne Komponenten auf andere zugreifen und miteinander kommunizieren um Daten auszutauschen.

Damit ergibt sich jetzt folgendes allgemeines Bild (Abb 5.3) über den Grundaufbau einer Realisierung eines Managementsystems:

  

Abbildung 5.3: Grundaufbau Managementsystem

Ein Nomadisches System kommuniziert mit Services (genauer: mit den Servern dieser Services). Daß es sich dabei um spezielle Server handelt, soll aus Sicht des Clients nicht immer erkennbar sein. Aus Clientsicht betrachtet, kommuniziert der Client mit einem herkömmlichen Mail-Server. Daß dieser Mailserver intern ganz andere Dinge tut, als dies bisher von einem Mailserver zu erwarten war, ist völlig irrelevant. Wichtig für den Client ist nur, daß er seine Email bekommt, also den Mail-Service nutzen kann.

Diese Server werden vom Client also über ihr service-eigenes Protokoll angesprochen. So kann der Mail-Service zum Beispiel über POP3 oder SMTP angesprochen werden.

Um dies zu realisieren, benötigt man entweder mehrere Interfaces an einem Mailserver oder mehrere unabhängig voneinander arbeitende Server. Um diese Entscheidung zu treffen, muß man klären, wo die Aufgabenbereiche eines Interfaces beginnen und wo sie enden.

Ein Interface kann man als reine Schnittstelle betrachten, die Daten annimmt, gegebenenfalls sammelt und dann zur Auswertung und Bearbeitung weiterleitet. Man kann ein Interface aber auch mit umfangreicheren Aufgaben definieren. Danach nimmt es nicht nur Daten an, sondern wertet sie auch aus. Das Ergebnis reicht es dann erst zur Bearbeitung weiter. Der Server selbst erfährt lediglich, welches seiner Interfaces dieses Ergebnis 'eingeliefert' hat und sendet ihm die entsprechende Antwort. Diese Antwort wird dann im Interface erst in das richtige Kommunikationsprotokoll umgesetzt und abgesendet.

Ersteres ist die modularere Version, die es erlaubt, komplett unterschiedlich arbeitende Protokolle hinzuzufügen, ohne ein bereits Vorhandenes ändern zu müssen.

Im zweiten Beispiel muß man für jedes neue Interface den Server abändern.

Das gleiche Prinzip gilt für die anderen dargestellten Server.

Für den Druck- und Fax-Service werden jeweils unterschiedliche Protokolle verwendet (eines für den Druckservice, ein anderes für den Fax-Service).

Ein Beispiel, inwieweit die selben Services über verschiedene Protokolle erbracht werden können, liefert Abbildung 5.4.

  

Abbildung 5.4: Interfaces mit unterschiedlichen Protokollen

  

Abbildung 5.5: Services mit unterschiedlichen Protokollen

Hierbei wird davon ausgegangen, daß dem Nomadischen Systems zur Nutzung des ServicesA zwei Protokolle (Service-ProtokollA und Service-ProtokollB) zur Verfügung stehen, welche konkret von InterfaceA bzw. InterfaceB erbracht werden. Die Interfaces übernehmen in diesem Fall den Protokollspezifischen Teil des Servers. Je nach dem, welches Protokoll genutzt wird, werden gesendete Daten von InterfaceA oder InterfaceB angenommen. Diese analysieren die erhaltenen Daten und leiten an die eigentliche Service-Funktionalität lediglich die Bedeutung weiter (in der Abbildung als AuftragX bezeichnet). Der Service sendet seine Antwort an das entsprechende Interface und dieses sendet sie an das Nomadische System.

Abbildung 5.5 stellt den anderen Ansatz dar. Hier wird für jeden Protokolltyp ein eigener Server entwickelt, der genau ein Interface für ausschließlich diesen Typ Protokoll besitzt. Diese Version ist in der Praxis flexibler, da man, wenn man ein neues Protokoll hinzufügen möchte, lediglich einen entsprechenden neuen Server erstellt. Dieser Vorgang ist von anderen Services und Servern unabhängig. Der Nachteil dieser Realisierung besteht darin, daß man ein und die selbe Funktionalität (z.B. Email für NutzerX ausliefern) mehrfach implementiert.

Der Aspekt 'Kommunikation mit dem Managementsystem' ist in beiden Abbildungen (5.4 und 5.5) nicht dargestellt.

Die Kommunikation der einzelnen Service-Server mit den Komponenten ihres Managementsystems (in Abbildung 5.3 mit durchgezogenen Linien dargestellt) kann auf die gleiche Art und Weise geschehen, da auch hier lediglich eine Nutzung eines anderen Services vorliegt.

Die Verwendung eines einheitlichen internen Kommunikationsprotokoll wie in Abbildung 5.8 auf Seite vorgestellt, bringt den Vorteil, daß man nicht zusätzlich auch alle internen Komponenten für alle denkbaren Protokolle auslegen muß. Sollte dies trotzdem nötig werden, kann man jederzeit entsprechende Services hinzufügen.

Jini oder SLP integrieren

]Jini oder SLP integrieren Verwenden Nomadische Systeme unterschiedliche Managementplattformen (zum Beispiel Jini oder SLP), so kann man dies wie folgt realisieren:

Die Komponente, die das Nomadische System direkt anspricht, verhält sich, wie die entsprechende Komponente der Managementplattform. Für alle weiteren Aufgaben (Abrechnung, Policy-Service-Nutzung...) verwendet sie das allgemeine interne Managementprotokoll (siehe Definition auf Seite ).

Man kann auch alle Komponenten ihr eigenes Managementprotokoll verwenden lassen. Dabei würde man entsprechend viele Managementsysteme parallel zeitgleich verwenden. Dann muß man darauf achten, daß an mindestens einer Stelle die Plattformen auf gemeinsame Daten zurückgreifen und so indirekt miteinander kommunizieren. Geschieht dies nicht, ist es möglich, daß ein Nomadisches System (absichtlich oder unabsichtlich) wechselweise die verschiedenen Plattformen nutzt und so eventuelle Freieinheiten mehrfach ausschöpfen kann, bzw. am Ende nicht berechnet bekommt.