Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

13.03.1998 - 

Middleware; COM versus Corba/Corba ist offen, DCOM findet viele Entwickler

Zwei Middleware-Standards ergänzen sich zu einer Lösung

Im Gegensatz zu der mittlerweile sehr schnell veraltenden Desktop-Hardware gelten für Software eigene Verfallsgesetze. Nicht nur ihre immaterielle Natur verlängert die Lebensdauer, sondern auch das zum Teil immense intellektuelle Potential, das nötig ist, um eine Anwendung hinreichend fehlerfrei zu erstellen. Angesichts der mittelfristigen Knappheit an qualifiziertem Personal können es sich die Industriegesellschaften einfach nicht mehr leisten, funktionierende Softwarelösungen nur wegen technischer Neuerungen bei der Hardware oder der Kommunikation über Bord zu werfen. In der Open Management Group (OMG) haben sich deshalb inzwischen über 760 Hersteller und Anwender zusammengeschlossen, um einen professionellen Konsens über zukünftige Entwicklungen zu schaffen.

Das bislang wichtigste Ergebnis der OMG ist die Definition der Common Object Request Broker Architecture (Corba). Dieses Regelwerk ist wiederum ein strategischer Bestandteil der Object Management Architecture (OMA), die den gesamten gedanklichen Rahmen für eine funktionierende Softwarekomponenten-Landschaft abstecken soll. Corba faßt dabei die Aspekte der Schnittstellen und der Kommunikation von Software-Objekten zusammen. Aktuell gilt die im August 1997 veröffentlichte Spezifikation Corba 2.1.

Um Mißverständnissen vorzubeugen: Die OMG schreibt keine Software, auch keine Referenzimplementationen. Sie überläßt dies vollständig der IT-Industrie, um so für einen professionell organisierten und globalen, offenen Markt zu sorgen.

Im Gegensatz zu Corba handelt es sich bei der Konkurrenztechnik Distributed Component Object Model ( DCOM) um einen von Microsoft festgelegten Privatstandard, der aber grundsätzlich ähnliche technische Ziele wie Corba verfolgt. Neben marketing- und emotionsbeladenem Pro und Contra gibt es auch einige für den Anwender tatsächlich bedeutsame Aspekte, die gegen ein hartes Entweder-Oder sprechen.

Herkunftsbedingt kommt Corba mit heterogenen Umgebungen hervorragend zurecht. Byte-Order, numerische Repräsentation und Abhängigkeit von bestimmten Betriebssystem-Aufrufen sollten für den Corba-Entwickler kein Thema sein.

Nicht zuletzt die in Java geschriebenen ORBs, etwa Visigenics "Visibroker for Java", Suns "Joe" oder der frei erhältliche "JacORB" http://www.inf.fu-berlin. de/brose/jacorb , verhelfen einer auf Corba basierenden Lösung zur sofortigen Einsatzfähigkeit auf fast allen nur erdenklichen Client-Plattformen. Ob Mac, PC oder Embedded System im Kaffeeautomaten - falls eine Java Virtual Machine vorhanden ist, kann Corba genutzt werden.

Ganz anders die derzeitige Perspektive von DCOM. Da es sich um einen evolutionären Microsoft-Standard aus der Windows-Welt handelt, können viele Entwickler auf existierendes Know-how und vorhandenen Code zurückgreifen, um Komponenten für DCOM zu erstellen. Angesichts der dominanten Verbreitung von Windows-Varianten auf Desktop-Systemen erschließen sie so ein attraktives Marktpotential für ihre neuentwickelten Active-X-Programme. Da es sich aber um weitgehend an das Win32-API angelehnte gewöhnliche Windows-Executables handelt, wird es nur in Einzelfällen Sinn machen, bestehenden Code auf andere Plattformen zu portieren.

Beiden Welten gemein ist die Verwendung von Beschreibungssprachen für die Objekt-Schnittstellen. Diese Interface Definition Languages (IDLs) legen unabhängig von der späteren Programmiersprache fest, welche Methoden und Parameter die Software-Objekte ausmachen. Beim Vergleich von Corba- und DCOM-IDL scheint ein ungleich größerer Beschreibungsaufwand auf der DCOM-Seite zu liegen. Dies ist bedingt durch die mehrfachen Interfaces, die ein DCOM-Objekt besitzen kann. Doch was zunächst schwierig aussieht, läßt sich durch eine geeignete integrierte Entwicklungsumgebung automatisch generieren. Nur bleibt auch dann der erzeugte IDL-Code wesentlich unübersichtlicher als bei der Corba-IDL, für die es im übrigen Generierungsautomatismen gibt.

Ähnlich stellt sich die Situation bei der Behandlung von Exceptions dar. Während Corba nach dem mächtige Exception-Mechanismus von C++ verfährt, erhält der DCOM-Programmierer 32-Bit-Binär-Returnwerte vom Typ HRESULT, die er mit IErrorInfo erst in sprachspezifische Exceptions umwandeln muß. Obwohl die DCOM-Lösung komplizierter aussieht, läßt sich ein vergleichbares Ergebnis damit erzielen - eine weitere Aufgabe für integrierte Entwicklungsumgebungen.

Auch die Identifikation von Objekten läuft bei Corba völlig verschieden von DCOM. Während Corba-Objekte auf einen hierarchischen Namensraum zurückgreifen, der sich auch in bestehende Directory Services abbilden läßt, benutzen DCOM-Objekte zur Identifikation eindeutige Objektnummern (UUIDs), die unabhängig vom Namen sind und daher auch mehrere Objekte mit identischen Namen zulassen. Ob dies vorteilhaft ist, muß jeder Anwender für sich entscheiden.

Ein oft zitierter Unterschied zwischen Corba und DCOM ist die Methode der Vererbung von Schnittstellen. Stark vereinfacht gesagt kann ein DCOM-Objekt mehrere Schnittstellen besitzen, während ein Corba-Objekt Schnittstellen vererbt. Was sich nach belangloser Semantik anhört, hat einen simplen Grund: Der Hersteller eines DCOM-Programms kann zu Beginn des Objektlebenszyklus einen eingeschränkten Satz von Methoden einbauen und ihn nach und nach erweitern, ohne Client-Programmierern Einblick in die Interna des Sourcecodes geben zu müssen.

Diese inkrementelle Methode entspricht der Microsoft-Philosophie, die schon bei der Entwicklung der SMB-Protokolle einen Protokollwirrwarr erzeugte, das erfolgreich zur Konfusion der Mitbewerber beitrug. Das gilt im übrigen auch für diverse Microsoft-Abteilungen, wie der Autor mehrfach feststellen konnte. Der Anwender bemerkt von solchen Problemen jedoch lediglich einen gewissen Overhead, der ihm auf gut ausgestatteten PC-Plattformen gleichgültig sein kann.

Für Systemintegratoren und Entwickler von Thin Clients stellt Overhead jedoch einen nicht zu unterschätzenden Kostenfaktor dar. Wie schon aus dem sehr schleppenden Heranwachsen funktionierender OLE-Komponenten in den letzten Jahren ablesbar, ist deren Programmierung komplex. Microsoft hätte demzufolge heute mit DCOM keine Chance, würde nicht schon seit 1993 das COM-Modell in die Köpfe der Entwicklergemeinde einsickern. Da dies schon weithin geschehen ist, läßt sich umgekehrt schließen, daß es heute bereits viele Programmierer gibt, die fähig sind, Active-X-Komponenten zu erstellen.

Die Corba-Seite hatte in der Vergangenheit ebenfalls ihre Stolpersteine zu überwinden: Bis zum Release von Corba 2.0 Mitte 1995 war die Interoperabilität verschiedener Implementierungen nicht gewährleistet. Erst dann begannen Entwickler sich ernsthaft mit Corba auseinanderzusetzen. Wegen des nicht unerheblichen Lernaufwands sind Entscheider verständlicherweise erst geneigt, ein Komponentenmodell für ihren Wirkungsbereich detailliert zu erlernen, wenn sie einen möglichst breiten Absatz für die daraus resultierenden Produkte erwarten können. Hier hat Microsoft wegen seiner schieren Marketing-Macht unbestreitbare Vorteile. Durch Suns Entscheidung, den eigenen ORB "NEO" in Zukunft durch die Visigenics-Produkte zu ersetzen, klärt sich langsam auch die Lage bei den Corba-Implementierungen. Auch Siemens-Nixdorf hat ein Lizenzabkommen mit Visigenics unterzeichnet und setzt auf diesen Trend.

Der Schlüssel zum Erfolg komponentenbasierter Software könnte letztlich weniger in der Verfügbarkeit geeigneter Teillösungen liegen als im intelligenten Management des Ausführungsorts. Ideal als Komplementär von Cluster-Technologien könnte beispielsweise eine Objekt-Transaktionsmonitor-Middleware nicht nur Load-Balancing, sondern auch Hochverfügbarkeit gewährleisten - beides Ziele von Clustering.

Besonders gut passen beide Konzepte hinsichtlich der Verteilung auf Anwendungsseite zusammen, weil auf diese Weise immer ausgefeiltere Cluster-Lösungen überflüssig werden. Auf der anderen Seite ist es nur eine Frage der Zeit, bis Server-seitige ORBs zum festen Bestandteil von Datenbank-Clustern werden. Alle Anbieter der "Komponente" Datenbank haben selbstverständlich größtes Interesse an einem breiten Marktzugang und sind gerade dabei, Corba sowie DCOM-Schnittstellen anzubieten.

Dem rein lösungsorientierten Nutzer geht es um ein kostengünstiges Ergebnis. Diese Haltung brachte die Diskussion um Fat oder Thin Clients ins Rollen. Dabei erwies sich, daß die Grenzen zwischen fetter Engineering Workstation und magerem Settop Client fließend sind und nur durch die Anwendungen bestimmt werden.

Gleichzeitig steigt durch die in Clustern stark verbesserte Skalierbarkeit der Server die Attraktivität von kostengünstigen Thin-Client-Lösungen. In der typischerweise heterogenen Server-Welt ist das portable Corba das geeignete Mittel. Das Versprechen, komplette, völlig portable Java-Clients nach dem Prinzip "write once, run anywhere" erzeugen zu können, kann nur mit Hilfe von Corba und IIOP eingelöst werden.

Ein wichtiger Aspekt des Systemdesigns ist der Ressourcenverbrauch. Angesichts von Prozessorentwicklungen, die 10 MIPS pro Quadratmillimeter Chipfläche erreichen, rückt im Consumerbereich der Client für unter 100 Dollar in vorstellbare Nähe. Eine schlanke Corba-Implementation hat in diesem Segment gute Chancen, da sich durch die vielen offenen Sourcen eine Portierung schnell und unabhängig von Lizenzen eines Monopolisten durchführen läßt. Im extrem kostensensitiven Low-end werden nicht nur die Hardware-, sondern auch Engineering- und Lizenzkosten nach Zehntelcents optimiert.

DCOM hätte im Bereich schlanker Billigrechner nur eine Chance, wenn etwa die Kombination eines x86-Prozessorkerns zusammen mit einer Windows-CE-Lizenz weniger als zehn Dollar kosten würde. Davon sind wir heute noch weit entfernt. Bis das erste DCOM- oder Corba-fähige Mobiltelefon verfügbar ist, dürfte es angesichts der attraktiven Marge dennoch nicht mehr lange dauern. So hat Siemens gerade ein Lizenzabkommen für das schlanke Microsoft-Betriebssystem erworben.

Das implemententierungsunabhängige General Inter-ORB-Protocol (GIOP) erlaubt die Vorstellung, eine sehr schlanke Objektkommunikation aufzubauen. Das auf dem Remote Procedure Call (RPC) von DCE festgelegte DCOM hat dem derzeit nichts entgegenzusetzen. Ähnliches gilt für Echtzeitanwendungen: Während es sehr wohl denkbar ist, auf die weitverbreiteten Echtzeit-Kernel "VxWorks" oder "Psos" eine Corba-basierte Applikation aufzusetzen, wird DCOM hier nicht ernsthaft in Betracht gezogen.

Große Anbieter setzen auf beide Techniken

Für IT-Allrounder wie HP, IBM oder Siemens-Nixdorf ist es durchaus sinnvoll, beide Komponentenmodelle zu unterstützen, um alle Kundenwünsche zu adressieren. Auch die mit dem betriebswirtschaftlichen R/3-Paket, Release 3.1 von SAP mitgelieferte Technik für Business Objects ist grundsätzlich nach beiden Welten hin offen. Spezialisten wie Netscape oder Sun sind eher darauf angewiesen, offene Standards zu etablieren. So war es nur logisch von Netscape, in der aktuellen Version der Internet-Software "Communicator" bereits Corba 2 zu unterstützen. Der von Visigenics lizenzierte Visibroker for Java verhilft Netscape zu einem nahezu universellen Desktop-Client für die Corba-Welt, der weit über die derzeitigen Grenzen von DCOM und Active X einsetzbar ist.

Pikanterweise könnte die zunächst als Marketing-Schachzug abgetane Offenlegung der Communicator-Sourcen sogar jemanden auf die Idee bringen, Active-X-Unterstützung einzubauen, um den universellsten Client (für die Wintel-Welt) zu erhalten. Wer nicht solange warten möchte oder dem Kleingedruckten der Netscape-Offerte (zu Recht) mißtraut, kann auch das Netscape-Plug-in "ScriptActive" von Ncompass Labs einsetzen, das die Verwendung von Active-X-Controls im Netscape-Browser schon heute erlaubt http://www.ncompasslabs.com/scriptactive .

Offene Bekenntnisse zum entschiedenen Sowohl-als-Auch, wie die kürzlich erfolgte Lizenzierung von COM durch Iona oder das Comunity-Framework von Siemens-Nixdorf, stellen daher hauptsächlich eine pragmatische, lösungsorientierte Strategie dar. Es wird keinem Anbieter gelingen, einen vollständigen Satz von Komponenten für das eine oder andere Modell in kürzester Zeit anzubieten. Der Markt muß dies leisten - und da rühren sehr viele Köche im Brei.

Corba in Banken

Die Grundzüge von Corba lassen sich am besten an einem Beispiel verstehen, das bewußt aus dem Bankensektor ausgewählt ist: Eine auffallend große Zahl von Corba-Anwendungen und -Projekten existiert heute schon in diesem Bereich. Angenommen, eine Bank möchte die Arbeitsplätze seiner Anlageberater auf Komponentenbasis modernisieren, so wird dazu ein Software-Objekt benötigt, das Zugriff auf die zentral gelagerten Kundenstammdaten hat. Aber auch Software zur Berechnung und Darstellung verschiedener Rentenmodelle soll am Arbeitsplatz zur Verfügung stehen. Außerdem soll das Ganze in einer modernen, leicht benutzbaren Verpackung auf dem PC, NC oder X-Terminal des Beraters präsentiert werden.

Damit das grafische Front-end auf die Komponenten "Stammdaten" und "Rentenberechnung" zugreifen kann, benötigt es eine Methode, um die Komponenten zu aktivieren und mit ihnen zu kommunizieren. Hier kommt der ORB in Spiel. Er ist dafür verantwortlich - gleich einem Lotsen -, die Frage nach dem Wo und Wie zu beantworten. Befindet sich das gesuchte Objekt nicht in seinem Verwaltungsbereich, so kann er mittels GIOP weitere ORBs ansprechen, bis die Frage beantwortet ist. Läuft diese Kommunikation mittels Browser über ein TCP/IP-Netz, so kommt IIOP, die Internet-spezifische Ausprägung von GIOP, zum Einsatz.

Der Client, im gewählten Beispiel das grafische Front-end, braucht dabei nicht zu wissen, wo die jeweiligen Komponenten sind - ein klarer Vorteil dieses Verfahrens. So könnte der Zugriff auf die Stammdaten über das hausinterne Netz auf eine Mainframe-Datenbank erfolgen, möglicherweise sogar über einen zwischengeschalteten Transaktionsmonitor, wie Open UTM oder Tuxedo. Als Voraussetzungen müssen auf dem Mainframe eine Corba-fähige Datenbank-Schnittstelle vorhanden sein und ein ORB laufen. Viele Anbieter von Standard-Datenbanken haben sich bereits zu solchen Schnittstellen bekannt. Die Rentenberechnung könnte auf einem Unix-System erfolgen, das die Ergebnisse an den Client zur grafischen Darstellung weiterreicht.

Um auch DCOM-Clients einzubeziehen, gibt es Bridges, die beide Welten miteinander verbinden. Sie sind in ORB Plus Corba Connect von Hewlett-Packard enthalten. Es wäre also keineswegs ausgeschlossen, die Benutzeroberfläche eines Anlageberater-PCs als DCOM-Komponente zu erstellen, die gesamte Vorgangsintelligenz aber in Corba-Objekten auf Unix- oder Mainframe-Systemen ablaufen zu lassen.

Wegen der Effizienz der Entwicklungswerkzeuge ist dieses Szenario sogar möglicherweise schneller realisierbar als die zwangsweise Zusammenstellung aus Komponenten eines Typs. Da die Performance von Java-basierten Clients teilweise noch zu wünschen übrig läßt, wäre es vorstellbar, in einem ersten Schritt ein simples Visual-Basic-Interface zu "erklicken" und später auf eine Java-basierte Lösung mit NCs zu migrieren, die direkt in Corba kommuniziert.

Angeklickt

In einem nüchternen Vergleich der beiden Middleware-Techniken auch auf technischer Ebene kommt der Autor zu dem Ergebnis, daß die komplexe Realität in dden Anwenderunternehmen am besten mit Corba und DCOM abbildbar ist. Dabei zeigt er die Stärken und Schwächen aus Entwicklersicht inklusive deren Konsequenzen für die Anwender auf.

*Peter Averkamp ist freier Autor in München und hauptsächlich für die Unix-PCs der Technischen Universität om Garching bei München zuständig.