4 Management des Telephony Internet Servers mittels JDMK

  Die Integration von Sprach- und Datenkommunikation wird immer wichtiger, um die Kosten für den Erwerb, den Betrieb und die Wartung von Kommunikationsdiensten und Geräten zu reduzieren. Es ist möglich, die hohen Kapazitäten bestehender breitbandiger Datennetze für die Übertragung von Sprache zu nutzen. Unternehmen haben damit die Möglichkeit, Anrufe zu entfernten Standorten lokal in Datenströme zu konvertieren und über das Internet oder bestehende eigene Datennetze zu übertragen. An der entfernten Lokation werden die eingehenden Datenströme wieder in Sprache umgesetzt und an den gewünschten Gesprächspartner vermittelt. Mit dieser Technik können teure Verbindungen über öffentliche Telefonnetze (public switched telephone networks (PSTN)) vermieden werden. Dies ist besonders für global agierende Unternehmen attraktiv, für die sich dadurch erhebliche Einsparpotentiale ergeben. Dazu müssen an den verschiedenen Standorten Gateways zwischen den Vermittlungsanlagen (private branch exchange (PBX)) und den Datennetzen installiert werden. Diese Gateways werden als Internet Telefonie Server bezeichnet.

Traditionell wurde die Administration und das Management von Telefonsystemen und den entsprechenden Netzen von Carriern mit speziell angepaßten und oftmals proprietären Managementsystemen, Protokollen und Werkzeugen durchgeführt. Die zunehmende Sprach/Daten Integration führt dazu, daß auch Telekommunikationssysteme mit Technologien verwaltet werden, die aus dem Management von Datennetzen kommen. Das bedeutet, daß offene und standardisierte Middleware Infrastrukturen ebenso wie bereits bestehende IT-Managementsysteme unterstützt werden müssen.

Die Telefonanlage Hicom 300 der Firma Siemens mit ihren zugehörigen Gateways ermöglicht die Vermittlung von Telefongesprächen über ATM oder über Internetprotokolle (TCP/IP) [18]. Das Gateway, das die Schnittstelle zwischen analogen sowie digitalen Daten (Audio, Video) und den Internetprotokollen realisiert, wird als Telephony Internet Server (TIS) bezeichnet. Außerdem ist der TIS in der Lage, verschiedene Protokolle für Videokonferenzen (H.323 und H.320) zu unterstützen und er integriert verschiedene Endgeräte (z.B. Telefone und Computersysteme), von denen aus telefoniert werden kann oder die an einer Videokonferenz teilnehmen können (vgl. Abb. 4).

Im Rahmen einer Industriekooperation mit der Siemens AG [8] wurden mit JDMK (Version 3.0 Beta 2) eine Managementanwendung und ein Agent für das Management des TIS entwickelt.

  

Abbildung 4: Telephony Internet Server (TIS), Anwendungsszenario

Der TIS selbst mit allen seinen Komponenten ist als Windows NT Dienst implementiert. Die bisherige Anwendung zum Management des TIS basiert auf SNMP. Der TIS-Agent ist ebenfalls als Windows NT Dienst implementiert und nutzt die Windows NT SNMP Extension Agent Facility. Damit kann ein neues Managementmodul (implementiert als dynamische Bibliothek) beim Agent registriert werden, ohne den Agenten neu compilieren zu müssen. Allerdings muß bei jeder neuen Registrierung der Agent gestoppt und neu gestartet werden. Der für den TIS verantwortliche Teil des SNMP-Agenten ist rund 250 kBytes groß, die TIS-MIB besteht aus rund 150 Variablen, 20 Tabellen und sechs Typen von asynchronen Events.

Es ist klar, daß -- besonders in großen Unternehmensnetzen -- Zugriffskontrollen auf die MIB-Variablen realisiert werden müssen. Für einige der Variablen soll der lokale Administrator das Recht zum Lesen und Setzen besitzen, auf die anderen soll nur der für das unternehmensweite TIS-Netzwerk zuständige Administrator zugreifen dürfen. Obwohl dies mit dem SNMP View-based Access Control Model (VACM) [27] möglich wäre, ist VACM bisher nicht im TIS-Agenten implementiert. Es ist bislang nicht möglich, abgestufte Zugriffsrechte auf Ebene der MIB-Variablen zu vergeben.

  

Abbildung 5: Management von TIS mit JDMK

Die Anforderungen, die an ein Managementsystem für den TIS gestellt werden, lassen sich wie folgt zusammenfassen:

• Hoher Grad an Flexibilität, Anpaßbarkeit und Skalierbarkeit
• Möglichkeit die Funktionalität zur Laufzeit der Anwendung zu erweitern oder zu modifizieren
• Einfache Update-Mechanismen
• Fein abgestuftes Sicherheitskonzept (vergleichbar mit SNMP VACM)
• Persistente Speicherung des Agenten und dessen Zustandes und damit ein sicheres Wiederanfahren nach einem Ausfall
• Fähigkeit den Agenten in höherem Maße mit Autonomie in Form von Reaktions- und Aktionsfähigkeit auszustatten
• Zugriff auf standardisierte Middleware, Namens- und Verzeichnisdienste
• Einfache Integration in bestehende Managementsysteme sowie Unterstützung verschiedener Protokolle
• Unterstützung von Java basiertem Management, um einen höheren Grad an Plattformunabhängigkeit und Portabilität zu erreichen.
• Unterstützung des Web-based Management Paradigmas

JDMK wurde in diesem Projekt eingesetzt, weil es viele interessante Möglichkeiten bietet und viele der gestellten Anforderungen an eine Entwicklungsumgebung bzw. ein Framework erfüllt. Da sich der TIS noch in der Entwicklung befindet und sich deshalb die MIB und die Implementierung noch ändern können, sollte bei der Realisierung eines TIS-Agenten möglichst viel generiert werden können, um den Anpassungsaufwand nach einer Änderung gering zu halten. Aus der TIS-MIB wurden deshalb mit Hilfe des mibgen Compilers M-Beans erzeugt, d.h. die Umsetzung der MIB in eine M-Bean Struktur erfolgt automatisch. In den generierten M-Beans müssen vom Entwickler die spezifischen Algorithmen für den Zugriff auf den TIS implementiert werden. Eine Anpassung nach einer Änderung kann dennoch relativ schnell erfolgen, da nur die Implementierung der geänderten M-Beans anzupassen ist. Beim Agenten können die geänderten M-Beans zur Laufzeit durch die neuen ersetzt oder um zusätzliche M-Beans oder Objekte erweitert werden.

Bei einer Änderung der M-Bean Implementierung oder bei einem Versionswechsel des TIS-Agenten können der M-Let und der Launcher Service zum dynamischen Update verwendet werden. Dazu müssen lediglich im <MLET>-Tag eines HTML-Files die entsprechenden Klassen eingetragen werden. Der Launcher Service sorgt unter Zuhilfenahme des M-Let Service dafür, daß noch nicht installierte Klassen nachgeladen werden, oder er tauscht den kompletten TIS-Agenten aus, falls sich dessen Versionsnummer geändert hat.

Intern ist der TIS aus mehreren Komponenten (z.B. Gatekeeper, Administration Maintenance Server (AMS), u.a.) aufgebaut, die über ein eigenes Nachrichtenformat über Interprozeßkommunikation (IPC) miteinander kommunizieren. Die dafür notwendigen Methodenaufrufe sind in einer dynamischen Bibliothek zusammengefaßt. Um auf die Managementinformationen der Komponenten zugreifen zu können, mußte der TIS-Agent das Nachrichtenformat und die IPC-Mechanismen implementieren. Dazu wurde die entsprechende dynamische Bibliothek mittels Java Native Interface (JNI) eingebunden und in einer Java Klasse (NativeBase, vgl. Abb. 5) gekapselt. Dies bedeutet, daß der JDMK-Agent und dessen M-Beans über Java Methodenaufrufe den TIS managen können. Bei einer Änderung der MIB ändert sich diese Schnittstelle nicht.

Der TIS-Agent sollte Web-basiertes Management ermöglichen, d.h. ein Web-Browser sollte als Managementkonsole verwendet werden können. Diese Anforderung läßt sich sehr einfach durch die Registrierung des HTML-Adapters im CMF des TIS-Agenten realisieren. Dieser Adapter, der wie ein gewöhnlicher WWW-Server angesprochen wird, erzeugt HTML-Seiten mit allen Informationen und Methoden, die der TIS-Agent zur Verfügung stellt. Die generierten Seiten entsprechen allerdings nicht immer den Anforderungen an ein modernes User Interface. Sie können jedoch als Basis für eigene Erweiterungen verwendet werden. Prinzipiell reicht die Registrierung des HTML-Adapters im TIS-Agenten aber aus, um den TIS über einen Web-Browser managen zu können.

Daneben sollte aber auch der traditionelle Zugriff über SNMP erhalten bleiben und zusätzlich die Möglichkeit eröffnet werden, über andere Protokolle (z.B. RMI) auf den TIS-Agenten zuzugreifen. Auch dies läßt sich durch eine einfache Registrierung des entsprechenden Protokolladapters realisieren.

Eine weitere Forderung war, daß der Agent relativ einfach in eine Corba basierte Architektur zu integrieren sein sollte. Von JDMK wird zwar auch ein IIOP-Adapter angeboten, aber um den TIS-Agenten in eine Corba Infrastruktur zu integrieren, ist dieser Adapter nicht ausreichend. Er implementiert nur das IIOP-Protokoll und verwendet keine Corba Services, d.h. insbesondere werden der TIS-Agent oder dessen M-Beans nicht in den Naming Service oder das Interface Repository eingetragen. Um dies realisieren zu können, wären größere Anpassungen am TIS-Agenten erforderlich.

Die im Rahmen des Projekts realisierte Architektur für das Management von TIS ist in Abb. 5 dargestellt. TIS2-MIB, NetworkParams und GKStatistics sind Beispiele für M-Beans, die Teile der TIS-MIB implementieren.