Mit Einführung der Version 1.1 hat Sun einen wichtigen Meilenstein in der Weiterentwicklung von Java erreicht. Das neue Java Development Kit (JDK) 1.1 bringt zahlreiche Verbesserungen unter anderem im Security-Bereich und die Einführung des Dateiformats JAR zur Bündelung von Dateien für effizienten Download. Das Abstract Window Toolkit (AWT) wurde überarbeitet und für die Windows-Plattform vollständig neu implementiert.

Für die Programmierung von verteilten Anwendungen im Netz (Intra- und Internet) bietet die Sun-Entwicklung verschiedene Technologien. Java-Sockets sind in der Sprache selbst schon vorhanden und ermöglichen eine einfache Kommunikation zwischen Client und Server. Auf Objektebene schließlich ist mit Hilfe der Remote Method Invocation (RMI) eine Kommunikation zwischen verteilen Java-Anwendungen möglich.

Weiterhin gibt es Java-Implementierungen der Corba- und der DCOM-Middleware-Architekturen. Durch Verwendung eines Broker-Mechanismus, wie ihn die Object Management Group (OMG) mit Corba und Microsoft mit DCOM spezifiziert haben, ist es möglich, Clients und Server in verschiedenen Programmiersprachen auf verschiedenen Plattformen zu realisieren und sie außerdem netzweit miteinander zu verbinden.

Im Paket Java.net der Programmiersprache sind schon verschiedene Klassen für Sockets, URLs, IP-Adressen und HTTP-Verbindungen vorhanden. Dies ermöglicht eine einfache Socket-Kommunikation zwischen Client und Server. Entwickler profitieren beim JDK 1.1 vor allem von Verbesserungen und der Aufnahme von BSD-style Sockets. Die Programmierung auf Socket-Ebene bietet Vorteile hinsichtlich des Durchsatzes, ist aber vor allem für große Anwendungen nur schwer wartbar.

Programmierer wollen sich normalerweise um die Anwendungslogik kümmern und nicht um Netzwerkkommunikation. Da aber bei der direkten Verwendung von Sockets keine Schnittstellen-Vereinbarungen zwischen den Objekten der Anwendung getroffen werden, sind Anwendungen auf dieser Basis nur schwer wartbar. Dieser Tatsache will Javasoft mit der Einführung der RMI Abhilfe schaffen.

Bisher gab es RMI nur als "Beta-Add-on" zu JDK-1.0-Versionen. Neben der Möglichkeit, mit Sockets eine Verbindung auf relativ niedrigem Abstraktionsniveau aufzubauen, sind in diesem Werkzeugkasten mit RMI und "Object Serialization" nun neue Möglichkeiten gegeben, eine Java-zu-Java-Kommunikation im Netzwerk auf Objektebene zu betreiben.

In der Sprache ist also bereits eine sogenannte Middleware-Technologie vorhanden. Für die verteilbaren Objekte spezifiziert der Programmierer die Schnittstellen mit Hilfe von Java. Lediglich eine zusätzliche Vererbung von Java. rmi.Remote zeigt an, daß sich dieses Objekt transparent über das Netz ansprechen läßt.

Wie üblich implementiert eine Klasse das Java-Interface. Aus ihm werden mit Hilfe eines RMI-Compilers "Stubs" und "Skeletons" erzeugt. Diese haben die Aufgabe, bei einem Methodenaufruf (Request) die Parameter in ein sogenanntes Request-Paket einzufügen.

Anschließend wird der Request an den Server gesendet, dort vom Skeleton ausgepackt und an die oben erwähnte Implementierung der Methode übergeben. Nach deren Abarbeitung erhält der Client entsprechende Rückgabewerte. Dies geschieht wieder unter Verwendung von Stub und Skeleton.

Der große Vorteil besteht darin, daß dieser Vorgang den Programmierer nicht sonderlich interessieren muß. Das Objekt wird so angesprochen, als ob es lokal im Client vorhanden sei. Lediglich der Erhalt der ersten Objektreferenz - gewissermaßen ein Zeiger über das Netzwerk auf das entfernte Objekt - geschieht über einen Naming-Service. In ihm registrieren sich Server-Objekte unter Angabe ihres Namens und der eigenen Objektreferenz. Clients können zu einem Namen dann die gesuchte Objektreferenz erhalten. Der Naming-Service ist Bestandteil von RMI und wird dort als sogenanntes RMI-Registry, ähnlich der Windows-Registry, bezeichnet.

Ein ähnlicher Ansatz wie RMI, der aber zusätzlich die Vorteile der Sprach- und Plattformunabhängigkeit bietet, besteht mit der Java-IDL (Interface Definition Language) beziehungsweise mit der Kombination von Java und Corba.

Auf der Basis von Corba lassen sich Programme erstellen, die unabhängig von verwendeter Programmiersprache, Betriebssystem und Plattform miteinander kommunizieren können. Durch die Kombination von Java und Corba können also Applikationen entstehen, die von WWW-Browsern dynamisch geladen werden und dann auf Corba-Server im Intra- oder Internet zugreifen.

Der Client kann beispielsweise in Java programmiert sein, während der Server eine Cobol-Anwendung auf einem Host ist. Gerade in der Kombination von beiden Technologien liegen entscheidende Vorteile. Sowohl Corba als auch Java unterstützen die Trennung von Interface und Implementierung. Bei der Nutzung eines Dienstes kann also die zugrundeliegende Implementierung im Server ausgetauscht werden, ohne daß der Client davon betroffen wäre.

Die Schnittstellen der Objekte werden in einer Interface Defini- tion Language beschrieben. Das Erstellen der konkreten Implementierung erfolgt dann in einer beliebigen Programmiersprache (C, C++, Java, Ada 95, Smalltalk, Cobol etc.), für die eine Abbildungsvorschrift (Mapping) vorliegt.

Ein großer Vorteil von Corba ist, daß sich vor allem bereits existierende Anwendungen, die sogenannten Legacy Applications, integrieren lassen. Oft sind Anwendungen in einem Unternehmen vorhanden, die bereits jahrelang zur Zufriedenheit der Benutzer laufen und "nur" nach außen geöffnet werden sollen. Gerade hier und in der Unterstützung einer Vielzahl von Programmiersprachen liegen die Stärken von Corba.

Zusätzlich bietet Corba nicht nur den ORB, also den Objekt-Bus, sondern weitere Dienste, die in den Corba-Services vereinbart sind. Hierzu gehören Naming-, Event-, Security-, Trader- und eine Reihe weiterer Dienste. Ihre Implementierung kann auf bereits bestehenden Infrastrukturen basieren, beispielsweise der Naming-Service auf DCE-CDS oder X.500.

Sowohl Corba als auch Java beruhen auf einem Objektmodell und bieten somit die Vorteile der Objektorientierung. Corba ermöglicht die transparente Verteilung von Objekten im Netzwerk, wobei diese in fast beliebigen Programmiersprachen realisiert und auf unterschiedlichen Betriebssystemen und Rechnerarchitekturen vorhanden sein können. Java erlaubt das Erstellen von portablen Applikationen und Applets, die sich auch dynamisch über das Netz laden lassen.

Implementierung von Java-IDL oder in Java realisierte ORBs sind von zahlreichen Herstellern erhältlich. Javasoft will dem JDK 1.2 einen Java-ORB mitgeben. Netscape liefert seinen Browser Communicator 4.0 standardmäßig mit der Runtime-Version von "Visibroker for Java" aus, womit Corba auf Clients eine DCOM vergleichbare Verbreitung erreichen wird.

Das Distributed Component Object Model (DCOM) ist seit Windows NT, Version 4.0, standardmäßig in diesem Microsoft-Betriebssystem enthalten, für Windows 95 existiert momentan eine Betaversion. DCOM entstand durch Erweiterungen aus dem Vorgänger COM, das Bestandteil von Windows 3.1 ist und eine zentrale Rolle bei der komponentenorientierten Anwendungsprogrammierung (OCX) hat.

Microsoft hat in den letzten Jahren seine Anstrengungen im Bereich der Enterprise-Anwendungen forciert und deshalb COM um die Möglichkeiten der Verteilung der Komponenten auf verschiedene Knoten in einem Netzwerk erweitert. Im Gegensatz zu Corba handelt es sich bei COM beziehungsweise DCOM nicht um einen herstellerunabhängigen Standard. Microsoft möchte das Modell aber durch die Open Group zu einem industrieweiten Quasi-Standard erheben.

Zusätzliche Services sind darin nicht spezifiziert, sondern werden in Form mehrerer neuer Produkte für Messaging und Transaktions-Management sofort auf den Markt gebracht. Für die Spezifikation der Schnittstellen verwendet Microsoft seine eigene Interface Definition Language, oft auch als MIDL bezeichnet. Ein Compiler bildet auf Implementierungssprachen wie C, C++ und Java ab. Zusätzlich können Sprachen wie Visual Basic sogenannte Type-Libs importieren und damit auf DCOM-Objekte zugreifen.

Interessant ist die DCOM-Anbindung an Microsofts eigene Java-Entwicklungs-umgebung. Unter Windows NT ist eine sehr enge Integration zwischen der MS-Java-Variante J++ und DCOM/COM vorhanden. Zahlreiche Wizzards, zum Beispiel ATL-Wizzard für C++, generieren die notwendigen Implementierungsrahmen.

Die Aufgabe des Entwicklers ist es, die notwendigen Methoden zu implementieren und hier und da auch noch Eintragungen per Makros zu machen. Wenn er diese vergißt, und der Code geht dennoch durch den Compiler, sind Fehler (in Java wie in C++) per Laufzeit nur sehr schwer zu finden.

Java wird sich in kurzer Zeit wohl als die Sprache für Client-Server-Anwendungen im Intranet beziehungsweise Internet etablieren. Unternehmen haben beim Einsatz dieser Technologie verschiedene Optionen, wie sie Java letztlich einsetzen wollen. Für den praktischen Einsatz müssen verschiedene Faktoren analysiert werden:

- Wie lassen sich Java beziehungsweise die mit Java angebotenen Technologien in den Entwicklungprozeß integrieren?

- Wie können bereits bestehende Anwendungen mit möglichst wenig Aufwand angebunden werden?

- Wie werden Entwicklung, Installation sowie Wartung und Management unterstützt?

- Welche Tools werden zur Integration geliefert?

- Ist die Technologie skalierbar und performant?

- Welche Securitymöglichkeiten sind vorhanden?

Da Java-Sockets Bestandteil des JDK 1.1 sind, ist die Entwicklung von Anwendungen, die auf diesem Mechanismus basieren, nahezu mit jeder Java-Entwicklungsumgebung (Symantec, Microsoft, Borland, Sun) möglich. Schlechte Wartbarkeit und niedrige Abstraktionsebenen realtivieren die leichten Performance-Vorteile von Sockets.

RMI ist seit JDK 1.1 Bestandteil der Sprache. Einzige Voraussetzung bei der Entwicklung ist also, daß der verwendete Java-Compiler und die virtuelle Maschine mit JDK 1.1 vollständig kompatibel ist. Microsoft unterstützt in J++ und IE derzeit noch kein RMI. Vorteil von RMI ist, daß der Programmierer sich nur innerhalb einer Sprache bewegt. Gleichzeitig ist dadurch aber auch die gesamte Anwendung auf Java beschränkt. Andere Sprachen (C, C++, Visual Basic) können nicht direkt verwendet werden.

Für die Entwicklung von verteilbaren Java-Anwendungen auf der Basis von Corba stehen schon eine Vielzahl von kommerziellen und auch frei verfügbaren Java-ORB-Implementierungen zur Verfügung. Die Einbindung des IDL-Java Compilers ist in nahezu jeder Java-IDE möglich.

Vollkommene ORB-Unabhängigkeit sichert man sich durch die Verwendung des von der OMG verabschiedeten POA (Portable Object Adapter) oder durch Entwicklung eines eigenen Layers. Entwicklungsumgebungen (wie "MS-Dev-Studio", "SniFF" etc. ermöglichen die Integration der Corba-Implementierung in den Zyklus. CASE-Tools generieren aus Modellen die OMG IDL.

Welche Technologie ein Unternehmen letztlich einsetzen sollte, hängt von der Umgebung und den Anforderungen ab. In einer heterogenen Umgebung (und das ist in den meisten Unternehmen der Fall) ist Corba eine sehr gute Wahl. Bei reinen Windows-Umgebungen ist DCOM sicher eine Alternative. Es bleibt abzuwarten, ob die von Microsoft beauftragte SAG auf den Nicht-Windows-Plattformen eine Alternative zu Corba auf den Markt bringt.

Angeklickt

Client-Server-Computing hat sich als allgemeines Paradigma inzwischen etabliert. Dieser Beitrag untersucht, inwieweit Java ein solches Programmiermodell unterstützt beziehungsweise um zusätzliche Funktionalität erweitert. Dabei wird vor allem betrachtet, wie moderne Middleware-Architekturen wie RMI, Corba oder DCOM unterstützt werden. Diese Middleware-Technologien werden Client-Server-Computing durch eine Peer-to-peer-Kommunikation ersetzen und Vorteile bei der konkreten Anwendungserstellung und Softwareverteilung liefern.

*Bernhard Merkle ist als Berater und Software-Entwickler bei der Interactive Objects Software GmbH in Freiburg tätig. Er ist unter der Adresse merkleio.freinet.de erreichbar.