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/Ein IBM-Plädoyer für plattformunabhängige Middleware

"Corba integriert heterogene Welten"

CW: Gibt es einen Middleware-Krieg?

Weyerhäuser: Wir betrachten dieses Thema nicht aus diesem Blickwinkel. Es existiert ja noch nicht einmal eine genaue Definition für Middleware. Was es gibt, sind Produkte, die in diversen Szenarien unterschiedlich gut einsetzbar sind.

CW: IBM würde also auch Microsoft-Techniken wie DCOM einsetzen?

Weyerhäuser: Das ist für uns kein Religionskrieg. Im Servicebereich setzen wir auch Technologien ein, die nicht von IBM stammen. Wenn DCOM bereits im Einsatz ist und bleiben soll, werden wir uns nicht dagegenstellen.

CW: Woher kommt die Polarisierung Corba versus DCOM?

Weyerhäuser: Ich halte sie für ein Mißverständnis, das auf einer unzulässigen Einengung basiert. DCOM ist Microsofts Implementierung für die Kommunikation zwischen verteilten COM-Objekten. Dem entspricht in etwa der Object Request Broker (ORB) aus der Corba-Architektur, deren Frameworks und Dienste über die Objektkommunikation hinausreichen.

CW: Ließe sich Microsofts Broker in die OMG-Architektur integrieren?

Weyerhäuser: Selbstverständlich. Die Object Management Group (OMG) hat eine entsprechende Spezifikation erarbeitet. Das Ziel dieser Organisation ist es ja gerade, eine Architektur für eine heterogene DV-Welt zu definieren, zu der auch Microsoft gehört. Das funktioniert allerdings nur, wenn man diese Aufgabe nicht nur einem Hersteller überläßt.

CW: Das Verhältnis zwischen Microsoft und der OMG gilt als gespannt.

Weyerhäuser: Das kann ich so nicht bestätigen. Microsoft ist Mitglied in der OMG, und Bill Gates hat erst kürzlich bestätigt, daß Corba heute und auch in der Zukunft seinen festen Stellenwert hat. Ich denke, er weiß genau, welche Funktionalität darin steckt, und stellt sich darauf ein.

CW: Sie reden, als habe sich der Object Request Broker längst allgemein durchgesetzt.

Weyerhäuser: Der ORB an sich ist heute eigentlich nicht mehr Gegenstand der Diskussion. Das ist in etwa so, als ob Sie sich über nebensächliche Unterschiede in den TCP/IP-Implementierungen einzelner Hersteller streiten wollten. Hauptsache ist, daß der Standard akzeptiert ist.

Das ist bei Corba nicht anders, zumal die darauf beruhenden ORBs, bezieht man IIOP ein, tatsächlich eine standardisierte, objektorientierte Variante eines TCP/IP Protokolls darstellen.

CW: Wo ist der Bedarf für eine Objektvariante von TCP/IP?

Weyerhäuser: Die Kapselung hilft dem Entwickler. Er muß sich bei der Programmierung nicht mehr um die darunter liegende Infrastruktur kümmern. Er arbeitet auf Anwendungs- und nicht auf Netzwerkebene. Für den Anwender ist wichtig, daß ORBs heute überall real verfügbar sind und funktionieren.

CW: Das Web ist doch ein TCP/ IP-Netz. Wenn der ORB ein gekapseltes TCP/IP ist, wozu brauche ich dann noch ein Internet-Inter-Orb-Protocol (IIOP)?

Weyerhäuser: IIOP ist ein Protokoll auf Basis von TCP/IP und dessen eigentliche Kapselung. Das IIOP-Protokoll definiert im wesentlichen, wie die Objekte verpackt werden müssen, damit man sie auf einer Leitung versenden kann.

CW: Wie wichtig ist in diesem Zusammenhang Java?

Weyerhäuser: Für mich ist das Phänomen Java der beste Beweis für die Flexibilität von Corba. Heute gibt es etliche ORBs, die in Java implementiert sind. Außerdem lassen sich Corba-Objekte mit Hilfe der Java-Applet-Technologie wunderbar verteilen.

CW: Worin ergänzen sich Java und Corba?

Weyerhäuser: Corba befreit von der Abhängigkeit von Betriebssystemen, Programmiersprachen und Objektmodellen. Im Rahmen von "write-once, run-everywhere" erleichtert Java die Implementierung von Corba-konformen Produkten erheblich. Damit trägt Java wesentlich zur Verbreitung von Corba bei.

CW: Eine Grundsatzfrage: Was ist eigentlich so wichtig an der momentan so hitzig geführten Middleware-Diskussion?

Weyerhäuser: Der Nutzen von Middleware ist unumstritten. Sie erspart dem Entwickler die Kenntnis vieler technischer Details. Optimalerweise programmiert er auf Anwendungsebene. Doch es gibt viele unterschiedliche Middleware-Produkte, deren Integration den Anwender viel Zeit und Geld kostet. Hier versucht Corba zu helfen.

CW: Können Sie konketer werden?

Weyerhäuser: Im Client-Server-Zeitalter sollen die Anwender von Front-end-Systemen aus auf die Unternehmens-DV zugreifen. Aber während die Produktzyklen im Back-end vergleichsweise langsam sind, können die Desktop-Systeme sehr schnell wechseln. Ein Datenbanksystem bleibt manchmal Jahrzehnte in Gebrauch, am PC dagegen geschieht der Zugriff mal über Gateways, mal über ODBC und inzwischen auch über Browser. Diese häufigen Wechsel führen dazu, daß die Entwickler mehr damit beschäftigt sind, Protokolle und Verbindungen zwischen Protokollen zu programmieren als mit den eigentlichen Anwendungsprojekten. Corba hat sich als einzige Architektur auf Basis eines offenen Standardisierungsprozesses in Richtung einer Integrationsplattform dieser Middleware-Welten entwickelt und wird sich in Zukunft weiter in diese Richtung entwickeln.

CW: Wo liegt die Vereinfachung?

Weyerhäuser: Der Sinn und Zweck der Corba-Architektur besteht darin, daß man sogenannte Business-Objekte von der Stange kaufen kann. Dabei ist nicht auszuschließen, daß diese Komponenten auf existierender Middleware aufsetzen. Sinnvoll ist zum Beispiel, den Naming Service von Corba auf Basis von DCE zu implementieren. Die Implementierung des Corba-Persistenz-Services werden Anwender wahrscheinlich auf eine relationale Datenbank stützen wollen. Der Vorteil für Entwickler liegt auf der Hand: Er kann heterogene Services auf der Basis eines einheitlichen Programmiermodells in eine homogene Welt überführen.

CW: Sie sprechen jetzt über die Interface Definition Language von Corba?

Weyerhäuser: Alle Komponenten der OMG-Architektur werden über IDL definiert. Angefangen beim ORB selbst über die Corba-Services bis hin zu den eigentlichen Geschäftsobjekten. IDL ist die Grundlage für das gemeinsame Programmiermodell.

CW: Was meinen Sie mit Grundlage?

Weyerhäuser: Die IDL beschreibt zum Beispiel Geschäftsobjekte in einer von Programmiersprachen unabhängigen Weise. Solche Geschäftsobjekte beschreiben, wie ein Unternehmen arbeitet. Hier sollte man sich nicht von einer Programmiersprache abhängig machen. Als die IDL eingeführt wurde, war von Java keine Rede. Heute ist die Sprache eingebunden, ebenso wie C++, C, Cobol oder Smalltalk. Die in den verschiedenen Sprachen geschriebenen Objekte können zudem reibungslos kooperieren.

CW: Es heißt, es sei schwierig, mit der IDL umzugehen.

Weyerhäuser: Mit der IDL umzugehen ist überhaupt nicht schwierig. Sie dient lediglich der Definition eines Objekts. Die eigentliche Geschäftslogik wird dann in einer anderen Programmiersprache erledigt.

CW: Woher kommen dann die Klagen?

Weyerhäuser: Wer IDL für schwierig hält, der kann Werkzeuge benutzen, die automatisch IDL generieren.

CW: Wenn alles so einfach ist, warum etabliert sich die Corba-Architektur so zäh, während viele Entwickler gern zu den Visual-Basic basierenden Microsoft-Techniken greifen?

Weyerhäuser: Microsoft hat auf diesem Gebiet bislang nur wenig erreicht. Mit der Portierung von DCOM durch die Software AG wurde lediglich die Kommunikationsschicht auf anderen Plattformen verfügbar. Für die darauf aufbauenden Dienste gilt das noch nicht. Außerdem fehlt es an Robustheit, Skalierbarkeit und Sicherheit für eine unternehmensweite Architektur.

CW: Gerade auf diesen Markt zielt aber die Software AG.

Weyerhäuser: Ich bin gespannt, wie die Software AG hier Erfolg haben will.

CW: Läßt sich denn mit einer Konsortialtechnik wie Corba eine einheitliche Architektur aufrechterhalten? Will nicht jeder Anbieter Kunden mit Optimierungen an sich binden?

Weyerhäuser: Was Sie hier als Schwachstelle darstellen, ist in Wirklichkeit eine Stärke der Corba-Architektur. Sie fördert unterschiedliche Implementierungen. Dafür ist über eine standardisierte Schnittstellen-Beschreibung die Offenheit garantiert.

*Markus Weyerhäuser ist IBMs technischer Leiter für den europaweiten Support des Component Brokers, der Corba-Implementation von Big Blue, mit Sitz in La Gaude, Frankreich.