"Microsofts DCOM gilt gebenüber Corba als fast sicherer Sieger", wirbt die Londoner Ovum Ltd. für eine Studie mit dem Titel "Ovum Evaluates: Object Request Brokers" (vgl. CW Nr. 35 vom 29. August 1997, Seite 15: "Corba versus DCOM: "Beide Middleware-Konzepte sind noch unreif"). Von einer solchen Konfrontation zwischen dem Middleware-Modell von Microsoft und dem herstellerneutralen Gegenstück der Object Management Group (OMG) will die Autorin Rosemarie Rock-Evans heute nichts mehr wissen.
Die Vorwürfe des britischen Branchendiensts "Computergram" richten sich jedoch weniger gegen die Microsoft-Parteinahme als gegen eine Reihe sachlicher Mängel. Das gilt insbesondere für die mangelnde Aktualität der Informationen. So sei in dem 317 Seiten langen Report von vier Corba-Services die Rede, die um weitere acht erweitert werden sollen. Tatsächlich gibt es inzwischen jedoch 15 Services. Die Bezeichnung der Autorin dafür (COSS) sei offiziell zum letzten Mal vor drei Jahren verwendet worden. Auch die mit rund 500 angegebene Anzahl der OMG-Mitglieder entspricht ungefähr dem Wert vor zwei Jahren. Derzeit zählt die Organisation etwa 780 Members.
Das mögliche Scheitern des Corba-Standards begründete der Ovum-Report auch mit der mangelnden Unterstützung aus der Industrie. Genannt und untersucht wurden jedoch nur die Corba-Implementierungen von Sun, Bea Systems, Iona, Visigenic, IBM plus die Komponententechnik von Microsoft. Außen vor blieben die Object Broker von HP, Fujitsu, Chorus, Siemens-Nixdorf, ICL und anderen.
Als schlichtweg falsch bezeichnet "Computergram" die Behauptung, die Corba-Implementierungen würden nicht zusammenarbeiten. Genau das zeichnet jedoch alle korrekten Implementierungen der Version 2 von Corba aus, von denen es seit etwa zwei Jahren bereits eine Reihe gibt. Das australische Distributed Systems Technology Centre (DSTC) hat das zumindest für sieben der kommerziell verfügbaren Broker nachgewiesen.
Falsch, so der Branchendienst, ist auch die Ovum-Behauptung, daß die Erweiterung Internet Inter-ORB Protocol (IIOP) nicht funktioniere und zudem nur von IBM und Sun unterstützt würde. Vielmehr handle es sich dabei um ein recht simples und daher kaum fehleranfälliges Verfahren, das zudem von allen Corba-2-Anbietern verwendet werde.
Zu all diesen und weiteren Kritikpunkten nimmt die Autorin der Ovum-Studie in ihrer Replik keine Stellung. Statt dessen wehrt sie sich trotz der Ankündigung ihres Hauses, daß "DCOM über Corba triumphieren" werde, gegen die Verkürzung ihrer Ergebnisse auf die Konkurrenz von Corba und DCOM. Vielmehr habe sie gezeigt, daß die eigentliche Alternative zu Brokern nicht Microsofts DCOM, sondern Transaktionssysteme seien, wie sie von Bea oder NCR angeboten werden. Diese seien wesentlich einfacher zu programmieren und würden zudem mit Objekttechniken ausgestattet, die mit Corba und DCOM umgehen könnten. Tatsächlich verwendet zumindest Bea für Tuxedo die Corba-Implementierung von Digital Equipment und die vom selben Hersteller stammende DCOM-Brücke dazu.
Unwidersprochen ist bislang, daß Programmierung von Brokern alles andere als trivial ist. Zu Recht weist Rock-Evans darauf hin, daß Entwickler hier in der Regel mit etwa 700 Anwendungsprogrammier-Schnittstellen umgehen müssen.
Was nun die Rolle von Microsofts DCOM betrifft, so argumentiert Rock-Evans, daß es sich dabei vor allem um eine Technik für Unternehmen handle, die bislang keine Middleware-Strategie entwickelt haben. Derartige Aufgaben fielen in diesen meist kleineren, mit PC-Produkten ausgestatteten Firmen automatisch den Programmierern zu. Gerade dort profitiere Microsoft von seinem hochprofessionellen Marketing und einem auf PC-Entwickler ausgerichteten Schulungsprogramm. Aber selbst Firmen, die eine von DCOM abweichende Middleware-Strategie verfolgen, müssen mit der Microsoft-Technik als zusätzliche Komponente in einer heterogenen DV-Welt umgehen können.