Als die Mitglieder der Object Management Group (OMG) mit der Spezifizierung von Corba begannen, verfolgten sie eine Vision, die heute auch Befürwortern einer Web-Services-Architektur vorschwebt: Eine "offene" Infrastruktur, über die sich Anwendungen und Objekte gegenseitig finden und verständigen können - unabhängig von den verwendeten Programmiersprachen, Hardware, Betriebssystemen und Netzwerkprotokollen.

Erfolgsstory der 90erDieses Ziel hat Corba nach Ansicht seiner Verfechter erreicht, wenn sich auch der Plattformsupport mittlerweile wieder auf diverse Unix-Derivate und Windows konzentriert. Rund 800 OMG-Mitglieder, darunter IT-Hersteller wie Anwender, trieben die Spezifikationen bis Mitte der 90er Jahre so weit voran, dass sich Corba zeitweise zum bevorzugten objektorientierten Integrationsmechanismus für komplexe und oft unternehmenskritische Systemlandschaften mauserte. Schätzungsweise 50 unterschiedlich mächtige Implementierungen des Corba-Standards, so genannte Object Request Broker (ORB), sind heute erhältlich. Hierzu zählen kommerzielle Angebote von Iona, Borland, IBM oder Bea Systems sowie ORBs, die als Shareware oder Open Source verfügbar sind, darunter prominente Vertreter wie "Mico" oder "TAO", die bei Microsoft oder Boeing im Einsatz sind. Mindestens 1000 Großunternehmen sowie zahlreiche Hersteller nutzen heute Corba (Referenzliste unter http://www.corba.org/).

Konkurrenz auf dem VormarschTrotz dieses Erfolgs gerät Corba seit mindestens einem Jahr technologisch in die Defensive. Komponentenmodelle wie Enterprise Javabeans (EJB) der Java 2 Enterprise Edition (J2EE) und COM+/.NET konkurrieren mittlerweile um die Gunst von Systemarchitekten und Entwicklern. Mit dem Konzept der Web-Services und deren Favorisierung von XML und Web-Standards wie HTTP scheint es mit Corbas Vorreiterrolle als letzlich proprietären, weil nicht Web-basiertem und synchronem Kommunikationsstandard zwischen verteilten Anwendungen endgültig vorbei zu sein. Hinzu kommt, dass die Corba-Gemeinde nicht über entsprechende Marketing-Budgets und Benutzerscharen verfügt, um so massiv für sich zu werben wie die Konkurrenz.

Dennoch bleibt Corba für manche Anwendungsszenarien weiter die erste und oft einzige Wahl (siehe Kasten "Kriterien"). Vor allem die Möglichkeit, Objekte mit Hilfe der Schnittstellen-Beschreibungssprache Interface Definition Language (IDL) und deren Compiler in zahlreichen Programmiersprachen implementieren zu können, gilt als eine der großen Stärken des Standards. Die OMG bietet "Language Mappings" für die Sprachen Ada 95, C, C++, Cobol, Java, Lisp, PL/1, Python und Smalltalk. Hinzu kommen "inoffizielle" Mappings etwa für Delphi, Pascal, Perl, PHP, Pike, Ruby oder Tcl/Tk.

Da die OMG versucht, Corba interoperabel zu halten, lassen sich auch technische Brücken zwischen Corba-Anwendungen und populären Technologien bauen. So sind schon seit einigen Jahren der Corba- und der Java-Standard zusammengerückt. Java-Applikations-Server nutzen reichlich Corba beispielsweise in Form einer Reihe implementierter Dienste sowie das Protokoll RMI over IIOP und den Portable Object Adapter (POA). Das Java Development Kit nutzt Corba, so weit es für den eigenen Standard Sinn hat (zur Koexistenz von Java und Corba siehe CW 23/01, Seite 70).

Die künftige Unterstützung für Microsoft COM+ ist hingegen noch unklar. Die Redmonder werden mit .NET das XML-basierte Kommunikationsformat Simple Object Access Protocol (Soap) verwenden, während Corba das architekturneutrale General Inter ORB Protocol (Giop) nutzt. Im September 2000 begann die OMG aber eine Lösung zu entwickeln, wie sich Giop statt wie bisher auf TCP/IP künftig direkt auf Soap mappen lässt. Damit würden sich aus der .NET-Welt heraus die vielen Corba-Services nutzen lassen, wenn auch jeder Thread eine eigene Client-Verbindung benötigt.

Laut Jost Hoppermann, Director Research Europe bei der Giga Information Group, werden trotz neuer Trends manche Unternehmen Corba die Treue halten. Es sind dies in erster Linie Mainframe-orientierte Firmen mit zahlreichen dezentralen oder terminalbasierten Anwendungen. Sie suchen nach Ansicht des Analysten nach einer "agileren" Service-basierenden Architektur, um neue Anforderungen an die Systemlandschaft umsetzen zu können. Branchenschwerpunkte sind die Luftfahrt, Banken und TK-Hersteller, die Systeme mit Echtzeitverarbeitung benötigen. Ebenso setzen Medienanstalten auf Corba, darunter CNN oder Pro 7, der diesjährige Sieger des COMPUTERWOCHE-Award "Anwender des Jahres" (siehe CW 41/01, Seite 78). Und es finden sich sogar vereinzelt neue Corba-Projekte, vor allem bei Finanzdienstleistern und Behörden wie der Bundesanstalt für Arbeit.

Corba kann begeisternWelche Rolle Corba haben kann, erläutert Ulrich Gähler, Chief IT Architect Zürich Financial Services bei der Zürich Versicherung: "Die Möglichkeit, mit Corba eine komplette Servicearchitektur aus Geschäftskomponenten aufbauen zu können, hat uns begeistert." Als sein Team vor drei Jahren entschied, mit Corba eine komplette Bankarchitektur aufzusetzen, war es zugleich die einzige funktionierende Infrastruktur am Markt, die diesen Wunsch erfüllen konnte. "Wir konnten sehr schnell neue Kontakt- und Vertriebskanäle implementieren und zählen heute 50 interne Anwender sowie einige tausend externe Benutzer", schildert Gähler. Typisch für die meisten Anwender wird Corba auch hier mit anderen Techniken kombiniert. So nutzt Zürich Microsoft-Clients, setzt bei der Web-Entwicklung zunehmend auf Java und experimentiert im Portal-Umfeld mit ersten Soap-Implementierungen.

Corba, so Gähler, sei nichts für IT-Shops mit nur 20 Mitarbeitern, denn der Aufwand für den Aufbau einer Infrastruktur sei enorm. "Mit einer gescheiten Architektur lässt sich in Großunternehmen die Komplexität aber immerhin erheblich reduzieren". Auch habe man die Entwickler nicht einfach auf Corba "losgelassen", sondern vorab ein Competence-Center mit mittlerweile vier Experten geschaffen, über das ein von der Anwendungslogik unabhängiges Datenmodell entwickelt wird. Ferner werden nur die wirklich benötigten Corba-Schnittstellen (Services) implementiert. Die anfangs erhoffte Servicelandschaft sei aber erst teilweise Realität geworden. In der Praxis lasse sich laut Gähler die von der OO-Theorie versprochene Wiederverwendung der generierten Objekte für neue Dienste nur schwer erzielen. "Dies ist für mich auch ein Grund, warum das Kozept der Web-Services derzeit auf so viel Interesse stößt."

Sorgen um externen Corba-Support braucht sich der IT-Profi indes wenig zu machen: Der Großraum Zürich gilt mit Anwendern wie UBS, Credit Suisse oder Zürich Versicherung seit Jahren als Corba-Hochburg. Wichtig für die Zukunft bleibt es aber laut Gähler, sich eng an den Corba-Standard zu halten und immer wieder Kompatibilitätstests mit anderen ORBs zu machen, um bei Bedarf die Schnittstellen auf einen anderen ORB neukompilieren zu können.

Wie bei der Zürich Versicherung, so ist laut Giga-Analyst Hoppermann die Entscheidung für Corba meist architekturgetrieben und geht von der IT aus. Doch angesichts schnellerer Technologie- und Anwendungszyklen, kann Corba nicht mehr jahrelang evaluiert und erprobt werden. Dies kann Gunther Lochstampfer, Mitarbeiter beim Dienstleister VR Kreditwerk Hamburg - Schwäbisch Hall AG, bestätigen.

Die IT hatte geplant, über Corba alle Vertriebskanäle zu vereinen: Internet, Innendienst, Banken und per Corba-Fat-Client-Generierung auch der Außendienst. Die firmeneigene Beratungssoftware, die als C++-Fat-Client entwickelt wurde, sollte in Corba-Komponenten gekapselt werden und als verteilte Server-Anwendung laufen, um die diversen Kanäle zu bedienen. Doch das Projekt wurde von der Geschäftsleitung aufgrund enger Terminvorgaben für die Banken und den Innendienst gestoppt und nur zum Teil realisiert.

Wie die Bausparkasse finden sich immer mehr Firmen, die von Corba Abstand nehmen oder ihre bestehenden Anwendungen für den Einsatz mit J2EE wrappen wollen. Als Gründe nennt Giga-Analyst Hoppermann schwindendes Corba-Know-how, mangelhafte Entwicklungsprozesse, Fusionen, Umstellungen von Backend-Systemen sowie allgemein schlechte Projekterfahrungen mit Corba. Viele Experten glauben daher, dass der OMG-Standard vor allem als Basistechnologie im Java-Standard weiterleben wird. Laut Christian Witt, Systemarchitekt bei der Mathema AG, ist der Integrationsaufwand nur noch dann vertretbar, wenn Firmen wenige Corba-Services benötigen und nicht die ganze Bandbreite an Diensten eines J2EE-Servers. "Doch auch EJB-Projekte werden komplex sein, weil verteilte Architekturen nun mal komplex sind", warnt Witt.

"Was Corba kann"Die Corba-Kernspezifikationen beschäftigen sich mit grundsätzlichen Aspekten wie Interfaces, Objektbus und Methodenaufrufen. Hinzu kommen zusätzliche Corba-Services und die dazugehörigen Spezifikationen für Namensdienste, Sicherheit, Ereignisse, Persistenz und Objektverwaltung. Corba unterstützt Interoperabilität durch Programmiersprachen- und Ortstransparenz sowie durch Plattformunabhängigkeit. Corba-Implementierungen existieren für die verschiedensten Betriebssysteme, und die OMG hat Inter-ORB-Protokolle zur reibungslosen Interoperabilität definiert. Aktueller Release-Stand ist 2.4, der auch die meisten Neuerungen des Corba-Standards 3.0 enthält. So sind jetzt bidirektionale Verbindungen über Firewalls möglich, und es steht ein interoperabler Namensdienst zur Verfügung, mit dessen Hilfe Objekte durch URLs identifiziert werden können. Das ebenfalls vorgestellte "Corba Component Model" wurde bisher nicht implementiert.

KriterienCorba könnte die richtige Lösung sein, wenn:

- Ein verteiltes System das Ziel ist,

- die beteiligten Anwendungen in verschiedenen Programmiersprachen erstellt werden,

- Server und Clients verschiedene Plattformen nutzen,

- bestehende Anwendungen eingebunden werden müssen,

- Dienste wie Security, Transactions,Naming oder Event Notification nötig sind,

- Kompatibilität mit dem J2EE-Standard erforderlich ist,

- das Projekt eine umfassende, strategische Softwarearchitektur zum Ziel hat.

Corba ist weniger geeignet, wenn:

- Das System nur auf einem einzelnen Rechner laufen soll,

- die Anwendung in einer Sprache geschrieben werden soll,

- eine Microsoft-Lösung mit COM+ oder .NET das Ziel ist,

- das geplante System nur kurzfristigen Nutzen bringen soll,

- die Kommunikation asynchron über eine Web-Infrastruktur etwa mit Hilfe von Soap erfolgen soll und die Performance nicht ausschlaggebend ist,

- Corba-Spezialisten fehlen.