Das Entwickeln von Anwendungen für verteilte Umgebungen macht sich eine vermittelnde Software-Infrastruktur zwischen Betriebssystem und Anwendung zunutze: Sie ermöglicht die Interoperabilität zwischen Objekten in einem verteilten Rechnernetz. DCOM und Corba basieren beide auf einem Objektmodell, und sie gehen vom gleichen Grundgedanken aus, nämlich einen Standard für die netzweite Kommunikation zwischen Objekten zu definieren.

Die Object Management Group (OMG) ist eine Interessengemeinschaft von mittlerweile rund 750 Unternehmen, die seit 1989 an einem Standard für objektorientierte und verteilte Umgebungen arbeitet. Schlüsselkomponente ihrer Object Management Architecture (OMA) ist die Common Object Request Broker Architecture (Corba), deren Spezifikation 1991 angenommen wurde.

Mit der Ausgabe 2.0 von Corba definierte die OMG 1994 die Interoperabilität zwischen Objekten in heterogenen Systemen. Das kürzlich vorgestellte Corba Internet Inter ORB Protocol (IIOP) garantiert jetzt auch Corba-Interoperabilität über das Internet.

Wichtig im Zusammenhang mit Corba ist, daß es sich dabei lediglich um die Spezifikation einer offenen Architektur und nicht um eine Implementierung, also ein fertiges Produkt handelt. Ziel der OMG ist es, übergreifende Standards für Entwickler zu definieren: Es geht dabei also eher um das Finden eines möglichst offenen kleinsten gemeinsamen Nenners für die objektorientierte verteilte Welt.

Auf der Gegenseite steht Microsoft mit dem Konzept DCOM, das aus der Technik Object Linking and Embedding (OLE) entstand. Das Kommunikationsmodell von OLE2 für die einfache Kommunikation zwischen Windows-Anwendungen erhielt später den Namen COM, Component Object Model.

Um auch die Kommunikation zwischen Komponenten im Netzwerk zu ermöglichen, entwickelte Microsoft das sogenannte Distributed COM oder DCOM. 1995 tauchte im Zusammenhang mit COM und DCOM auch der neue Begriff "Active X" auf: Dies ist der Sammelbegriff für die DCOM/ COM/OLE-Technologie, und "Active X Controls" sind die früheren "OLE Controls". DCOM wird jetzt mit Windows NT 4.0 ausgeliefert und ist auch für Windows 95 erhältlich. Es handelt sich nach derzeitigem Stand im Kern um ein proprietäres Lösungskonzept.

Bei Corba stand von Anfang an der Gedanke der Offenheit, Skalierbarkeit und Plattformunabhängigkeit im Vordergrund. Corba-Implementierungen laufen unter praktisch allen Unix-Varianten, OS/2, OS/400, Mac-OS, VME, MVS, VMS sowie MS-DOS, 16-Bit- und 32-Bit-Windows. Corba-basierte Produkte unterstützen heute sogar mehr Microsoft-Plattformen als DCOM beziehungsweise Active X.

Ein Grund dafür liegt auch in der Tatsache, daß Microsoft seine Sourcecodes nur zögerlich freigibt. Diese Haltung ist Wasser auf die Mühlen der Corba-Befürworter, die DCOM als proprietäre Lösung brandmarken. Active X gilt zwar als ein neutrales Interface und als Oberbegriff für eine Reihe von Interfaces des Component Object Models, jedoch sind die Spezifikationen von Active X nicht hinreichend bekannt.

Tendenzen in Richtung einer Öffnung gibt es allerdings auch bei DCOM: Inzwischen liegt die Weiterentwicklung von DCOM bei der Active Group beziehungsweise der Open Group, und erste Unix-Implementierungen sind bereits auf dem Markt. Microsoft hat beispielsweise die Firma Software AG beauftragt, die DCOM-Technologie auf verschiedene Unix-Systeme, AS/400 und MVS zu portieren. Eine erste Betaversion liegt für Suns Solaris vor.

Im Gegensatz zur ständigen Erweiterung von COM/DCOM ist Corba keine aus dem PC-Windows-Umfeld weiterentwickelte Technologie, sondern eine von Anfang an objektorientierte, offene Architektur, die Object Model Architecture (OMA). Corba ist der Versuch einer formalen Spezifikation: Sie gibt Hinweise, wie die offene, objektorientierte Architektur in verschiedenen Sprachen und Umgebungen umzusetzen ist.

Hier hilft die Interface Definition Language IDL, Schnittstellen zu definieren, wobei allerdings diese Definitionen nie so präzise sind wie eine tatsächliche Implementierung. Bei Microsofts DCOM hingegen ist die Referenzimplementierung immer NT.

Auch bei der Unterstützung verschiedener Programmiersprachen zeigen sich deutlich die Unterschiede zwischen DCOM und Corba: Das Programmiermodell hinter COM und DCOM ist eng mit C++ verknüpft, was die Unterstützung anderer Sprachen erschwert. So werden beispielsweise Zeiger (Pointer) zwischen die Objekte und Anwendungen gesetzt, während Programmiersprachen wie Cobol oder Java keine Pointer kennen.

Corbas sprachneutraler Ansatz bietet hier mehr Offenheit: Die OMG hat Spezifikationen von C, C++, Ada, Smalltalk, Cobol und Java übernommen, und einige Corba-Produkte unterstützen weitere Sprachen wie Visual Basic oder Fortran. Vor allem die Cobol-Unterstützung ist ein wichtiges Argument für Corba, denn diese Sprache ist nach wie vor in allen professionellen Umgebungen sehr verbreitet.

Ein Pluspunkt von Corba ist die höhere Sicherheit: Nicht ohne Grund setzen Unternehmen wie Banken, Versicherungen und Behörden Corba-Implementierungen bereits seit mehreren Jahren für sicherheitskritische Anwendungen ein. Offene, verteilte Anwendungen, Kommunikation und Datenaustausch über weltweite Netze bedeuten generell ein hohes Sicherheitsrisiko, und die Frage ist hier, welche Technologien ein Höchstmaß an Sicherheit bieten.

Für finanzielle Transaktionen bedeutsam ist neben der üblichen Autorisierung und Authentifizierung sowie möglichen Verschlüsselungen noch die sogenannte "Non-Repudiation", also die Unmöglichkeit einer nachträglichen Zurückweisung der Transaktion. Die OMG-Security-Service-Spezifikationen bieten die notwendige Sicherheit für Electronic Commerce in verteilten Umgebungen.

DCOM besitzt bisher noch keine vollständigen Services für die sichere Kommunikation zwischen Objekten. Abhilfe soll hier allerdings der Microsoft Transaction Server schaffen. Dies ist ein offener, flexibler Container für Server-Komponenten, der das Entwickeln zuverlässiger, skalierbarer und verteilter Anwendungen auch im "Mission-critical"-Bereich erleichtern soll.

Die Anforderung an Skalierbarkeit ist in beiden Modellen noch nicht optimal gelöst, vor allem wenn es um sehr große Netze geht. Probleme bereiten hier nach wie vor Übertragungsfehler, etwa das Blockieren von Leitungen beim Verschicken von Objekten. Corba ist allerdings für die Kommunikation und Interoperabilität von Objekten in großen LANs, WANs und Internet-weiten Anwendungen konzipiert. DCOM beziehungsweise Active X sind von Haus aus für den Desktop und nie für den Einsatz in großen Netzwerken entwickelt worden.

Was die Unterstützung für das World Wide Web anbelangt, hat Corba derzeit Vorteile gegenüber DCOM: Corba unterstützt bereits Java, die sich als die Programmiersprache für die plattformunabhängige Web-Technologie etabliert hat. Java bietet Cross-Plattform-Unterstützung für Dutzende von Plattformen bis zu IBM-Mainframes: Dazu müssen Browser nur die Java Virtual Machine (JVM) implementieren.

Corba erlaubt eine direkte Verbindung mit Java über ein sogenanntes "Orblet", das selbst in Java geschrieben ist: Dieser Corba-Zugang läßt sich in den Browser laden, und dann können Java-Applets, die in Web-Browsern laufen, direkt mit Corba-Objekten - die in irgendwelchen Programmiersprachen geschrieben sind - kommunizieren.

Solche Objekte können beispielsweise andere Anwendungen oder OMG Object Services für Sicherheit, Transaktionsunterstützung, Naming und Event-Management sein. Corba-Orblets gibt es von vielen Herstellern.

Bei allen Vorteilen von Corba haben Active X und DCOM gleichwohl eine Reihe von Stärken:

Wenn es um das schnelle und einfache Entwickeln von Anwendungen in Microsoft-Umgebungen geht, ist DCOM die beste und benutzerfreundlichste Plattform. Im Prinzip lassen sich mit Active X und DCOM per Mausklick echte verteilte Anwendungen mit grafischen Oberflächen entwickeln. DCOM stellt dem Entwickler einen kompletten Baukasten mit Objekten zur Verfügung, mit denen er sehr schnell fertige Business-Lösungen realisieren kann. Hinzu kommt, daß DCOM bereits mit NT und Windows 95 geliefert wird.

Corba eignet sich demgegenüber eher für komplexere Anwendungen in größeren, heterogenen Umgebungen mit höheren Anforderungen an die Sicherheit. Diese Leistungsfähigkeit hat allerdings auch ihren Preis. Corba-Entwicklungen sind aufwendiger und komplizierter, sie verlangen erheblich mehr Programmier-Know-how.

Nachteilig für die Durchsetzung des Corba-Standards wirkt sich die Tatsache aus, daß es sich bei der OMG um ein sehr großes, buntgemischtes Gremium unterschiedlichster Interessengruppen handelt: Das verzögert die Entscheidungsprozesse und damit auch die schnelle, marktnahe Definition von Schnittstellen sowie die Verabschiedung von Spezifikationen. Häufig ist der Markt schon einige Schritte weiter, und die OMG bemüht sich nachträglich um eine Standardisierung. Umgekehrt bei Microsoft: Hier profitieren die Anwender von den schnelleren Reaktionsmöglichkeiten des Herstellers auf den Markt und dessen Anforderungen.

Keine Alternative ohne strategische Nachteile

Für den Kunden heißt dies auch: Abhängigkeit von einem Hersteller. Für kleinere und mittlere Unternehmen, die voll auf Microsoft setzen, muß dies kein Nachteil sein. Wer sich innerhalb der Microsoft-Welt bewegt, erhält mit DCOM eine sehr gute und zudem kostengünstige Plattform. Wer viele grafische Oberflächen entwickelt, ist mit DCOM gut beraten.

Wer viele Cobol-Entwicklungen im Unternehmen hat, dessen Wahl wird auf Corba fallen. Eine entscheidende Rolle spielt die eingesetzte Plattform: Bei PCs kommt DCOM in Frage, bei Unix- und Mainframe-Umgebungen ist man mit Corba auf der sicheren Seite.

Corba ist derzeit die offenere und flexiblere Plattform, denn sie kann DCOM integrieren, aber nicht umgekehrt: Corba "kennt" DCOM, aber DCOM kennt Corba nicht. Es ist also auch kein Problem, beide Plattformen im Unternehmen einzusetzen und zu nutzen.

DCOM wird aber auch für große, heterogene Unternehmen interessant, weil sich Windows 95 oder NT als Client-Plattformen durchsetzen. Versuche, DCOM- und Active-X-Implementierungen auf Großrechner zu portieren, verliefen bisher jedoch nicht problemlos.

Angesichts dieser Entwicklungstendenzen wird es entscheidend darauf ankommen, ob und inwieweit Microsoft mit der OMG zusammenarbeitet. Ansätze einer Verständigung zwischen Microsoft und der OMG gibt es bereits: Auf dem aktuellen OMG-Meeting im August 1997 in Dublin soll der Vorschlag eingebracht werden, DCOM und Corba in einem COM-to-Corba-Modell zu integrieren.

Angeklickt

Konkurrierende Interessengruppen und Unternehmen blockieren bis jetzt noch eine gemeinsame Richtung für objektorientierte Middleware-Standards. Auf der einen Seite steht die Object Management Group mit ihrer Common Object Request Broker Architecture (Corba), auf der anderen Seite Microsoft mit dem Distributed Component Object Model DCOM. Die Polarisierung der Meinungen zu den beiden Objekttechnologien führt zu einer Verunsicherung des Anwenders: Welchen Weg soll ein Unternehmen einschlagen, das seine IT-Architektur vereinheitlichen möchte?

*Ulf Lindquist ist Technical Director und Geschäftsführer der Norcom Informationstechnologie und Unternehmensberatung GmbH in München.