Autor: Michael Stal

Es bedarf keiner prophetischen Fähigkeiten, um für die Softwareindustrie einen fortlaufenden Trend zu vernetzter und verteilter objektorientierter Software zu konstatieren. Heute stellt sich gar nicht mehr die Frage, ob Vernetzung eine Schlüsseltechnologie darstellt. Vielmehr lautet das Problem, sich für die richtige Softwaretechnologie zu entscheiden. Für Echtzeitsysteme mit maximalen Effizienzanforderungen mögen Infrastrukturen wie Microsoft DCOM oder OMG CORBA (noch) eine geringe Rolle spielen. Doch für die Mehrzahl aller Anwendungen stellt sich die Situation gänzlich anders dar, speziell unter Berücksichtigung der immer schnelleren Produktzyklen. Wer kann sich da den Luxus der TCP/IP-Programmierung noch leisten? Um den Grund für die wachsende Akzeptanz von Technologien wie CORBA zu verstehen, lassen Sie uns mit einer Zeitmaschine in das Jahr 1989 zurückreisen. Zum damaligen Zeitpunkt beginnen sich objektorientierte Programmiersprachen und Technologien zu etablieren. Auf dem Markt ist die Betriebssystemlandschaft geprägt von MacOS, MS-DOS, und diversen Unix-Derivaten. Verteilte Systeme spielen in industriellen Softwaresystemen eine zunehmende Rolle. Deren Programmierung erfolgt primär unter direkter Nutzung von Kommunikationsprotokollen oder komfortabler über Sockets oder entfernte Prozeduraufrufe (engl. RPC). Die relativ komplexe Programmierung von Interprozeßkommunikation bleibt jedoch in der Hand einiger weniger Experten. Kein Wunder, denn die genannten Kommunikationsmechanismen sind relativ systemnah. Sie erfordern die Eigenentwicklung selbst rudimentärer Dienste wie zum Beispiel von Namensdiensten. Zudem führen sie im Regelfall zu architekturellen Problemen, weil sich das verwendete Programmierparadigma - zum Beispiel Objektorientierung - im allgemeinen nicht mit dem verwendeten Kommunikationsparadigma - zum Beispiel datenstrombasierte Übertragung unstrukturierter Rohdaten - deckt. Von der Unterstützung heterogener Landschaften mit unterschiedlichen Betriebssystemen und Programmiersprachen ganz zu schweigen. Doch wie lassen sich in dieser Situation blühende Landschaften für Softwareentwickler herbeizaubern? Dabei ist das Glück doch so nah. Mit Objektorientierung liegt die Lösung geradezu auf der Hand. Mechanismen wie Datenkapselung mittels Klassen erlauben ein Verbergen der Details des zugrundeliegenden Betriebssystems und ebenso des verwendeten Kommunikationsprotokolls. Als Verteilungseinheiten dienen dabei Objekte. Konzepte wie Proxy sorgen für einen tranparenten Zugriff auf die entfernten Objekte. Für den Benutzer bleibt zudem durch die Einführung eines zentralen Nachrichtenbrokers verborgen, wo sich das aufgerufene Objekt physikalisch befindet. Mit genau diesem Konzept vor Augen ist im Jahr 1989 das herstellerunabhängige Konsortium OMG (Object Management Group) enstanden. Die Zielsetzung des heute weltweit größten Softwarekonsortiums bestand von Anfang an darin, eine geignete Infrastruktur bereitzustellen, um die problemlose Interaktion von Softwareobjekten selbst in heterogenen Umgebungen zu gewährleisten. Der Begriff "heterogen" beschränkt sich dabei nicht nur auf unterschiedliche Netztechnologien und Betriebssysteme, sondern umfaßt ebenfalls die bunte Palette der verschiedenen Programmiersprachen. Die Informationstechnik in heutigen Unternehmen präsentiert sich auf den verschiedensten Ebenen heterogen und das muß jede Infrastruktur berücksichtigen, will sie die Heterogenität vor dem Entwickler transparent verbergen.

Natürlich kann ein solches Unterfangen nicht unkoordiniert und ungeplant erfolgen. Daher hat die Object Management Group eine Referenzarchitektur definiert, deren Bestandteile sie im Laufe der Zeit mit Leben gefüllt hat und immer noch füllt (siehe Bild 1: OMG Referenzarchitektur).

Als zentraler Bestandteil innerhalb dieser Architektur dient der sogenannte ORB (Object Request Broker). Zu seinen Aufgaben gehört die Weitervermittlung von Methodenaufrufen vom Client an die Server-Objekte, sowie die Übergabe der Resultate und Fehlerbedingungen an den aufrufenden Client. Da der Broker das Herzstück der gesamten Architektur darstellt, erfolgte seine Standardisierung notwendigerweise zuerst. Diese Komponente trägt heute den allseits etablierten Namen CORBA (Common Object Request Broker Architecture).

Der Fokus der Standardisierung beschränkt sich aber nicht nur - wie oft irrtümlich angenommen - auf die Vermittlungskomponente CORBA. Ein Broker stellt lediglich einen objektorientierten Mechanismus zum Aufruf entfernter Objektmethoden bereit. In der Praxis der industriellen Softwarentwicklung genügt dies jedoch nicht. Dort sind zusätzlich Dienste notwendig, die ein breites Spektrum von Problemstellungen abdecken. Beispielsweise die transaktionsorientierte Abarbeitung von Methodenaufrufen, das persistente Abspeichern von Objekten, die Verfügbarkeit von Sicherheitsmechanismen oder der Zugriff auf verteilte Objekte über einen Namensdienst. Deshalb erfolgt im Rahmen der sogenannten Object Services eine Standardisierung dieser fundamentalen Dienste. Deren Anzahl ist heute bereits auf 19 angewachsen, was ihre Bedeutung zusätzlich unterstreicht.

Aber auch mit den Object Services läßt es die OMG noch nicht bewenden. Neben Objektdiensten bedarf es in der Praxis weiterer infrastruktureller Dienste, sogenannter Common Facilities. Zum Beispiel läßt sich auf Basis einer Verteilungsinfrastruktur wie CORBA auch eine Komponententechnologie und darauf aufbauend eine Technologie für Verbunddokumente definieren. Vor wenigen Monaten haben sich die OMG und JavaSoft zu diesem Zweck auf JavaBeans als Standardkomponententechnologie geeinigt. Ursprünglich sollte OpenDoc diesen Part übernehmen, doch mußten die CI Labs inzwischen ihre Technologie trotz aller Stärken zu Grabe tragen. Ein weiteres Beispiel für ein Common Facility ist die Administration vernetzter CORBA-Systeme. Gerade wenn eine Integration unterschiedlicher Produkte erfolgen soll, sind standardisierte Administrationsdienste unverzichtbar.

Während sich Common Facilities auf domänenunabhängige infrastrukturelle Dienste erstrecken, stellen die sogenannten Domain Interfaces Rahmenwerke für spezielle Domänen bereit, zum Beispiel für die Domänen Gesundheitsdienste, Transportwesen, Telekommunikation, oder Finanzdienstleistungen.

Last but not least bilden die Applikationsobjekte die von den Anwendern entwickelten CORBA-Objekte. Sie sind dementsprechend nicht Gegenstand der Implementierung

<Bild 2: Broker Pattern)

Wie bereits erwähnt, repräsentiert CORBA den Antriebsmotor innerhalb der Referenzarchitektur. Um CORBA zu durchleuchten, ist ein Blick auf das darin verborgene architekturelle Konzept hilfreich. Dieses findet sich übrigens auch in konkurrierenden Technologien wie Microsoft DCOM oder Java RMI. Grundpfeiler ist das Einziehen von Abstraktionsschichten zwischen der zugrundeliegenden Plattform und der Anwendung. Ein Broker dient hierbei als Nachrichtenvermittler. In seiner Zuständigkeit liegt das Transportieren von Aufrufen zwischen Client-Applikation und Zielobjekt sowie das Rückübermitteln von Resultaten und Ausnahmebedingungen auf dem umgekehrten Weg. Damit ein Client nicht Kenntnis von der Position des Server-Objekts besitzen muß, implementiert der Broker ein Repository. Dort sind alle von ihm administrierten Server-Objekte mit Namen und physikalischer Position eingetragen. Empfängt der Broker einen Aufruf, durchsucht er sein Repository nach dem angebenen Zielobjekt, aktiviert dieses gebenenfalls und leitet den Aufruf an das Objekt weiter. Der Broker erhält Kenntnis über die verfügbaren Server-Objekte, weil sich diese explizit bei ihm anmelden.

Wären Clients und Server direkt mit dem zugehörigen Broker verbunden, müssten sie sich zur Kommunikation an ein festes Protokoll halten. Dadurch wären Systemabhängigkeiten unvermeidlich. Noch dazu würde daraus ein Bruch mit dem objektorientierten Paradigma resultieren. Aus diesem Grunde sind zwei weitere Indirektionsschichten notwendig. Auf der Client-Seite ist ein sogenanntes Client-Proxy verfügbar, das dieselbe Schnittstelle implementiert wie das zugehörige entfernte Server-Objekt. Statt das Server-Objekt selbst zu benutzen, ruft der Client die entsprechende Methode im Client-Proxy auf. In der Methode des Client-Proxy erfolgt nun, unsichtbar für den Client, ein Konvertieren der Aufrufparameter in ein plattformunabhängiges Format. Anschließend wird ein Aufrufpaket geschnürt, an den Broker weitergeleitet, und auf das Eintreffen des Ergebnisses gewartet. Ist dieses verfügbar, wandelt das Client-Proxy es anschließend in das lokale Format um und beendet den Methodenaufruf. Das alles geschieht transparent für den Client. Server-seitig übernimmt ein Server-Proxy eine ähnliche Funktion, indem es gegenüber dem Server-Objekt als Client in Erscheinung tritt.

Im bisherigen Szenario war stillschweigend vorausgesetzt, daß in einem Netz nur ein einzelner Broker verfügbar ist. In der Praxis macht eine solche Annahme schon aus Skalierbarkeitsgründen nur wenig Sinn. Stattdessen ist ein Netz verteilter Broker-Komponenten wahrscheinlicher, die miteinander netzweit kooperieren. Etwa, um Client-Aufrufe über Broker-Grenzen hinweg weiter zu vermitteln. Da es sich bei den kooperierenden Brokern um unterschiedliche Lösungen handeln kann (unterschiedliche Hersteller, unterschiedliche Betriebssysteme), bedarf es zu diesem Zweck einer gemeinsamen Sprache. Sogenannte Bridge-Komponenten erfüllen diese Aufgabe, indem sie das lokale Protokoll des Brokers in ein gemeinsames Interoperabilitätsprotokoll übersetzen.

<Bild 3: CORBA>

Der CORBA-Standard realisiert zur Unterstützung heterogener Umgebungen die eben beschriebene Architektur. Die im Broker-Pattern eingeführten Client-Proxies und Server-Proxies heissen im CORBA-Kontext Stubs und Skeletons. Da CORBA neben unterschiedlichen Betriebssystemen und Netzwerktechnologien auch unterschiedliche Programmiersprachen unterstützt, ist ein sprach- und prozeßübergreifendes Objektmodell notwendig. Die CORBA-Spezifikation definiert folgerichtig ein entsprechendes Objektmodell. Dort repräsentiert jedes CORBA-Objekt die Instanz eines sogenannten Interface-Typs. Ein Interface-Typ entspricht im objektorientierten Sinne einer Klasse, die ihrerseits mehrere Elternklassen besitzen kann. Unterstützung findet dabei Schnittstellenvererbung, nicht jedoch Implementierungsvererbung. Die Implementierung einer Unterklasse muß daher alle Methoden der Elternklassen mitimplementieren. Wie aber erreicht CORBA die gewünschte Programmiersprachenunabhängigkeit? In anderen Worten: wie ist es möglich, ein CORBA-Interface in Programmiersprache A zu implementieren, diesen entfernten Dienst aber aus einer Applikation in Programmiersprache B zu nutzen? Die Antwort dazu lautet CORBA Interface Definition Language (IDL). Hierbei handelt es sich um eine mit C++ verwandte Definitionssprache, die ausschließlich Elemente zur Datenbeschreibung jedoch keinerlei Anweisungskonstrukte enthält. Auch die Menge der verwendbaren Datentypen ist in IDL gegenüber Programmiersprachen wie C++ eingeschränkt. Sozusagen nach dem Prinzip des kleinsten gemeinsamen Nenners. Wer einen CORBA-Dienst zur Verfügung stellen möchte, beschreibt diesen Dienst zunächst in Form einer IDL-Spezifikation. Zum Beispiel:

// File: RemoteFile.idl

#typedef sequence<octet> ByteArray;

interface RemoteFile {

exception AccessViolation{};

void openFile(in string name) raises(AccessViolation);

long readFile(in long howMuch, out ByteArray b) raises(AccessViolation);

long closeFile() raises(AccessViolation);

// ...

};

Aus dieser Datei generiert ein sogenannter IDL-Compiler unter anderem das zur Implementierung benötigte Skeleton. Dies in der jeweils benötigten Programmiersprache. In C++ beispielsweise als C++-Klasse, von der ein Entwickler eine eigene Unterklasse ableitet und diese wie jede andere C++-Klasse implementiert. Der Benutzer des CORBA-Objekts verwendet seinerseits einen IDL-Compiler, um aus der IDL-Datei das benötigte Stub in der verwendeten Zielsprache zu erzeugen. Daraufhin generiert der IDL-Compiler eine Klasse zum Zugriff auf das entfernte CORBA-Objekt. Diese läßt sich dann wie jede andere lokale Klasse nutzen. Jedes CORBA-Objekt ist dabei über eine Objektreferenz eindeutig und persistent identifizierbar. Die Abbildung von IDL auf verschiedene Zielsprachen gehört übrigens zu den zentralen Standardisierungsaktivitäten der OMG.

Im bisher beschrieben CORBA-Modell müssen Clients bereits zur Kompilierzeit Kenntnis über die von ihnen aufgerufenen CORBA-Objekte besitzen. Gerade in hochdynamisch konfigurierbaren und verteilten Systeme ist eine solche Einschränkung nicht akzeptabel. Daher bietet der Standard ein sogenanntes Dynamic Invocation Interface (DII) und ein Interface Repository. Letzteres enthält IDL-Beschreibungen über die im System registrierten CORBA-Schnittstellen, während das DII unter Zuhilfenahme dieser Typinformationen ein dynamisches Kreieren und Absetzen von Methodenaufrufen ermöglicht. Dem aufgerufenen CORBA-Server bleibt verborgen, ob der Client ihn über ein statisches Stub oder dynamisch über das DII aufgerufen hat. Auf der Serverseite steht als Pendant zum DII das sogenannte Dynamic Skeleton Interface (DSI) zur Verfügung. Dieses erlaubt Servern das Bereitstellen von CORBA-Objekten, ohne bereits zur Laufzeit deren Schnittstellen kennen zu müssen. Was zunächst paradox erscheinen mag, hat in der Praxis eine durchaus sinnvolle Anwendung. Man denke beispielsweise an Gateways zu anderen Objektsystemen oder an interpretative und untypisierte Umgebungen wie etwa Debugger und Smalltalksysteme.

CORBA unterstützt überwiegend die synchrone Request/Response-Semantik, bei der ein Client in einem Methodenaufruf solange blockiert bis sich der Server zurückmeldet. Daneben stehen sogenannte oneway-Requests zur Verfügung, die dem Client eine Fortsetzung seiner Aktivitäten ermöglichen, noch bevor eine Rückmeldung des Servers erfolgt ist. Allerdings ist die erfolgreiche Ausführung von oneway-Aufrufen nicht garantiert. Es handelt sich also um einen unzuverlässigen Mechanismus. Nur im Rahmen des Dynamic Invocation Interface existiert mit "deferred synchronous requests" eine dritte Spielart von Methodenaufrufen. Diese lassen sich asynchron durchführen und periodisch mittel Pollingstrategie auf ihre Beendigung abprüfen.

Die im Broker-Pattern beschriebene Datenbank zum Lokalisieren von registrierten Servern trägt in der CORBA-Architektur die Bezeichung Implementation Repository. Neue CORBA-Server melden sich über den sogenannten Basic Object Adapter beim CORBA-System an. Daraufhin erfolgt ein Eintrag in das Implementation Repository, der unter anderem die physikalische Position des Servers enthält, etwa den Verzeichnispfad des ausführbaren Serverprogramms. Der Basic Object Adapter fungiert dabei als zentrale Schnittstelle zwischen Server und Broker. Er ist beispielsweise für die Aktivierung noch nicht gestarteter Server und die Generierung von Objektreferenzen zuständig. Im ORB Interface verbirgt sich allgemein nützliche Funktionalität, unter anderem Methoden zur Konvertierung von Objektreferenzen in Zeichenketten.

Da in CORBA-Version 1.2 wichtige Festlegungen wie die Interoperabilität zwischen verschiedenen CORBA-Produkten fehlten, kam es Ende 1994 zur Verabschiedung des Nachfolgestandards CORBA 2.0. In der neuen Spezifikation ist festgelegt, wie unterschiedliche CORBA-Implementierungen auf Basis vorhandener Kommunikationsprotokolle miteinander zusammenarbeiten müssen. Einzig die Kooperation auf Basis von TCP/IP ist für Anbieter verpflichtend, alles andere optional. Wollen zwei beliebige Broker über TCP/IP Informationen austauschen, so müssen sie hierfür das standardisierte Protokoll IIOP (Internet Inter-ORB Protocol) nutzen. Die Implementierung dieses Protokolls kann auf verschiedene Weise erfolgen. Eine denkbare Variante ist die direkte Verwendung von IIOP als natives Protokoll, eine Alternative die Verwendung von Bridge-Komponenten zur Protokollkonvertierung zwischen proprietärem Protokoll und IIOP.

Mit der Verabschiedung von CORBA 2.0 hat die OMG zwar einen weiteren großen Schritt zurückgelegt, ist dabei aber noch nicht am Ende ihrer Bemühungen angelangt. Aufgrund der praktischen Erfahrungen mit CORBA 2.0 haben sich in der Zwischenzeit einige weitere Änderungs- und Erweiterungswünsche ergeben. Zum Glück basiert CORBA auf einer sehr sauber konzipierten Architektur, die sich schon beim Übergang zu CORBA 2.0 als robust gegenüber Weiterentwicklungen erwiesen hat. Die hier vorgestellten möglichen Erweiterungen spiegeln den aktuellen Stand wieder und sind mit einigem Vorbehalt zu genießen. Sie sollten aber dennoch einen Vorgeschmack auf ein zukünftiges CORBA 3.0 vermitteln. Es könnten sich aber durchaus noch Änderungen ergeben, frei nach dem philosophischen Grundsatz pantha rei - alles fließt:

• Mehrere Schnittstellen pro Objekt: Zur Anreicherung existierender CORBA-Schnittstellen mit weiterer Funktionalität, beziehungsweise zur Partitionierung von Funktionalität in mehrere logische Einheiten, eignet sich Schnittstellenvererbung nur sehr bedingt. Es wäre hingegen sinnvoll, wenn ein CORBA-Objekt auch mehrere Schnittstellen implementieren könnte. Ein solches Konzept, wie es sich auch in Java und Microsoft COM wiederfindet, könnte demnächst ebenso für CORBA-Systeme zur Verfügung stehen.
• Message Broker: Nicht für alle Anwendungsdomänen ist ein objektorientierter RPC-Mechanismus das probate Mittel. Speziell für nachrichtenbasierte nichtblockierende Kommunikation ala "Fire’n Forget" bieten Produkte wie MessageQ eine bessere Lösung. Daher möchte die OMG entsprechende Mechanismen auch in CORBA integrieren.
• Wertsemantik: In CORBA 2.0 lassen sich Objekte nur per Objektreferenz als Parameter übergeben oder zurück liefern. Für manche Problemstellung wäre die Übertragung einer vollständigen Kopie des entsprechenden Objekts die bessere Alternative. Diese Art von Wertsemantik könnte bald in CORBA 3.0 realisiert sein.
• Portable Adapter: Die Spezifikation des bisherigen Basic Object Adapters bietet derartige Freiheitsgrade, daß die Portierung von Server-Programmen von einem CORBA-Produkt auf das andere nur mit Mühen erfolgen kann. Der Portable Adapter soll hier Abhilfe verschaffen.
• Reverse Mappings: Viele Entwickler stehen dem Problem gegenüber, mit CORBA-IDL einer weiteren Sprache mächtig sein zu müssen. Ein sogenanntes Reverse Mapping definiert für eine vorgegebene Programmiersprache ein Framework, das die Implementierung von CORBA-Objekten ohne Nutzung von IDL ermöglicht. Auf Wunsch lassen sich die IDL-Spezifikationen mit speziellen Werkzeugen aus dem Programmcode wiedergewinnen.

Natürlich sind neben der weiteren Evolution von CORBA auch zahlreiche andere Aktivitäten im Gange. Zum Beispiel die Spezifikation zusätzlicher Services wie etwa dem Trader-Dienst. Dieser ist in der Lage, für einen Client nach CORBA-Objekten mit bestimmten Eigenschaften zu suchen. Etwa nach einem Druckdienst, der sich möglichst in räumlicher Nähe befindet und Farbausdrucke liefert. Das Tätigkeitsfeld der OMG erstreckt sich außerdem auf Objektorientierung generell, nicht nur auf verteilte Systeme. So erfolgt die Standardisierung der UML (Object Modelling Language) der "drei Amigos" Grady Booch, Ivar Jacobsen und James Rumbaugh ebenfalls unter der Schirmherrschaft der OMG. Die Rolle der OMG als letzte Bastion für offene, objektorientierte Systeme ist daher nicht zu unterschätzen.

Microsoft, selbst Mitglied der OMG, ist unbestritten der führende und einflußreichste Softwarehersteller für Desktop-Lösungen. Mittlerweise dringt die Softwareschmiede auch in den bisher von Unix dominierten Server-Markt vor. Um unternehmensweite Lösungen anzubieten, bedürfen Betriebssysteme wie Windows NT und Windows95 einer Infrastruktur ala CORBA. Microsoft Windows verfügt allerdings bereits seit Jahren über die Komponententechnologie COM (Component Object Model). Statt den plattformunabhängigen CORBA-Standard zu integrieren, hat sich die US-Company deshalb einer anderen Strategie bedient und COM zu einer verteilten Lösung namens DCOM (Distributed Component Object Model) erweitert. Der Vorteil liegt auf der Hand: DCOM kann sich der plattformspezifischen Win32-APIs bedienen und ist zudem integraler Bestandteil jeder Windows NT/95-Installation. Um der Kritik der Plattformabhängigkeit zu begegnen, hat Microsoft eine strategische Allianz mit der Software AG geschlossen, deren Zielsetzung in der Portierung von DCOM auf andere Betriebssysteme besteht. Allerdings ist die Verfügbarkeit von DCOM auf Solaris bisher nicht auf den erhofften Zuspruch gestossen. Ein Grund mag darin bestehen, daß die DCOM-Portierung nur die Basisinfrastruktur umfaßt, nicht aber andere ActiveX-Bestandteile oder sogar Entwicklungswerkzeuge. Außerdem herrscht in Fachkreisen noch Skepsis über die Skalierbarkeit von DCOM. Entgegen dem weitverbreiteten Irrtum "DCOM = Windows und CORBA = Unix", existieren auch für Windows seit geraumer Zeit CORBA-Implementierungen, die eine große Stabilität aufweisen. Um die Interoperabilität von CORBA-Lösungen mit DCOM-Umgebungen zu gewährleisten, hat die OMG Arbeitsgruppen eingerichtet, an denen Microsoft sich aktiv beteiligt. Einige CORBA-Hersteller bieten schon seit längerer Zeit entsprechende Integrationslösungen an.

Als weitere Brokerlösung ist das sprachspezifische RMI (Remote Method Invocation) von JavaSoft erhältlich. Durch seine Beschränkung auf Java bleibt dem Programmierer das Erlernen einer Definitionssprache wie CORBA-IDL erspart. Dadurch geht die Programmierung von RMI relativ einfach von statten. Freilich verfügt RMI weder über einen Satz fundamentaler Objektdienste noch über die Funktionsvielfalt einer CORBA-Umgebung. In den entsprechenden Newsgroups kam es deshalb zu heftigen Diskussionen über das für und wider von CORBA und RMI. Mittlerweile hat Sun erkannt, daß diese Diskussion nur der Konkurrenz nützt. Auf dem letzten OMG-Treffen in Montreal haben Sun und die OMG deshalb in einer Presseverlautbarung mitgeteilt, daß in Zukunft RMI über IIOP mit CORBA-Systemen zusammenarbeitet.

Mittlerweile ist eine Vielzahl verschiedener CORBA-Produkte am Markt erhältlich. Neben frei verfügbaren Implementierungen wie zum Beispiel TAO, Electra, OmniBroker oder JacORB existieren inzwischen zahlreiche kommerzielle Produkte. Vom irischen Unternehmen IONA etwas das Produkt Orbix, das sich für zahlreiche Betriebssysteme einsetzen läßt. Das Unternehmen Visigenic macht durch seine strategischen Allianzen mit Netscape, Oracle, Silicon Graphics und Borland von sich reden. So ist VisiBroker for Java integraler Bestandteil des Netscape Communicator und ebenso der Java-Programmierumgebung Borland JBuilder. Silicon Graphics plant sogar die Integration von Visibroker in das eigene Unix-Betriebssystem. Die meisten Workstation-Hersteller führen CORBA-Implementierungen im Programm. Sun verfügt mit NEO, Siemens-Nixdorf mit Sorbet, IBM mit DSOM (Distributed System Object Model) und Hewlett-Packard mit HP-ORB jeweils über eine eigene CORBA-Plattform. Digital hat die Eigententwicklung ObjectBroker mittlerweile an das Unternehmen BEA weiterveräußert. Insgesamt ist die Zahl der erhältlichen Produkte recht hoch. Als Wermutstropfen soll nicht unerwähnt bleiben, daß die verfügbaren Produkte sich meist gegeneinander abzugrenzen versuchen, indem sie zusätzlich zum CORBA-Standard noch proprietäre Features bieten. Deren Verwendung ist insofern problematisch, als daraus Abhängigkeiten vom konkreten Produkt resultieren. Zudem unterscheiden sich die Produkte stark in der Verfügbarkeit von Object Services. Einen kompletten Satz an Objektdiensten kann noch kein Hersteller anbieten. Das wird gerne von CORBA-Gegnern als Argument ins Felde geführt. Zu bedenken ist jedoch, daß Dienste wie etwa ein Transaktionsmonitor in Komplexität und Umfang der CORBA-Implementierung selbst nicht nachsteht. Kein Wunder, daß die Bereitstellung solcher Dienste Zeit beansprucht. Als weiteres Argument gegenüber CORBA ist oft die unüberschaubare Vielzahl der Produkte zu vernehmen. Gerade der daraus resultierende Konkurrenzdruck hat in der Vergangenheit zu einer rasch anwachsenden Qualität der verfügbaren Produkte geführt. Anfängliche Kinderkrankheiten wie etwa fehlerhafte Implementierungen des Interoperabilitätsprotokolls IIOP sind heute nahezu ausgemerzt. Eine Vielzahl von Produkten hat zudem für den Anwender den Vorteil, daß er Abhängigkeiten von einzelnen CORBA-Zuliefern minimieren kann. Ein Ziel, das sich manche Konkurrentechnologie nicht unbedingt auf die Fahnen schreiben möchte. Als Problem ist allerdings die mangelnde CORBA-Unterstützung in Entwicklungsumgebungen zu bezeichnen. Aber auch das beginnt sich mittlerweile zu ändern. So unterstützen Borland JBuilder und Netscape's Produkte die Implementierung von CORBA-Objekten. Rational Rose 4.0 erlaubt bereits die Integration von CORBA-IDL in den Entwicklungsprozeß. Produkte wie Visigenic VisiChannel oder I-Kinetics DBComponent ermöglichen den Zugriff auf relationale Datenbanken über CORBA. Zur Integration von DCOM-Umgebungen existiert ebenso eine Palette von Lösungen.

Im Zuge der unternehmensweiten "Webisierung" mit Internetechnologien wächst auch die Bedeutung von Infrastrukturen für Client/Server-Computing. Aufgrund seiner Plattformunabhängigkeit im allgemeinen und dem Kommunikationsprotokoll IIOP im speziellen paßt CORBA sehr gut in dieses Umfeld. Mittels CORBA ist zum Beispiel der Zugriff auf Serverdienste durch Internet-Benutzer möglich. Die Java-Technologie bietet dazu eine ideale Ergänzung. Zum einen lassen sich in Java sehr elegant grafische Frontends realisieren, zum anderen erlaubt der plattformneutrale Java-Bytecode eine Mobilität von Programmen über das Netz. Erstere Eigenschaft ermöglicht das Erstellen von Java-Applets, die gleichzeitig als CORBA-Clients agieren, und letztere Eigenschaft das Implementieren von CORBA-Objekten in Java. Diese lassen sich dann bei Bedarf, etwa zur Entlastung von Web-Servern, beliebig auf andere Server migrieren. Kein Wunder also, daß viele Hersteller spezielle CORBA/Java-Produkte anbieten. Erwähnt seien an dieser Stelle Visigenic's VisiBroker for Java, IONA OrbixWeb, JavaIDL, und Sun Joe.

CORBA hat sich mittlerweile vom Papiertiger zur weit verwendeten Verteilungsplattform gemausert. Das beweisen zahlreiche Unternehmen, die diese Technologie inzwischen auch im großen Rahmen für ihre Anwendungen einsetzen. Als zusätzlicher Vorteil hat sich dabei das Interoperabilitätskonzept mittels IDL erwiesen, mit dessen Hilfe eine fast schmerzlose Integration existierender Software in ein verteiltes Umfeld möglich ist.

Durch CORBA läßt sich die Komplexität verteilter Software relativ unproblematisch in den Griff bekommen, beseitigen allerdings läßt sie sich nicht. Wer CORBA als Allheilmittel betrachtet, um ohne ohne Berücksichtigung von architekturellen Aspekten und nichtfunktionalen Anforderungen große Systeme zu erstellen, stößt unweigerlich auf Probleme. Das gilt aber generell für jede andere Softwaretechnologie in gleichem Maße. CORBA stellt lediglich eine Spezifikation dar. Nicht der CORBA-Standard ist daher für den Projekterfolg entscheidend, sondern das verwendete CORBA-Produkt.

CORBA eignet sich noch nicht für alle Anwendungsanfelder, etwa Software mit hohen Quality-of-Service-Anforderungen oder Echtzeitsysteme. Aber auch in dieser Richtung bewegt sich momentan im OMG-Umfeld einiges. Beispielsweise ist die Bereitstellung einer leichtgewichtigen CORBA-Version geplant, um derartige Systeme zu unterstützen.

Vom akademischen Umfeld ist andererseits die Kritik zu vernehmen, daß die Technologie noch nicht alle dynamischen Aspekte biete. Beispielsweise selbstbeschreibende Parameterobjekte. Derartige Anforderungen stehen wiederum im Widerspruch zu den Performanzwünschen industrieller Anwender. Es ist ersichtlich, daß sich CORBA im Spannungsfeld zwischen teilweise diametralen Anforderungen befindet. Da der Standard jedoch eine sehr flexible und erweiterbare Architektur definiert, lassen sich auch diese Anforderungen erfüllen. Hier erweist sich als Vorteil, daß es nicht nur einen CORBA-Anbieter gibt, sondern mehrere. Daher sind auch zukünftig unterschiedliche Produkte zu erwarten, die unterschiedliche Kundenanforderungen adressieren.

Zu guter letzt der Blick auf CORBA-Alternatven. Low-level-Programmierung von Kommunikation über Sockets oder andere Mechanismen führt zu schwer wartbarer und inflexibler Software. Ratsam ist dieser Weg nur bei extrem hohen Performananforderungen. Zumindestens ein Application Framework wie Adaptive Communication Environment von Prof. Douglas C. Schmidt sollte in solchen Fällen zum Einsatz kommen. Wenn möglich, ist aber immer der Einsatz einer geeigneten Infrastruktur zu bevorzugen. Gegenüber Konkurrenzplattformen kann CORBA hier mit weiter Verbreitung, Herstellerunabhängigkeit und einem Entwicklungsvorsprung von mehreren Jahren auftrumpfen. Nur eines bleibt mir an dieser Stelle noch zu wünschen: Liebe Unix-Hersteller. Bitte ergreift eure Chance und integriert CORBA endlich in eure Betriebssysteme. Nehmt euch dabei IBM Warp und Silicon Graphics zum Vorbild.

<> OMG: CORBA 2.0 Specification, OMG-Document, 1995

<> Sean Baker: CORBA Distributed Objects - Using Orbix -, Addison-Wesley, 1997

<> Orfali, Harkey, Edwards, The Essential Distributed Objects Survival Guide, Wiley & Sons, 1995

<> Jens-Peter Redlich: CORBA 2.0 - Praktische Einführung in C++ und Java, Addison-Wesley, 1997

<> Jon Siegel: CORBA Fundamentals and Programming, Wiley and Sons, 1996

<> Buschmann, Meunier, Rohnert, Sommerlad Stal, Pattern-Oriented Software Architecture - A System Of Patterns, Wiley & Sons, 1996

<> Object Management Group: OMG

<> IONA: Orbix

<> JavaSoft: Java RMI und Java IDL

<> Netscape: CORBA Entwicklungsumgebung für das Internet

<> Visigenic: VisiBroker

<> Douglas C. Schmidt: Informationen zu CORBA

<> Microsoft: Microsoft ActiveX/COM/DCOM