Kombination von CORBA und Java für
verteilte Client/Server-Anwendungen
im Intranet/Internet

Arne Koschel,
Dirk Hoffmann, Matthias Wipf
{koschel dhoffman wipf} @fzi.de

FZI Forschungszentrum Informatik
Haid-und-Neu-Str. 10-14
76131 Karlsruhe

1 Einleitung

In den letzten Jahren gewinnen verteilte Systeme immer mehr an Bedeutung. Speziell das Internet und das World Wide Web bieten eine vorhandene Infrastruktur, die dem Benutzer einen einfachen Zugriff auf große Mengen von verteilten Informationen und Diensten ermöglicht. Aufgrund des exponentiellen Wachstums und seinen auch Laien einfach zugänglichen und zu nutzenden Diensten wird das WWW [26] von vielen Experten als großer Zukunftsmarkt angesehen.

Zu den vielversprechendsten neuen Technologien, die zur Zeit entwickelt und benutzt werden, zählen zum einen die Common Object Request Broker Architecture (CORBA) [14] der Object Management Group (OMG) und die objektorientierte Programmiersprache Java der Firma SUN Microsystems. Java [8] ermöglicht es, interaktive Anwendungen zu erstellen und über das Internet in einen Java-fähigen Browser zu laden. Da Java jedoch zum Erstellen von verteilten Client/Server-Anwendungen nur grundlegende Funktionen beinhaltet, bietet sich die Kombination mit CORBA an. Die CORBA Spezifikation ist ein herstellerübergreifender Industriestandard zur Interoperabilität von Objekten in verteilten, heterogenen Systemen. Mittels CORBA lassen sich verteilte Anwendungen realisieren, wobei bestehende Anwendungen mittels Wrapper angebunden und weiterverwendet werden können.

Dieser Artikel soll aufzeigen, wie sich CORBA und Java verbinden lassen und welche Möglichkeiten sich durch die Kombination der beiden Konzepte ergeben. Dabei wird im besonderen auf die sogenannten Java ORBs eingegangen, also CORBA-Implementierungen in der Sprache Java. Im nächsten Kapitel werden zuerst die Grundlagen von CORBA und Java beschrieben und die Vorteile aufgezeigt, die sich durch die Kombination der beiden Konzepte ergeben. Im Anschluß daran folgt eine Übersicht über die interessantesten derzeit verfügbaren Produkte, die CORBA und Java miteinander verbinden. Anwendungen und eigene Erfahrungen mit Java ORBs werden in Kapitel 4 dargestellt. Den Schluß bilden ein Zusammenfassung und ein Ausblick auf zukünftige Anwendungen und Entwicklungen.

2 Grundlagen

2.1 CORBA

Das Ziel der Object Management Group, einer 1990 gegründeten Gruppe von inzwischen über 700 Herstellern und Anwendern, ist es, eine Basisarchitektur für heterogene, verteilte, objekt-orientierte Anwendungssysteme zu standardisieren, die Object Management Architecture (OMA). Den Kern ihrer Bestrebungen stellt die Common Object Request Broker Architecture (CORBA) [14] dar. CORBA ist eine Middleware, die das "Einklinken" von verteilten Objektanbietern (Server) und Objektnutzern (Clients) in einen Object Request Broker (ORB) ermöglicht. Die Komponenten der OMA werden in Abbildung 2.1 dargestellt.

Der ORB übernimmt die Verteilung von Objektaufrufen durch Clients bzw. Reaktionen auf Aufrufe durch Server. Wesentliche Merkmale von CORBA sind ein Kernobjektmodell, die Lokalisierungstransparenz, d.h. Clients und Server benötigen keine ortsbezogenen Informationen voneinander, und die Programmiersprachenunabhängigkeit durch Bereitstellung einer eigenen Interface Definition Language (IDL) einerseits und einer dynamisch aufrufbaren Schnittstelle zu Objekten (Dynamic Invocation Interface) andererseits. Durch den aktuellen CORBA-Standard 2.0 wird die Interoperabilität mehrerer ORBs verschiedener Hersteller über Betriebssystemgrenzen hinweg definiert. Hierdurch können Clients und Server miteinander kommunizieren, selbst wenn sie für verschiedene ORB-Implementierungen entwickelt wurden. Zum CORBA-Kern gesellen sich die CORBAservices und die CORBAfacilities. Aus diesen Elementen sollen (z.B. durch Mehrfachvererbung) Anwendungsobjekte (Application Objects) entstehen.

Die CORBAservices [15] dienen dazu, den Entwurf und die Implementierung von Objekten einer verteilten Anwendung so zu unterstützen, daß häufig benötigte Funktionen nicht extra neu entworfen werden müssen. Sie stellen damit die grundlegenden, standardisierten Schnittstellen zur Verfügung, welche die systemnahen Funktionen bereitstellen, die praktisch alle Objektimplementierungen benötigen. Bisher von der OMG spezifizierte Services beinhalten u.a. Lifecycle-, Relationship-, Naming-, Persistence-, Event-, Transaction- und Trader Service.

Die CORBAfacilities [16] sind vergleichbar mit Klassenbibliotheken für bestimmte Anwendungsdomänen. Unterschieden wird zwischen Domain Interfaces, die für eine bestimmte Anwendungsgruppe, wie z.B. CIM dienen, und anwendungsübergreifenden Common Facilities, welche z.B. Benutzerschnittstellen, Informationsverwaltung und Systemverwaltung behandeln. Dabei kann natürlich auf die Funktionalität der CORBAservices zurückgegriffen werden. Populäres Beispiel der Common Facilities ist der OpenDoc-Standard für Compound Documents von IBM. Für dessen (proprietäres) Gegenstück OLE von Microsoft existieren bereits Einbettungen in CORBA bzw. OpenDoc, wodurch die (technische) Interoperabilität entsprechender Anwendungssysteme sichergestellt ist.

2.2 Java

Java ist eine objektorientierte Sprache [4,12], deren Konzepte aus verschiedenen anderen objektorientierten Programmiersprachen entnommen wurden und die stark dem weitverbreiteten C++ ähnelt. Im Unterschied zu C++ wurde Java allerdings von Anfang an objektorientiert konzipiert, weshalb es mit Ausnahme der elementaren Datentypen nur Objekte gibt. C Elemente wie struct, union, enum und typedef gibt es nicht, das Operator Overloading und die Mehrfachvererbung aus C++ wurden ebenfalls gestrichen. Ein weiterer Aspekt bei der Konzipierung von Java bestand darin, die Sprache möglichst einfach, übersichtlich und sicher zu gestalten, weshalb auf Zeiger verzichtet wurde. Weitere wichtige Details der Sprache sind die automatische Speicherverwaltung, das Konzept zur Behandlung von Ausnahmen, die Integration von Multi-Threading und die Bereitstellung von Klassenbibliotheken, z.B. zur Erstellung von graphischen Benutzeroberflächen (GUI).

Wesentlich beigetragen zur Popularität von Java hat sicherlich, daß es als interpretierte Sprache von der verwendeten Rechnerplattform unabhängig ist. Ein Java Programm kann auf allen Plattformen mit Java-Unterstützung eingesetzt werden ("write once, run everywhere"). Zur Ausführung wird lediglich eine virtuelle Java-Maschine benötigt, die den vom Compiler erzeugten Bytecode übersetzt und ausführt. Den Ablauf vom Sourcecode bis zur Ausführung eines Java Programms verdeutlicht Abbildung 2.2. Die Java Runtime ist maschinenspezifisch und muß auf jedes Betriebssystem portiert werden. Sun bietet das JDK (Java Development Kit) für Sparc und X86 Solaris, Windows NT/95 und MacOS an. Java Portierungen für Windows 3.1, OS/2, AIX und OS/400 werden von IBM entwickelt, weitere Portierungen gibt es für Linux, IRIX und diverse UNIX Derivate.

Grundsätzlich gibt es zwei Anwendungsmöglichkeiten für Java. Zum einen kann man Java als gewöhnliche Progranmmiersprache wie z.B. C++ einsetzen, um eigenständige Programme, sogenannte Java-Applikationen, zu erstellen. Zum anderen lassen sich Java Programme in Web-Seiten integrieren, man spricht dann von Java-Applets. Diese sind nur in einem Java-fähigen Web-Browser lauffähig, wie z.B. dem Netscape Navigator ab der Version 2.0 oder dem Microsoft Internet Explorer ab 3.0.

Aus Sicherheitsgründen unterliegen Applets - im Gegensatz zu Java-Applikationen - einigen Einschränkungen. Ausführbare Inhalte, die in Form von Applets von einem fremden Rechner geladen werden, stellen für das lokale System eine potentielle Gefahr dar, da es für die Vertrauenswürdigkeit des heruntergeladenen Programmcodes keine Garantie gibt. Einem Applet ist es deshalb nicht erlaubt, Dateien zu Schreiben oder zu Lesen, da sonst das lokale Dateisystem ausspioniert oder Daten gelöscht werden könnten. Als weitere Sicherheitsrestriktion erlauben Java-Browser Applets nur zu dem Server eine Verbindung aufzunehmen, von dem sie geladen wurden. Der Compiler fängt sprachliche Sicherheitslöcher wie Bereichsüberschreitungen ab, zusätzlich wird der Bytecode eines über das Netz geladenen Java Programmes noch einmal verifiziert.

Java erfreut sich großer Beliebtheit, bietet es doch völlig neue Möglichkeiten für Softwareerstellung, -vertrieb und -administration. Beseitigung von Fehlern und neue Funktionen verspricht das JDK 1.1. Eine von vielen Neuerungen stellt das Java RMI (Remote Method Invocation) [5] dar, das eine Architektur zur Verfügung stellt, um auf verteilte Objekte im Rahmen einer homogenen "Java-Welt" zuzugreifen.

2.3 Die Verbindung von CORBA und Java

Eine Kombination von CORBA und Java bietet sich an, da sich die Stärken der beiden Technologien ideal ergänzen und die jeweiligen Schwächen beheben. Java ORBs sind komplett in Java implementiert und profitieren von der Portabilität dieser Programmiersprache, die auch eine Verwendung in einem Java-fähigen Web-Browser ermöglicht. Client-seitige Java Applets können bei Bedarf die Klassen eines Java ORBs nachladen und dadurch auf CORBA Server zugreifen wie Abbildung 2.3 zeigt.

Vorteile für den CORBA Entwickler

Durch die Portabilität von Java und der großen Anzahl unterstützer Plattformen werden speziell client-seitige Komponenten sehr universell verwendbar. Clients können als Applets programmiert und im Internet oder firmeninternen Intranets eingesetzt werden. In Java programmierte Server bieten den Vorteil, daß aufwendige Portierungen entfallen und Updates durch Nachladen neuer Klassen möglich sind, ohne daß eine Neuübersetzung notwendig ist. Auch Applets lassen sich als Server einsetzen. Sie unterliegen allerdings den durch die Java-Browser auferlegten Sicherheitsbestimmungen, die keinen Zugriff auf lokale Ressourcen erlauben.

Durch das objektorientierte Sprachkonzept von Java ist die Integration mit CORBA nahezu problemlos möglich. Java verfügt mit der Behandlung von Ausnahmen und dem Multi-Threading über Konzepte, die zur Erstellung verteilter Anwendungen sehr hilfreich sind. Die Sprachanbindung (IDL-Java-Mapping) ist bisher noch nicht standardisiert. Bis zur Verabschiedung eines einheitlichen Standards, die im Laufe des Jahres erwartet wird, verwendet jeder Hersteller seine eigene Java-Sprachanbindung, die sich aber nur geringfügig unterscheiden.

Vorteile für den Java Entwickler

Von der Kombination mit CORBA profitiert Java dadurch, daß ein Konzept zur Verfügung gestellt wird, um auf entfernte und verteilte Objekte ortstransparent zugreifen zu können. Die Verbindungsaufnahme eines Applets ist nicht mehr nur auf den Server beschränkt, von dem es geladen wurde. Durch die Trennung von Schnittstelle und Implementierung in CORBA lassen sich auf Server-Seite verschiedene Programmiersprachen einsetzen, zeitkritische Komponenten können zum Beispiel in C++ implementiert werden. Für den Programmierer der Client-Seite ist dies alles transparent, d.h. er braucht über sämtliche Implementierungsdetails nichts zu wissen.

Java ist bestens dazu geeignet, um interaktive WWW-Anwendungen zu erstellen. Auf Server-Seite können diese Anwendungen mit Hilfe von CORBA skalierbar gemacht und auf mehrere Rechner verteilt werden. Durch die Nutzung von client-seitigen Ressourcen und die Möglichkeit, Dienste auf verschiedenen Rechnern parallel auszuführen, lassen sich leistungsfähige Anwendungen mit hoher Verfügbarkeit erstellen. Bereits bestehende Anwendungen können weiterverwendet und mit Hilfe von sogenannten IDL Wrappern an einen ORB angekoppelt werden. Dadurch ergeben sich enorme Kostenvorteile, da Anwendungen für den Einsatz im Internet oder Intranet nicht neu geschrieben werden müssen bzw. weiter verwendbar sind.

Hierin liegt auch der entscheidende Vorteil des CORBA Ansatzes gegenüber von Java RMI. Die RMI Architektur unterstützt ausschließlich Java, was die Anbindung von nicht in Java programmierten Applikationen sehr erschwert. Neben der Unterstützung von mehreren Programmiersprachen bietet CORBA den Vorteil der völligen Ortstransperenz, der Interoperabilität und der Verfügbarkeit der CORBAservices. RMI eignet sich vor allem für reine Java Anwendungen kleinerer bis mittlerer Größe.

Zusammengefaßt bietet die Integration von CORBA und Java folgende Vorteile:

• Erstellung von interaktiven, skalierbaren Internet/Intranet-Anwendungen
• Weiterverwendung von bestehenden Anwendungen
• Integration von verschiedenen Hardwareplattformen, Betriebssystemen und Programmiersprachen
• Verringerter Aufwand in der Administration

3 Produktübersicht

Die Anzahl verfügbarer CORBA/Java Produkte steigt in ähnlichem Maße an, wie die Zahl integrierter Entwicklungsumgebungen für Java. Alle führenden ORB Hersteller haben Java ORBs in ihre Produktpalette aufgenommen oder entsprechende Produkte angekündigt. Im folgenden sollen drei kommerzielle Produkte sowie drei Forschungsvorhaben vorgestellt werden.

3.1 VisiBroker for Java

VisiBroker for Java [22] ist ein Object Request Broker (ORB), der mit dem CORBA 2.0 Standard konform ist und komplett in Java geschrieben ist. Das Produkt wurde unter dem Namen Black Widow von der Firma PostModern Computing entwickelt und basiert auf deren CORBA Implementierung ORBeline, ein CORBA 2.0 konformer ORB mit Sprachanbindung für C++. Nach dem Zusammenschluß von PostModern Computing mit Visigenic Software wurden Black Widow und ORBeline in VisiBroker for Java bzw. VisiBroker for C++ umbenannt.

VisiBroker for Java ist komplett in Java geschrieben und zur Zeit für Solaris 2.x, Windows 95 und Windows NT verfügbar. Der IDL Compiler erzeugt aus einer IDL Java Code sowohl für den Client als auch den Server. Mit Hilfe dieser Stubs kann ein Java Client verteilte Server Objekte aufrufen, wie wenn diese lokal verfügbar wären.

Die Architektur von VisiBroker for Java ist agentenbasiert. Mit Hilfe eines sogenannten Smart Agents (OSAgent) können Clients Servers-Objekte aufrufen, ohne dessen genauen Aufenthaltsort wissen zu müssen. Wird ein Server gestartet, so unterrichtet dieser den Smart Agent über seinen Aufenthaltsort. Ein Client kann dann den Smart Agent befragen, wo sich das Serverobjekt befindet.

Im Gegensatz zu anderen Herstellern verwendet VisiBroker for Java nur ein Kommunikationsprotokoll, das Internet Inter-ORB Protokoll (IIOP). Das IIOP wird im CORBA 2.0 Standard der OMG spezifiziert und ermöglicht die Kommunikation zwischen ORB Implementierungen unterschiedlicher Hersteller. Die Kommunikation zwischen Clients und Servern erfolgt grundsätzlich über IIOP, es wird keine HTTP Daemon benötigt, somit kann der Web-Server seiner eigentlichen Aufgabe, der Bereitsstellung von HTML-Seiten, nachgehen. Für das IIOP ist der sogenannte GateKeeper zuständig. Hierbei handelt es sich um eine Java Applikation, die für die sichere Kommunikation von Clients zu Servern verantwortlich ist (Secure Bridge). Das Zusammenspiel der einzelnen Komponenten wird in Abbildung 3.1 verdeutlicht.

Der GateKeeper kann auch als HTTP Daemon eingesetzt werden. Da es sich aber um eine Java Applikation handelt, ist dies aus Geschwindigkeitsgründen nicht ratsam. Damit Browser, die innerhalb einer Firewall laufen, auf Objekte im Internet zugreifen können, wurde zusätzlich noch ein Protokoll implementiert, wodurch IIOP Pakete per Piggy-Packing auf HTTP Anfragen aufgebracht werden können (HTTP/IIOP tunneling). Fordert ein Client ein Objekt an und kommt keine IIOP Kommunikation zustande, wird der IIOP Request automatisch in einer HTTP Anforderung gekapselt.

Als erster Hersteller bietet Visigenic Java Implementierungen der CORBA Naming und Event Services an.

3.2 OrbixWeb

Iona Technologies ist einer der führenden Anbieter auf dem Gebiet der CORBA Technologie mit Sitz in Dublin (Irland). Ihr Hauptprodukt Orbix mit der Sprachanbindung für C++ gibt es bereits seit Juni 1993 und ist eine der verbreitetsten CORBA Implementierungen mit Portierungen für Windows 3.1x, Windows NT/95, OS/2, Mac System 7.5, sowie für diverse UNIX Systeme. Laut den Angaben von IONA wird Orbix zur Zeit von mehreren tausend Entwicklern eingesetzt.

OrbixWeb [6,7] ist die Java Implementierung von Orbix und inzwischen in der Version 2.0.1 verfügbar. An Plattformen werden bisher nur Solaris und 32-bit Windows unterstützt, die Unterstützung weiterer UNIX-Plattformen ist für das erste Quartal 1997 angekündigt.

Ab der Version 2.0 bietet OrbixWeb sowohl eine client- als auch server-seitige Funktionalität, was bedeutet, daß neben Clients auch Server in Java implementiert werden können. Die Benutzung von Orbix C++ Servern ist aber ebenso problemlos möglich. Wie bei VisiBroker for Java gibt es einen IDL Compiler, der aus einer IDL Beschreibung entsprechende Java Stubs und Skeletons erzeugt. Unterstützt werden alle IDL Typen (auch ANY) und TypeCodes. IONA verwendet ein eigenes Java-IDL Mapping, wird aber das OMG Standard Mapping unterstützen, sobald dies verfügbar ist.

Zur Kommunikation zwischen Clients und Servern unterstützt OrbixWeb das IIOP und das Orbix Protokoll, als Standard wird das IIOP verwendet. Bei Verwendung des IIOP werden Server Objekte durch eine IOR (Interoperable Object Reference) identifiziert, d.h. ein Server muß von sich selbst eine IOR ausgeben, die ein Client liest und zur Herstellung einer Verbindung mit dem Server benutzt. Zum einen kann diese IOR vom Server in eine Datei geschrieben werden. Komfortabler ist dagegen der Einsatz von OrbixNames als Repository für IORs. OrbixNames ist ein CORBA konformer Naming Service, bei dem Server ihre IORs registrieren können. Clients wiederum können diesen Dienst nutzen, um IORs abzufragen. Optional wird auch das Orbix Protokoll unterstützt.

Sehr positiv ist, daß Iona mit OrbixWeb viele Beispiele ausgeliefert, welche die Vielfalt der gebotenen Möglichkeiten gut demonstrieren werden. Eine Unterstützung des hauseigenen Object Transaction Services (OTS) ist ebenfalls vorhanden.

3.3 Joe

Joe [10] ist ein Java ORB, der von der Firma Sunsoft entwickelt wird und inzwischen in der Version 2.0 verfügbar ist. Das Produkt kann nur als Bestandteil von NEO 2.0 oder dem Internet Workshop 1.0 erworben werden, die Version 1.0 ist aber weiterhin kostenlos über das Internet erhältlich. An Plattformen wird nur Solaris ab der Version 2.4 unterstützt, zusätzlich wird Solaris NEO benötigt, da auf Server-Seite nur NEO Services unterstützt werden. Das Internet Inter-ORB Protokoll ist in Joe und NEO ab der Version 2.0 ebenfalls integriert und erlaubt es Joe Clients, auch mit anderen CORBA Implementierungen zu kommunizieren.

Joe beinhaltet einen CORBA ORB, der Nachrichten zwischen Java Applets und Server Objekten transparent transportiert und vollständig in Java implementiert ist. Der Joe ORB wird automatisch mit dem Java Applet in den Web Browser geladen und kümmert sich dann um die Erstellung einer Verbindung zwischen lokalen Java Clients und entfernten NEO Objekten und deren Kommunikation.

Weiter ist ein IDL Compiler vorhanden, der automatisch die Java Klassenstubs aus einer IDL für NEO Objekte erzeugt. Die skalierbare Architektur von Joe ermöglicht es, das Aufkommen hoher Lasten zu regulieren. Sobald das Client Applet in den Browser geladen ist, erleichtert Joe die direkte Kommunikation mit Server Objekten durch Umgehung des HTTP Servers. Der HTTP Server wird dadurch wieder frei für die Aufgaben der Bereitstellung von HTML Seiten und Java Applets.

Durch die Unterstützung von Remote Callback können Java Applets asynchron Nachrichten empfangen. Dies erspart das kostenintensive Nachfragen, ob sich beim Server Veränderungen ergeben haben. Zusätzlich werden noch einige Tools zur Verwaltung, Entwicklung und Programmierung mitgeliefert.

3.4 JacORB

JacORB [1] ist ein Object Request Broker, der in Java geschrieben ist und an der Freien Universität Berlin von Gerald Brose entwickelt wird. In seiner jetzigen Form ist JacORB nicht vollständig konform zum CORBA Standard und noch im frühen Enwicklungsstadium. Das erklärte Ziel dieses Projekts ist allerdings die Konformität zum CORBA Standard, was mit fortlaufender Entwicklung umgesetzt werden soll.

Die aktuelle Version von JacORB trägt die Versionsnummer 0.5e und kann kostenlos von der Homepage geladen werden. Da sämtliche Komponenten in Java geschrieben wurden, kann JacORB auf allen Plattformen eingesetzt werden, für die es eine Java-Unterstützung gibt. Ab der Version 0.5d wird das JDK 1.1 benötigt. Das Produkt ist kostenlos und samt Sourcecode verfügbar.

In der zur Zeit verfügbaren Version von JacORB fehlen einige CORBA Details wie das Dynamic Invocation Interface und der Basic Object Adapter. Deshalb sind nur statische Aufrufe möglich, Server müssen von Hand gestartet werden und können nicht automatisch aktiviert werden. Als Kommunikationsprotokoll wird, wie inzwischen allgemein üblich, das IIOP verwendet. Beim Start eines Servers gibt dieser eine Interoperable Object Reference (IOR) von sich aus, die bei dem als CORBA Object Service implementierten Namensdienst registriert wird und von aufrufenden Clients abgerufen werden kann. Mit Hilfe dieser IOR kann sich der Client direkt mit dem Server verbinden, weitere Daemon Prozesse werden nicht benötigt. Natürlich ist auch ein IDL Compiler vorhanden, der wie üblich Java Stubs und Skeletons erzeugt und zum jetzigen Zeitpunkt noch nicht das CORBA ANY unterstützt.

3.5 Java IDL

Die Firma JavaSoft ist eine Tochter von Sun und für die Entwicklung von Java verantwortlich. Das Fehlen eines richtigen Client/Server-Sprachkonzeptes im JDK 1.0 war auch den Entwicklern bewußt, weshalb unter dem Namen "Remote Objects for Java" zwei Projekte ins Leben gerufen wurden, die dem Programmierer die Erstellung von verteilten Client/Server-Anwendungen mit Java erleichtern sollten.

Neben dem bereits erwähnten RMI gibt es ein weiteres Projekt, das den Namen Java IDL [9] trägt. Wie der Name bereits andeutet wird dabei der von der OMG spezifizierte Industriestandard IDL (Interface Definition Language) benutzt, um Java Clients den Zugriff auf verteilte Objekte zu ermöglichen. Zum gegenwärtigen Zeitpunkt ist Java IDL als sogenanntes "Early Access Release" erhältlich und für Solaris und 32-bit Windows verfügbar. Wie bei allen Produkten von JavaSoft ist die Software kostenlos und soll in das JDK 1.2 aufgenommen werden.

Die IDL Schnittstellenbeschreibung kann mit Hilfe des mitgelieferten IDL Compilers übersetzt werden, der sowohl die Interfacedefinitionen als auch die Client- und Serverstubs erzeugt. Dadurch wird es für Java Clients möglich, entfernte Objekte transparent aufzurufen. In ähnlicher Weise können Java-Server Objekte bereitstellen, die von IDL Clients angesprochen werden können.

Das Java IDL System basiert auf einem portablen ORB Kern, der so strukturiert ist, daß leicht andere ORB Protokolle eingefügt werden können. Die von IDL Compiler erzeugten Stubs sind unabhängig vom verwendeten ORB und rufen für Datenumwandlungen ("Marshalling") und andere ORB spezifische Operationen das entsprechende ORB Modul auf. Neben dem proprietären Door Protokoll unterstützt Java IDL das IIOP und verfügt über einen CORBA konformen Naming Service zur Registrierung von interoperablen Objektreferenzen. Dadurch gewährleistet JavaSoft der Java-Welt den Zugang zu CORBA Servern. SunSoft arbeitet an einem Modul zur direkten Anbindung von NEO.

3.6 JYLU

JYLU [21] ist eine Java Implementierung des ILU 2.0 (Inter-Language Unification) Runtime Kernels von Xerox PARC und liegt derzeit unter der Versionsnummer 0.14 vor. Diese ist kompatibel zu ILU 2.0 alpha 8 und kann kostenlos vom WWW-Server geladen werden. Da JYLU komplett in Java geschrieben wurde, kann es auf allen von Java unterstützten Plattformen ausgeführt werden. Den Java Stub Generator gibt es in zwei verschiedenen Versionen. Zum einen kann man eine Web-Version benutzen, die eine IDL oder ISL akzeptiert und eine tar Datei mittels CGI zurückliefert. Zum anderen kann man den Java Stubber selbst installieren, wobei allerdings ILU 2.0 installiert sein muß.

ILU ist für die transparente, adressraumübergreifende, system- und sprachunabhängige Zusammenarbeit von Objekten gedacht. Hinter der von ILU zur Verfügung gestellte Objektschnittstelle werden Implementierungsdetails zwischen verschiedenen Sprachen, Adreßräumen und Betriebssystemen verborgen. Bei ILU handelt es sich nicht um einen ORB im Sinne des CORBA Standards. Es fehlen einige Funktionen wie das Dynamic Invocation Interface, das Interface- und Implementation Repository. Zudem besitzt ILU eine eigene Schnittstellen-Beschreibungssprache ISL (Interface Specification Language), eine leicht abgewandelten Form der IDL. Der Stubcompiler von JYLU kann aber sowohl ISL als auch IDL Schnittstellenbeschreibungen übersetzen. JYLU unterstützt zur Zeit noch nicht das IIOP und kann deshalb nicht mit ORBs des CORBA 2.0 Standards kommunizieren.

4 Anwendungsbeispiele und eigene Erfahrungen

Java ORBs sind wie die Sprache Java selbst noch sehr neu, weshalb konkrete Anwendungen noch sehr selten sind. Dennoch gibt es ein starkes Interesse an dieser Technologie. Dies zeigt sich darin, daß VisiBroker for Java inzwischen von mehreren namhaften Firmen lizensiert wurde, die diesen Java ORB in ihre Produkte integrieren wollen.

Netscape wird die VisiBroker for Java Runtime in die Version 4 des Navigators und in verschiedene Server Produkte integrieren. Dies bringt den Vorteil mit sich, daß die ORB Klassen bereits im Browser eingebaut sind und nicht über das Netz geladen werden müssen, was bisher sehr viel Zeit in Anspruch nimmt.

Oracle lizensiert VisiBroker for Java für den Einsatz in ihren Netzwerk Computern (NC). Borland wird den Java ORB von Visigenic in seine Java Entwicklungsumgebung JBuilder integrieren. Weitere Lizenznehmer sind Sybase, Novell und Circom.

Das derzeit größte CORBA/Java Projekt, das sich im Rahmen einer Milliarden-Investition bewegt, wird im Auftrag der Hongkong Telekom mit OrbixWeb entwickelt und hat die Erstellung eines Interactive Multimedia Service (IMS) zum Ziel. Diese Dienste sollen u.a. Home Shopping, Electronic Banking und Video-On-Demand ermöglichen. Für das Management der Kommunikations-Infrastruktur wird Orbix zur Bereitstellung von Medien-Servern verwendet. Zur Interaktion mit dem Benutzer kommt OrbixWeb in Set-Top-Boxen zum Einsatz.

Im Rahmen der Evaluierung von CORBA/Java Produkten haben wir verschiedene Java ORBs getestet und kleinere Anwendungen implementiert. Als Beispiel sei hier eine Komponente vorgestellt mit der es möglich ist, asynchron Nachrichten an ein Applet in einem Web-Browser zu übermitteln. Der Benutzer dieses sogenannten Ereignis Monitors kann eine Web-Seite aufrufen und ein Applet laden, das sich bei einem Ereignis-Server anmeldet. Sobald dieser Server ein Ereignis entdeckt, schickt er eine entsprechende Meldung an alle registrierten Clients. Diese Vorgehensweise minimiert die erforderliche Netzwerkkommunikation, da den Clients die wiederkehrende Anfrage nach eventuell vorhandenen Nachrichten erspart wird. Sobald ein Ereignisse entdeckt wird, erfolgt unaufgefordert die Benachrichtigung der Clients. Diese Anwendung wurde im Rahmen des GLOBUS III Projektes [11] zu Demonstrationszwecken erfolgreich eingesetzt.

Auf Client-Seite wurde dabei VisiBroker for Java eingesetzt, der Ereignis-Server wurde mit Orbix in C++ implementiert. Da es sich um ORBs unterschiedlicher Hersteller handelt, erfolgt die Kommunikation über das IIOP. Durch die Verwendung des IIOP sind alle Komponenten sehr flexibel einsetzbar. Die Architektur dieser Anwendung zeigt Abbildung 4.1.

Zuerst wird der Orbix Event Server persistent, d.h. von Hand, gestartet. Er verfügt im wesentlichen über zwei Methoden mit den sich Applets registrieren und Meldungen erzeugen lassen. Beim Start schreibt er eine Interoperable Objektreferenz (IOR) in eine Datei. Applet und VisiBroker for Java Klassen werden in den Browser geladen und ein Callback Objekt instanziiert. Nachdem das Applet die IOR aus der Datei gelesen hat, kann es sich mit dem Event Server verbinden und registriert dort eine Objektreferenz auf das client-seitige Callback Objekt. Eintreffende Ereignisse werden vom Event Server erkannt und an alle registrierten Clients unter Verwendung der übergebenen Objektreferenzen geschickt. In unserem Fall werden Nachrichten in einem eigenen Fenster angezeigt.

5 Zusammenfassung und Ausblick

Die Kombination von CORBA und Java bringt für beide Technologien Vorteile. Durch das Zusammenspiel gut zueinander passender Konzepte ergeben sich vielfältige neue Möglichkeiten für Anwendungen im Intra- und Internet. Java ORBs sind speziell als Infrastruktur für Netzwerk-Computer und für Anwendungen in heterogenen Intranets bestens geeignet. Entsprechende Bandbreiten vorausgesetzt, sind auch komplexere Anwendungen im Internet möglich. Auf Server-Seite hat der Programmierer alle Freiheiten und kann für eine geforderte Aufgabe die am besten geeignete Plattform und Programmiersprache auswählen. Clients wiederum lassen sich durch die Portabiliät von Java nahezu überall einsetzen.

Da Java eine interpertierte Sprache ist, können Java ORBs mit der Performanz von C++ ORBs nicht mithalten. Dies wird sich mit fortlaufender Entwicklung der Java Virtual Machine und der Verfügbarkeit von Just In Time (JIT) Compilern aber verbessern. Das Problem der langen Ladezeiten der vielen Klassen eines Java ORBs läßt sich mit ZIP- bzw. JAR-Archiven beheben. Beim Netscape Navigator 4 sind die Java ORB Klassen sogar schon in den Browser eingebaut.