Das Component Object Model (COM) von Microsoft und die Konsortialtechnik Common Object Request Broker Architecture (Corba) sind vergleichbare objektorientierte Softwaretechnologien, die beide den Betrieb verteilter Anwendungssysteme auf der Basis von Softwarekomponenten unterstützen. Für diese Technologie hat sich der Begriff Componentware eingebürgert. COM- und Corba haben zu einer Polarisierung der Herstellerfirmen in zwei konkurrierende Lager geführt.

Gegensätzliche Designansätze

Die Vorläufer jetziger COM- und Corba-Implementierungen wurden 1992 etwa gleichzeitig in den Markt eingeführt: Version 2 von Microsofts Object Linking and Embedding war bereits der späteren COM-Architektur verpflichtet. Die von der OMG definierte Version 1.0 wurde von mehreren Herstellern allerdings in nicht miteinander kompatibler Weise implementiert. Insofern ist COM keine Reaktion von Microsoft auf Corba, wie manchmal zu hören ist, sondern eine Parallelentwicklung. Dabei ist zu beachten, daß beide Technologien unterschiedliche Designziele hatten. Die Corba-Spezifikation zielte darauf ab, objektorientierte Anwendungssysteme nicht mehr auf einen Rechner zu beschränken, sondern ihre Verteilung auf verschiedene Rechner und Betriebssysteme unterschiedlicher Hersteller zu ermöglichen. Deswegen war die Corba Interface Definition Language (Corba-IDL) das erste Ergebnis der OMG-Arbeit. Damit wurden die Grenzen der Programmiersprachen, die die Corba-Entwickler vorrangig im Sinn hatten, nämlich C und C++, erweitert. Systemplattform war vor allem Unix. Die SOM-(System-Object-Model-)Implementierung von IBM war jedoch schon bald auch für OS/2, MVS und MacOS verfügbar. Heute gibt es sie zudem für Windows und Windows NT.

Das Designziel von COM war ganz anders. Zunächst entwickelte Microsoft die OLE-Technologie, um die Bestandteile des hauseigenen Office-Pakets in die grafische Windows-Oberfläche zu integrieren. Die OLE-Technologie litt jedoch unter Einschränkungen, zum Beispiel hinsichtlich des Datentransfers mit DDE (Dynamic Data Exchange), die besonders für Softwarehäuser schmerzhaft waren, wenn sie Produkte unterschiedlicher Herkunft bei ihren Kunden binär integrieren wollten. Deswegen wurde OLE 2 als Nachfolgetechnologie herausgebracht. Gleichzeitig faßte man die Basisfunktionen zu der eigenständigen Implementierungsbasis COM zusammen, nämlich Funktionen wie

- Structured Storage (logische Speicherplatzverwaltung),

- Monikers (logische Namen für den Aufruf anderer Komponenten) und

- Uniform Data Transfer (einheitlicher Datentransfer über COM-Interfaces).

Anders als OLE war COM von Beginn an unabhängig von der grafischen Oberfläche und konnte vor allem seine Services für beliebige Programme bereitstellen. Zudem waren die COM-Services unabhängig von den Programmiersprachen der Komponenten, denen sie ihre Dienste anboten. Mit Hilfe der COM-Plattform entwickelte sich der Markt der OLE Controls, auch OCX-Komponenten genannt. Mit Windows NT, Version 4, wurde COM um den MRPC (Microsoft Remote Procedure Call) ergänzt, daher der Name DCOM (Distributed COM). Damit ließen sich COM-Services transparent über Netze nutzen. Heute wird die gesamte Technologie mit Active X bezeichnet, und man spricht von Active-X-Controls oder Active-X-Komponenten. Für diese Technologie hat Microsoft inzwischen unter dem Namen DNA (Windows Distributed Internet Architecture) ein übergreifendes Konzept erstellt. Die gesamte Active-X-Technologie hat sich von Beginn an aufwärtskompatibel entwickelt.

Vererbung von Klassenmerkmalen

Ein kontroverses Feld in dieser Diskussion ist die Vererbung. Dabei läßt sich zwischen Implementierungs- und Interface-Vererbung unterscheiden. Beides sind Verfahren zur Wiederverwendung von Code. Diese wird bei der klassischen Objekttechnik durch Implementierungsvererbung ermöglicht: Im Rahmen von Klassenbäumen erbt ein Objekt Merkmale von einem anderen aus der darüberliegenden Klasse. So erbt zum Beispiel die Klasse Lastwagen die Eigenschaften der Klasse Kraftfahrzeug. Dieser Mechanismus funktioniert aber nur auf der Basis von Quellprogrammen und nur dann, wenn alle Klassen in der gleichen Programmiersprache geschrieben sind. Daher rührt das florierende Geschäft mit Klassenbibliotheken etwa für Java oder C++.

Diese Sprachabhängigkeit erfüllt aber nicht die Bedingungen für einen Markt mit binären Komponenten**. Hersteller von Standardsoftware liefern ihre Komponenten nicht im Quellenstatus an Kunden aus. Auch werden Anwender nicht in der Lage sein, ihre Softwarebibliotheken auf eine einheitliche Sprache umzustellen, um Wiederverwendung mit Klassenbibliotheken zu betreiben. Damit bleibt die Anwendung der Implementierungsvererbung auf geschlossene Entwicklungsprojekte beschränkt.

Vererbung von Schnittstellen

COM unterstützt dagegen die Interface-Vererbung, auch Delegation oder Aggregation genannt. Delegation findet statt, wenn in einer Komponente A Methoden (Funktionen) benötigt werden, die eine bereits vorhandene Komponente B bietet. B vererbt ihre Methoden dann, indem A nach außen ein Interface für den Methodenaufruf B anbietet, aber den Aufruf an B zur Bearbeitung weiterleitet. Aggregation ist eine Variante dieses Mechanismus. In beiden Fällen kommt wieder die Grundeigenschaft von COM zum Tragen: Die Interface-Vererbung funktioniert mit binären Komponenten, unabhängig von der Programmiersprache, mit der sie erstellt wurden. Hier bietet die COM-Technologie einen entscheidenden Vorteil für den sich entwickelnden Komponentenmarkt.

Bevor COM mit Windows NT 4.0 erstmals die Grenzen eines Rechners überschritt und die Client-Server-Kommunikation unterstützte, wurde es für verteilte objektorientierte Anwendungen nicht in Erwägung gezogen. Verteilte Anwendungen werden bislang meist mit Corba-Technologie entwickelt. Deshalb gibt es heute bereits eine große Zahl von Anwendungen, die Corba nutzen, vorzugsweise in Unternehmen in der Finanzdienstleistungsbranche. Es handelt sich dabei aber überwiegend um individuelle Anwendungen, etwa im Handelsbereich, die gesamtheitlich geplant, mit einer durchgängigen Programmiersprache (meist C++) realisiert und auf Unix implementiert wurden. Damit entsprechen sie dem ursprünglichen Designziel von Corba. Sie sind oft Satelliten zu bestehenden Kernanwendungen, die auf Großrechnern laufen.

Corba-Anwendungen unterstützen auch nicht die direkte Kommunikation zwischen Softwarekomponenten. Eine Corba-Komponente muß immer über einen Object Request Broker (ORB) mit einer anderen kommunizieren. Dieses Vorgehen ist dann umständlich, wenn die Komponenten nicht über ein Netz verteilt sind, sondern auf nur einem Rechner laufen.

Der Komponentenmarkt verlangt jedoch, daß immer mehr in binärer Form vermarktete Softwarekomponenten unterschiedlicher Hersteller auf einem System integrierbar sind. Da Corba hier weder für die direkte Kommunikation noch, wie oben erläutert, für die Vererbung eine befriedigende Lösung bietet, sind diese Anbieter bisher kaum auf den Corba-Weg eingeschwenkt, sondern engagieren sich eher für COM und Active X.

Unternehmen mit Corba planen häufig, bestehende Unix-Lösungen um Windows-NT-Systeme zu ergänzen, zum Beispiel in Bankfilialen. Dafür gibt es einen einfachen Grund: Die Arbeitsplätze sind ohnehin zu 90 Prozent mit Windows-Clients ausgerüstet, die sich viel einfacher über COM-Services an Windows-NT-Server anschließen lassen als an Unix-Systeme.

Hinzu kommen Leistungsvorteile, die sich aus der im Vergleich zu Corba direkteren Kommunikation ergeben. Gleichgültig ob die gerufene Komponente im gleichen Adreßraum, in einem anderen auf der gleichen Maschine oder jenseits einer Netzwerkverbindung liegt - die rufende Komponente "merkt" keinen Unterschied. Vor allem erfolgt die Kommunikation zwischen ihnen, nachdem sie von den COM-Services aufgebaut wurde, als direkte Punkt-zu-Punkt-Kommunikation. Es liegen keine Servicekomponenten mehr dazwischen. In Corba-Systemen läuft die Kommunikation immer über einen Object Request Broker (ORB). Mit der Verfügbarkeit des IIOP (Internet Inter Orb Protocol) wird zwar die Kommunikation zwischen verteilten ORBs möglich. Dann jedoch liegen sogar mehrere ORBs zwischen den kommunizierenden Komponenten.

Wie dynamisch die Windows-Welt sich auch ausbreiten mag, Großrechner und Unix-Systeme werden weiter im Einsatz bleiben. Daher läßt sich eine Client-Server-Technologie nicht auf Windows beschränken, wenn sie den Anforderungen mittlerer und großer Unternehmen genügen soll. Microsoft verfolgt hier die Zero-Mainframe-Footprint-Strategie (ZMF). Das bedeutet, daß das Unternehmen selbst keine Software für Nicht-Windows-Systeme erstellt. Diese Aufgabe wird Partnern wie der Software AG überlassen, die zum Beispiel die COM-Plattform auf Unix- und Mainframe-Lösungen zu übertragen hat.

Damit steht COM als unternehmensweite Plattform für verteilte Anwendungen zur Verfügung, ohne damit jedoch Corba aus dem Markt zu drängen. Beide Techniken werden sich entsprechend ihrer jeweiligen Einsatzgebiete etablieren: Corba für unternehmensinterne Anwendungen und COM für die Komponententechnologie.

Die vollständige Bewertung der Komponententechnologie verlangt, das Phänomen Java aufzugreifen. Die Plattform für Java-Anwendungen heißt Java Virtual Machine (JVM). Es ist absehbar, daß diese auf den üblichen Rechnern verfügbar sein wird; auch auf Großrechnern. JVM ist also eine alternative Komponentenplattform zu COM. Ein Java-Applet kann auch zu einer Active-X-Komponente gekapselt und damit von anderen Active-X-Komponenten angesprochen werden, die in anderen Sprachen geschrieben sind. Damit fügt sich auch Java in die heterogene Sprachunterstützung des COM-Modells.

Pro und Comtra

Die CW-Schwesterpublikation "Infoworld" hat sowohl DCOM als auch Corba getestet. Dabei wurde die Microsoft-Technik mit Visual C++ auf Windows NT eingesetzt. Auf Corba-Seite hat man sich die Implementierungen von Iona und sowie IBMs Systems Object Model (SOM), Version 3, auf NT angesehen.

Corba:

Gesamturteil: Hervorragende Basistechnik, die schon über viele Funktionen verfügt und rasch vervollständigt wird. Die Implementierungen sind zwar gut, doch ist der Einbau von Diensten oft nach wie vor schwierig.

Viele Plattformen, Unterstützung aller wichtigen Programmiersprachen, Objekte können Dienste ohne Kenntnisse über deren Speicherort einbinden, statische und dynamische Einbindung von Methoden, Vererbung von Komponenten, hoher Sicherheitsstandard, zuverlässige Kommunikation zwischen verschiedenen ORBs, Fehlertoleranz.

Mögliche proprietäre Erweiterungen durch Anbieter, umfangreiche Befehlssätze der Implementierungen, Fehlen von Tools, nicht immer einfache Anbindung verschiedener ORBs.

DCOM:

Gesamturteil: Gute Basistechnik insbesondere für den Desktop. In verteilten Umgebungen treten jedoch teilweise schwer zu bewältigende Probleme auf. Um so besser ist die Ausstattung von DCOM durch Werkzeuge von Drittanbietern.

Windows-übliche Entwicklungswerkzeuge, große Auswahl an fertigen Active-X-Komponenten, Zugriff auf Methoden über Schnittstellen, Clients brauchen den Standort ihres Servers nicht zu kennen.

Derzeit noch auf wenig Betriebssystem-Plattformen, keine volle Vererbung, verschiedene Schnittstellen für statische und dynamische Methodeneinbindung, Fehlen robuster Features für das Last-Management, hoher Lernaufwand.

Angeklickt

Der Microsoft-Partner Software AG hat vor allem den sich entwickelnden komponentenmarkt im Blick, für den er COM besonders geeignet hält. Hier komme es mehr auf die performante Integration unterschiedlicher Komponenten auf einem Rechner an als auf die Kommunikation zwischen verteilten und heterogenen Umgebungen, für die Corba konzipiert ist. Diese Technik verlange die Einigung auf Standards, die nur innerhalb eines Unternehmens zu leisten sei, so daß die Einsatzmöglichkeiten auf diesen Bereich - etwa zur DV-Integration - begrenzt seien.

*Angelika Siffring ist Produkt-Marketing-Manager Middleware bei der Darmstädter Software AG. Das Unternehmen ist mit der Entire-Produktlinie schon viele Jahre im Middlewaregeschäft, hat als frühes Mitglied der Object Management Group (OMG) viel Erfahrung mit Corba-Techniken gesammelt, sich aber in den vergangenen zwei Jahren auf die Microsoft-Seite geschlagen und dessen Brokertechnik Distributed Component Object Model (DCOM) auf Unix und MVS portiert.

**Gegen diese Aussage spricht, daß Corba eine Interface Definition Language (IDL) zugrunde liegt, deren Aufgabe es ist, über Schnittstellen-Definitionen Objekte sprachunabhängig zu machen. Das heißt: Miteinander kommunizierende Corba-Objekte sehen voneinander nur die IDL-Schnittstellen. Ob sie in Java, C++, Cobol oder einer anderen Sprache geschrieben sind, ist gleichgültig. Auf entsprechende Rückfragen blieb die Autorin bei ihrer Aussage, räumte aber ein, die Sprachabhängigkeit beschränke sich auf die Vererbungsmechanismen von Corba (Anm. d. Red.).