Neue Version 2.0 des Corba-Standards fuer November 1994 Das Rennen um Marktanteile bei verteilten Objekten ist eroeffnet

14.10.1994

Kurz vor der geplanten Veroeffentlichung des neuen Corba-Standards 2.0 der Object Management Group (OMG) zeigten IBM, HP, Sun, Next und andere, dass die Zeit der verteilten Objekte gekommen ist. Im November soll die neue Spezifikation kommen, doch die Produkte sind schon da: DSOM von IBM, ORB-Plus von HP, DOE von Sun, insgesamt fast ein Dutzend. Martin Roesch* schildert die Konsequenzen fuer Anwender und Software-Industrie.

Im Juli 1994 waren sie schon live zu sehen: verteilte Objekte bei der Arbeit. IBM und HP zeigten die Bearbeitung von Reisekostenabrechnungen in einem Verbundnetz von Windows-, OS/2-, AIX- und HP-UX-Stationen. Sun, Iona Technologies, Postmodern Computing und andere hatten ein Netz von Unix- und Windows- Stationen aufgebaut und erfreuten die Besucher der Object World in San Franzisko mit einem verteilten Multimedia-Kartenspiel. Mehrere hundert Besucher stiegen ein: Spieltisch war das Computernetz. Die Software bestand aus verteilten Objekten nach dem kommenden Corba- Standard 2.0. Spieler, Kartendecks und einzelne Karten waren die Objekte, im Netz ueber zwei Dutzend Stationen gestreut.

Die OO-Welle hat wohl auch die Mainframe-Leute von IBM aus ihrem Schlaf geweckt: Mit Hochdruck treibt Big Blue die Renovierung der stark verstaubten Softwarelandschaft seiner Spitzenlinie jetzt voran. Noch in diesem Jahr sollen erste Betainstallationen von DSOM, dem Corba-Produkt der IBM, fuer MVS/Batch, TSO und IMS/DC bei Kunden installiert werden.

Es wurde auch hoechste Zeit fuer die IBM-Mainframes; denn die Vorteile verteilter Objekttechnik beginnen sich herumzusprechen, und das Fehlen von Objekten auf MVS und VSE faellt den Kunden immer unangenehmer auf. Das Interesse an objektorientierten Methoden, Werkzeugen und Vorgehensweisen waechst, und es wird deutlich, dass die Objektorientierung keine Eintagsfliege war und auch keine Modeerscheinung ist.

Wirtschaftliche Vorteile fuer die Objektpioniere sind bereits deutlich sichtbar. Der bisher krasseste Fall: Ein Wettbewerb zwischen AT&T und dem neuen Herausforderer MCI Communications, der eine Milliarde Dollar aus dem angestammten AT&T-Kundenkreis in seine eigenen Auftragsbuecher umleiten konnte - dank der Flexibilitaet und Aenderungsfreundlichkeit seiner objektorientierten Abrechnungssysteme, die den Erfolg des MCI-Kommunikationsproduktes "Friends and Family" moeglich machten. Der konservativere Platzhirsch AT&T brauchte ueber 18 Monate, um bei seinen alten Abrechnungssystemen technisch nachzuziehen.

Stabil sind Objekte im uebrigen auch: Vier der fuenf groessten Trader an der New Yorker Boerse arbeiten mit objektorientierten Systemen. Der groesste von ihnen wickelt acht Prozent des gesamten Umsatzes der Boerse ab.

"Object Orientation is here to stay" - in den USA richtet man sich bereits darauf ein. Denn nichts ueberzeugt so nachhaltig wie Erfolg. Die Amerikaner besitzen gut entwickelte Antennen fuer die Auswirkungen neuer Technologien und stellen sich schnell darauf ein. Erst wird ein griffiger Name gesucht, das war auch bei Corba nicht anders: "Enterprise Objects" kennzeichnet die neue Art von Objekten, die nicht mehr eingesperrt in einzelne Programme, sondern unternehmensweit benutzbar sind. "Bisher haben wir unsere Systeme aus den kleinen und kleinsten Objekten der Programmiersprachen gebaut", lautet die Erkenntnis, "wie aus Sandkoernern." Corba 2.0 macht den Weg frei fuer groessere Softwarebausteine, die man mit Fertigbauteilen vergleicht.

Enterprise Objects kennzeichnen in den USA den Trend, der auch in Deutschland erkennbar ist: weg von der "Objektorientierung im Kleinen", der objektorientierten Programmierung (OOP) mit C++, Smalltalk und Objectcobol, und hin zur "Objektorientierung im Grossen", objektorientierte Analyse (OOA) und Corba. Das bedeutet nicht, dass OOP in Frage gestellt wird, doch sie wird auf ihre tatsaechliche Bedeutung reduziert und in ihre angestammte Rolle als Implementierungswerkzeug wiedereingesetzt. Die Bauplaene werden mit OOA gezeichnet und mit Corba-Fertigteilen realisiert. Innerhalb der Fertigteile kann dann mit OOP programmiert werden. Das ist aber nicht zwingend: Wie Projekterfahrungen - auch bei deutschen Kunden - gezeigt haben, reicht auf dieser Ebene auch 3GL-Code aus.

Enterprise Objects sind fachliche Objekte. Ein fachliches Objekt zeichnet sich dadurch aus, dass es fuer Anwender unmittelbar verstaendlich ist. Solche fachlichen Objekte stammen aus der Welt der Anwender. Beispiele dafuer sind eine Bestellung, der zugehoerige Kunde sowie zwei Artikel, von denen eine bestimmte Anzahl mit je einer Zeile bestellt wurde.

Beispiel: "Bestellung 94/123: Drucke Dich". Vom Kunden Mueller holt die Bestellung 94/123 die Adresse und von den beiden Bestellzeilen deren Elemente: Anzahl, Beschreibung, Einzelund Zeilenpreis.

Eine Bestellzeile holt sich dazu die Beschreibung und den Einzelpreis von ihrem zugehoerigen Artikel. Die Anzahl weiss sie selber. Den Zeilenpreis bildet sie durch Multiplikation der Anzahl mit dem Einzelpreis, den sie vom Artikel bekommen hat.

Die Objekte sind in Klassen zusammengefasst. Das erleichtert die Handhabung, weil alle Objekte einer Klasse dasselbe Verhalten und die Wissensstruktur aufweisen. Corba 2.0 ermoeglicht, dass die sechs Objekte unseres Beispiels nicht alle auf derselben Maschine liegen muessen, sondern auf mehreren Maschinen, auch von unterschiedlichen Herstellern, verteilt sein koennen.

Von den bisherigen sprachenbasierten Objekten unterscheiden sich Enterprise Objects durch ihre Langlebigkeit: Sie existieren so lange, wie sie gebraucht werden. Fuer Objekte vom Typ "Kunde" koennen das Jahrzehnte sein. Ein Enterprise Object wird erst dann geloescht, wenn es fuer den Betrieb nicht mehr wichtig ist. Dass C++ seine Objekte schon nach wenigen Sekunden oder Minuten wieder wegwirft, wird erst durch die Enterprise Objects als Mangel deutlich.

Enterprise Objects sind aber nicht nur eine neue technische Moeglichkeit. Sie beeinflussen auch das Denken von Software- Entwicklern. Ihre Langlebigkeit gibt Anlass zu neuen Ueberlegungen fuer die Architektur von Softwaresystemen: Jetzt kann man ein Objekt vom Typ "Kunde" darauf einrichten, sich nach 30 Tagen zu melden, wenn eine Rechnung nicht bezahlt wurde. Entworfen wird diese inzwischen von "Smart Agents" her bekannte Funktion mit OOA. Mit Corba laesst sie sich nicht implementieren.

Dass diese Technik keine amerikanische Domaene ist, zeigen Projekte aus Deutschland und die internationale Aufmerksamkeit, die sie erfahren haben: Schon 1991 wurde hierzulande ein objektorientiertes System nach den Prinzipien der Enterprise Objects erstellt. Das Projekt wurde im Jahr 1992 in San Franzisko mit dem Object Applications Award ausgezeichnet.

1993 war es ein deutsches Consulting-Unternehmen, das weltweit als einziges (neben dem amerikanischen Geheimdienst CIA) auf den Object World-Konferenzen in Boston und San Franzisko Projekterfahrungen mit Corba und mit der Kombination von OOA und Corba vorzuweisen hatte.

Es ist auch ein deutsches Trainingsinstitut, das weltweit als erstes (seit 1992) die fuer die Enterprise Objects typische Verbindung von OOA und Corba in den Vordergrund stellte und in Kundenprojekten in die Praxis umsetzte. Wie man sieht, ist der technologische Abstand zwischen USA und Deutschland gar nicht so gross: Die USA sind nur zwei Jahre hinterher.

Corba 2.0 ergaenzt den seit 1992 bestehenden Standard Corba 1.1 der Object Management Group (OMG) um eine wesentliche Faehigkeit: Die Corba-Systeme der verschieden Hersteller (IBM, HP, Sun, DEC, Iona und andere) koennen nun mit einheitlichen Steckdosen und Steckern versehen werden. Die Systeme der ORB-Hersteller lassen sich jetzt so einfach wie Elektrogeraete miteinander verbinden (vgl. Kasten auf Seite 13). Fuer Anwenderunternehmen ergeben sich daraus zwei Vorteile. Zum einen wird die Client-Server-Programmierung erheblich vereinfacht: Da nur die Object Request Broker (ORBs) als Postverteiler miteinander verbunden werden muessen und diese Veknuepfungung auch noch ueber Corba 2.0 standardisiert ist, wird die Kommunikation von Objekten ueber mehrere Maschinen hinweg sehr stark vereinfacht. Fuer Anwendungsprogrammierer sieht das Senden einer Nachricht immer gleich aus - egal, ob das Empfaengerobjekt auf der gleichen oder einer anderen Maschine liegt. Das bedeutet, dass die bisher extrem hohen Programmieraufwaende fuer echte (das heisst kooperative) Client-Server-Verarbeitungen auf eine bezahlbare Groesse reduziert werden koennen.

Zum anderen ermoeglicht Corba 2.0 die Bildung von Standardsoftware- Bausteinen. Ein Anbieter kann mit Hilfe von Corba eine Reihe von zusammengehoerigen Klassen mit einem Teil-ORB in ein Paket packen und als Standardsoftware-Baustein verkaufen. Die Verbindung verschiedener Welten wird dadurch betraechtlich erleichtert. Der ORB des Bausteins wird an den ORB des Kunden angeschlossen - fertig.

Corba 2.0 oeffnet den Weg in die Softwarebaustein-Industrie, weil durch den Standard eine wesentliche Voraussetzung fuer die Bildung unabhaengiger Bausteine geschaffen wurde: Standardbausteine lassen sich nun ohne Programmierung miteinander verknuepfen. Die Elemente werden nach Corba 2.0 einen schnelleren und breiteren Markt finden als fruehere Standardsoftware-Angebote. Die Preise werden dadurch schneller sinken, was wiederum eine noch breitere Anwendbarkeit nach sich zieht, die ihrerseits wieder auf die Preise drueckt.

Anwender muessen sich auf Corba 2.0 vorbereiten, da die damit moegliche Verbindung mehrerer ORBs wie eine Telefonverbindung nach China wirken kann: Ich hoere chinesisch, in China kommt Deutsch an. Wir hoeren uns, verstehen aber nichts. In derartigen Problemen liegt die wichtigste Vorbereitungsaufgabe fuer die objektorientierte Softwarewelt.