4.1.3 Auswahl der Protokolle

 Durch das JDMK, das als Entwicklungswerkzeug festgelegt ist, werden eine Reihe von Kommunikations-Protokollen in Form von Adaptern vorgegeben. In diesem Abschnitt werden diese kurz dargestellt und Vor- und Nachteile abgewogen.
Die Entscheidung für oder gegen die Nutzung eines bestimmten Protokolles ist in erster Linie von der spezifischen Umgebung abhängig. Da sich allerdings in den meisten Netzen die wichtigsten Protokolle als Standard etabliert haben, sind weitere Aspekte bei der Auswahl zu untersuchen.
Grundlage für diese Diskussion bilden die durch das JDMK zur Verfügung gestellten Adapter. Dadurch fällt z.B. das Knowledge Query and Manipulation Protocol (KQML) aus dieser Darstellung heraus, obwohl es für die Kommunikation mit und zwischen flexiblen Agenten entwickelt wurde. Es ist allerdings im Rahmen des JDMK möglich einen neuen Adapter zu implementieren, der dieses Protokoll nutzt.
Die auf TCP bzw. HTTP basierende Remote Method Invocation (RMI) ermöglicht Entwicklern das entwerfen verteilter Java-Anwendungen, in denen er Methoden entfernter Objekte aufrufen kann. Das dieser Mechanismus nur zwischen Java-Applikation funktioniert, stört in dem gegebenen Szenario nicht. Kritisch zu betrachten ist jedoch, daß Methodenaufrufe nicht verschlüsselt werden, was zur Folge hat, daß die als Aufrufparameter übergebenen Objekte direkt auslesbar sind. Allerdings bieten die durch Java bereitgestellten Sicherheitsmechanismen und -bibliotheken eine Vielzahl von Möglichkeiten, dem entgegenzuwirken.
Das Hypertext Transfer Protocol (HTTP) bildet die Basis des World Wide Web, und ist als solche weit verbreitet. Es ist in der Regel auf TCP oder UDP gesetzt und benötigt nur wenig Prozessor-Leistung, ist allerdings weniger effizient bei der Übertragung großer bzw. vieler kleiner Dateien, da es für jedes Paket eine neue TCP-Verbindung aufbauen muß. Sicherheitsaspekte wurden bei der Grundimplementierung des HTTP nicht beachtet.
Ein sehr modernes Protokoll stellt das JDMK mit dem Secure Sockets Layer Protocol (SSL) [DiAl 99], das sichere Kommunikation im Internet gewährleisten soll, bereit. Dieses Protokoll erlaubt Client/Server-Applikationen miteinander zu kommunizieren und dabei Lauschangriffe und Nachrichtenfälschungen von dritten auszuschließen. Basis dafür bildet ein auf einem zuverlässigem Protokoll wie TCP aufgesetztes SSL Record Protocol, daß in erster Linie der Zusammenführung anderer Protokollblöcke wie dem SSL Handshake Protocol dient. Dieses Handshake Protocol ermöglicht es dem Client und dem Server, sich vor dem Austausch von Daten zu authentifizieren und einen Algorithmus für die Verschlüsselung der Übertragung auszuhandeln. Vorteil dieses Protokolls ist, daß höher angesiedelte Protokolle wie das HTTP SSL nutzen können, da es für sie transparent ist. Bei der Entwicklung des SSL-Protokolls wurden folgende Ziele definiert [SSL]:

1.

Kryptographische Sicherheit
SSL soll dazu benutzt werden, eine sichere Verbindung zwischen zwei Parteien herzustellen.

2.

Interoperabilität
Unabhängige Programmierer sollen unter Nutzung des SSL Applikationen entwickeln können, die ohne Kenntnis des Partners kryptographische Informationen wie z.B. Parameter und Algorithmen austauschen können.

3.

Erweiterbarkeit
Neue Sicherheitsmechanismen sollen jederzeit eingearbeitet werden können.

4.

Effizienz
Kryptographische Mechanismen benötigen in der Regel eine hohe Prozessorleistung, die es zu minimieren galt.

Mit dem Internet Inter-Orb Protocol (IIOP) stellt das JDMK nicht nur ein Protokoll, sondern eine ganze Architektur zur Verfügung, und zwar die Common Object Broker Architecture (CORBA). Diese Architektur bietet viele Dienste an, die jedoch an anderer Stelle des JDMK bereits enthalten sind. Zudem benötigt sie auch sehr viele Ressourcen, z.B. für einen Name-Service.

Zusammenfassend ist festzustellen, daß sich insbesondere die RMI unter den genannten Sicherheits-Vorbehalten für die Kommunikation zwischen Java-Komponenten eignet. Da SSL über TCP eine sichere Kommunikation gewährleistet, ist der Einsatz dieses Protokolles insbesondere in gefährdeter Umgebung, z.B. im Extranet , vorzuziehen.