Wie C++ ist Java objektorientiert, Java-Applikationen bestehen aus einer Menge definierter Objekte mit Zustand und Verhalten, die miteinander über Schnittstellen kommunizieren. Dies erlaubt den Einsatz moderner Software-Entwicklungsmethoden mit den entscheidenden Vorteilen wie leichterer Änderbarkeit und Wiederverwendbarkeit von Code.
Java ist für verteilte Anwendungen ausgelegt
Java unterstützt standardmäßig weitgehend die Entwicklung verteilter Software. Die mitgelieferten Bibliotheken bieten sowohl eine einheitliche Schnittstelle zur TCP-Netzwerk-Programmierung als auch weitergehende Klassen zur Benutzung von Protokollen wie HTTP oder FTP. Das Programmieren im Netzwerk gestaltet sich damit so einfach wie der Zugriff auf lokale Dateien.
Java gestattet echtes Late-Binding, welches vom Interpreter erledigt wird, und das Laden von Code zur Laufzeit über ein Application Programming Interface (API). Dieser Sachverhalt prädestiniert es für eine Symbiose mit Corba.
Javas Multithreading gehört zu dessen hervorstechenden Fähigkeiten. Sie verbessert die Skalierbarkeit von Anwendungen. Eine Kombination von Schlüsselworten und Standardklassen unterstützt diese Eigenschaft. Auf Multiprozessor-Maschinen können die Threads auf diverse CPUs verteilt werden und laufen daher parallel. Ansonsten findet ein Scheduling im Time-slice-Verfahren innerhalb eines Prozesses statt.
Corba definiert die Applikationen-Infrastruktur
Die Common Object Request Broker Architecure (Corba) ist eine Technologie der 1989 gegründeten Object Management Group (OMG). Momentan zählt die OMG zirka 650 Mitglieder, darunter alle großen Softwarehäuser. Mit Corba wird die Infrastruktur für die Entwicklung verteilter Anwendungen innerhalb heterogener Umgebungen definiert.
Corbas Herzstück ist der Object Request Broker (ORB), der als Vermittlungsstelle zwischen den Objekten fungiert. Für den Servicenutzer (Client) ist es dabei von untergeordneter Bedeutung, in welcher Programmiersprache und für welche Plattform die avisierten Objekte auf dem Server implementiert worden sind.
Der Nachrichtentransport zwischen den Kommunikationspartnern basiert auf TCP/IP und einem optimierten XDR-Verfahren (XDR = eXternal Data Representation) für die Darstellungsschicht. So hat auch das IIOP (Internet Inter-ORB Protocol) TCP/IP als Fundament und definiert den Transportmechanismus für das Netzwerkprotokoll, wenn eine Kommunikation unterschiedlicher ORB-Implementierungen (stand-alone und vernetzte ORB) vorgesehen ist. Die Interface Definition Language (IDL) ist eine deklarative Sprache, mit der Objekt-Schnittstellen vereinbart und Funktionalität nach außen sichtbar gemacht wird. Sie dient der Objektbeschreibung.
Die Implementierung wird in einer konkreten Programmiersprache vorgenommen, für die ein sogenanntes Mapping existiert. (Momentan sind die Sprachabbildungen für C, C++, Smalltalk und ADA 95 offiziell von der OMG definiert). So erzeugt der IDL-Compiler beispielsweise sowohl die C++-Klassen-Definitionen als auch die Stubs (Methodenrümpfe).
Die Stubs transformieren die übergebenen Operations-Argumente in einen Corba-Request, der anschließend zum Zielobjekt auf dem Server gesandt wird. Auch die automatische Konvertierung der Rückgabewerte wird von den Stubs übernommen.
Um die Kommunikationsfähigkeit von Objekten in einer verteilten Umgebung zu gewährleisten, müssen diese einen eindeutig identifizierbaren Namen aufweisen. So kann je nach verwendeter Corba-Technologie ein Objektname aus den Komponenten Marker, Interface-Name, Server-Name und Host-Name zusammengesetzt sein. Diese Bedingung wird durch den entsprechenden Corba-Naming-Service realisiert. Wenn nun der Client diese Objektreferenz korrekt erhält, kann er anzusprechende, potentiell weltweit verteilte Objekte so behandeln, als ob sie lokal vorhanden wären. Denn unter diesen Voraussetzungen ist es für den ORB möglich, die Objekte im heterogenen Umfeld zu lokalisieren.
Die statischen und dynamischen Serviceaufrufe gewährleisten dem Client-Entwickler ein Maximum an Flexibilität beim Erstellen von Applikationen. Sind zur Erstellung des Client bereits Schnittstellen der avisierten Objekte greifbar, so kann der statische Ansatz genutzt werden. Das dynamische Handling wiederum managt Anfragen an neu hinzugefügte Objekte.
Warum eine Symbiose von Java und Corba viel Aufmerksamkeit verdient, sollen folgende Ansätze verdeutlichen. Sie bietet sich nämlich als Alternative zu Web-Technologien wie HTTP oder CGI an. Diese sind in erster Linie für die Interaktion mit dem Anwender konzipiert, nicht aber für jene zwischen Applikationen.
Mit Hilfe des Java-Corba-Verbunds kann man via Internet auf beliebige unternehmenskritische Anwendungen zugreifen. Damit können Unternehmen den Datentransfer etwa zwischen Mainframe-basierenden Applikationen direkt über das Java-Interface auf beiden Seiten miteinander verknüpfen. Diese Lösung vereinigt die Vorzüge aus beiden Welten: Java macht durch den plattformunabhangigen Byte-Code eine Portabilität von Anwendungen in heterogenen Strukturen möglich. Und zusätzlich wird die Codemobilität durch das Laden von Applets via Netzwerk garantiert. Ergänzend dazu erlaubt Corba einer Java-Applikation, entfernte Dienste in Anspruch zu nehmen. Ein weiteres Plus ergibt sich aus den Gemeinsamkeiten der Objektmodelle von Java und Corba. Dieser Aspekt wird unter anderem in der Kapselung sichtbar: Objekte sind von außen nur über Schnittstellen zugreifbar. Zwischen Schnittstelle und Objektimplementierung erfolgt eine explizite Trennung (Remoting of Interfaces). Ein direkter Zugriff auf die Datenelemente eines Objekts wird dadurch nicht gewährt. Dadurch ist es erst möglich, das Objektmodell von Corba fast übergangslos in Java umzusetzen, was den Entwicklungsaufwand wesentlich verringert.
Die Vereinigung von Java und Corba scheint also eine ideale Konstellation zu sein. Sie kann zu massiven Kostenreduktionen führen, zu schnelleren Software-Entwicklungszeiten und zu skalierbaren Lösungen, die weltweit verteilte Transaktionen realisieren können - bis hin zu Clients, die nicht nur plattform-, sondern auch netzübergreifend funktionieren.
Verfügbare Java-ORBs
Zum heutigen Zeitpunkt existieren für das Corba-immanente IDL/Java-Mapping Entwicklungen der Unternehmen Sunsoft, Visigenic und Iona Technologies:
Sunsoft JOE
Sunsofts "JOE" (Java Objects Everywhere) enthält einen ORB in Form von Java-Klassen, einen IDL-Compiler und ein "Proj-Tool" genanntes Werkzeug, das eine minimale Entwicklungsumgebung bereitstellt. Wird eine IDL-Datei in das Proj-Tool aufgenommen, so kann von dort der Compiler aufgerufen werden.
Joe repräsentiert eine Lösung zur Integration von Java in Suns Corba-Implementierung "NEO". Dabei ist die Unterstützung sogenannter Remote Callbacks erwähnenswert. Es handelt sich hierbei um die Fähigkeit von NEO-Objekten, Java-Applets auf der Client-Sei- te asynchron über Ereignisse zu informieren. Dadurch entfällt die Notwendigkeit der ständigen Abfrage, ob sich etwas am Server geändert hat. Zukünftige Versionen von JOE werden das IIOP verwenden und somit den Zugriff auf beliebige Corba-Objekte ermöglichen.
Iona Orbix Web
Iona Technologies brachte 1993 mit "Orbix" die erste vollständige Corba-Implementierung auf den Markt, welche mittlerweile auf etwa 20 verschiedenen Plattformen läuft. Das irische Unternehmen bietet auf dem eigenen, frei zugänglichen Web-Server eine Evaluierungsversion des Java-Corba-Brokers "Orbix Web" an. Um Orbix Web zu implementieren, ist allerdings eine bereits vorhandene Orbix-Version 2.0 vonnöten.
Visigenic Visibroker
Post Modern Computings "BlackWidow" heißt seit der Übernahme des Herstellers durch Visigenic "Visibroker". Hinter Visibroker verbirgt sich ein Corba-2.0-konformer Java-ORB. Er unterstützt wie Ionas Konkurrenzprodukt bereits die Kommunikation über IIOP. Zudem enthält er einen IDL-to-Java-Codegenerator, der Java-Stubs und Java-Skeletons erzeugt.
*Uta Unger ist Mitarbeiterin der in München ansässingen Ixos Software GmbH..