Vor einem Jahr hat die OMG die ersten Corba-Standards vorgestellt. Corba 1.1 beschreibt, wie Object Request Broker arbeiten und wie sie fuer Programmierer aussehen. Zirka 60 Firmen arbeiten zur Zeit an Produkten, die dem Corba-Standard entsprechen werden.

Um an diesen erfolgreichen Start anzuknuepfen, hat das Technical Committee der OMG jetzt die Initiative ergriffen und mit einer Materialsammlung fuer die naechste Ausgabe des Corba-Standards begonnen. Das Dokument, das im Dezember in Orlando, Florida, verabschiedet wurde, fordert Anwender und Hersteller auf, ihre Wuensche und Anforderungen zu aeussern. Der Text ist ueber Roesch Consulting erhaeltlich.

Fragen an Hersteller und Anwender

Einige Fragen, zu denen die OMG Informationen von Anwendern und Herstellern wuenscht, sind:

- Wie ist die Einbindung von Multimedia-Anwendungen zu gestalten? Hier kommt es auf die genaue Synchronisation mehrerer Ein- und Ausgabeobjekte an.

- Wie koennen mehrere ORBs zusammenarbeiten?

- Fuer welche anderen Sprachen als C und C++ und in welcher Reihenfolge soll die Programmier-Schnittstelle zum ORB standardisiert werden?

- Welche Art und welcher Umfang von Transaktionssicherung wird gewuenscht?

- Welche anderen Standards sollten beruecksichtigt werden?

- Wie soll die Duplizierung von Objekten zum Beispiel aus Performance-Gruenden behandelt werden?

Dies sind einige der genannten Punkte, doch wird von der OMG ausdruecklich Wert darauf gelegt, dass die Liste offen ist. Also! Wer gute Ideen auf Lager hat: Jetzt ist die Zeit, sie in den neuen Standard Corba 2.0 einfliessen zu lassen.

Die Erfahrung hat gezeigt, dass viele Firmen in den letzten Jahren ORB-aehnliche Produkte fuer den Eigenbedarf entwickelt haben: Der Bedarf ist offensichtlich dringend, und die Loesung liegt in der Luft: Viele Teilnehmer unserer Objektorientierungs-Seminare waren erstaunt, Teile ihrer hauseigenen Systeme im ORB wiederzuentdecken. Dass dies keine Einzelfaelle sind, bestaetigt Richard Soley, Technischer Direktor der OMG: "Wir erfahren fast jede Woche von einem Anwenderunternehmen, das einen ORB oder etwas aehnliches fuer den Eigenbedarf erstellt hat".

Soviel zu den positiven Seiten. Doch hat die Arbeit der OMG auch andere Aspekte. Und die haben ihre Ursache darin, dass in der OMG und besonders in den Technical Committee Meetings die Hersteller gegenueber den Anwendern zur Zeit deutlich in der Mehrheit sind.

Damit besteht die Gefahr, dass Interessenkonflikte einseitig zu Lasten der Anwender geloest werden.

Ein solcher Gegensatz besteht zur Zeit bei der Austauschbarkeit von Hardware beziehungsweise Betriebssystemen. Anwender wuenschen eine moeglichst hohe Unabhaengigkeit von Traegersystemen (Hardware, Betriebssystem oder TP-Monitor), waehrend Hersteller - ganz im Gegenteil - eine moeglichst starke Kundenanbindung anstreben. Es ist offensichtlich, dass diese Ziele einander widersprechen.

Wenn die Anwender nicht staerkeren Einfluss in der OMG nehmen, besteht die Gefahr, dass eine fuer Anwender unguenstige Loesung 1994 Bestandteil des OMG-Standards Corba 2.0 werden kann.

Object Request Broker sind in der Lage, die Einfachheit der Objektorientierung von der objektorientierten Analyse bis hin zur Implementierung der fertigen Software zu erhalten. Informationssysteme werden fuer Menschen leichter verstehbar. Dadurch verhindern ORBs die Bildung von Objektinseln und die Vorteile der Objektorientierung kommen ungehindert zur Wirkung.

Die direkte Folge sind geringere Kosten, weniger Fehler und schnellere Fertigstellung. Dazu ein Beispiel:

Abbildung 1 zeigt einen Ausschnitt aus einer objektorientierten Analyse und wie ein Objekt Teilaufgaben an andere Objekte delegiert.

Auf dem Bildschirm ist eine Liste mit Rechnungen angezeigt. Eine der Rechnungen ist markiert, und der Benutzer hat einen Push- Button "Drucken" mit der Maus angeklickt. Das Ergebnis: (1) Die vom Entwickler fuer den Button festgelegte Nachricht wird an die markierte Rechnung geschickt.

Die Rechnung schickt ihrem zugehoerigen Kunden die Nachricht "Gib mir deine Adresse"(2). Danach wendet sie sich an ihre Rechnungszeilen mit der Bitte um die gesamten Daten jeder Rechnungszeile (3). Die Rechnungszeilen fragen hierfuer bei ihren Artikeln nach, wie die Beschreibung lautet(4) und wie hoch der Preis ist(5). Wenn alle Daten bei der Rechnung vorliegen, kann sie sich drucken(6).

Abbildung 2 greift das besprochene Beispiel auf und zeigt, wie Objekte sich gegenseitig mit Hilfe von Object Request Brokern Nachrichten schicken koennen.

Beim objektorientierten Design werden die Daten einer Objektklasse zu einem Datenbestand und die Methoden der Objektklasse werden zu Funktionen eines Klassenmoduls.

Abbildung 3 verdeutlicht, wie eine Software-Architektur aussehen kann, die die Objekte aus Abbildung 1 implementiert.

Auf der realen Maschine gibt es fuer jedes Objekt beziehungsweise genauer: jede Objektklasse aus der objektorientierten Analyse ein Programm und einen Datenbestand. Das Klassenprogramm enthaelt die Funktionen, die das Verhalten der Objekte der Klasse bestimmen. Der Datenbestand beinhaltet die Daten aller Objekte der Klasse.

Die Objekte kommunizieren ueber Nachrichten miteinander. Die Einfachheit der objektorientierten Analyse findet sich in der Struktur des fertigen Systems wieder (vgl. Abb. 4).

Abb. 1: Objektkommunikation ueber Nachrichten

Abb. 2: Ein ORB als Nachrichten-Zusteller erhaelt die Einfachheit der Objektorientierung in der fertigen Software.

Abb. 3: Umsetzen eines Objektes beziehungsweise einer Objektklasse im Design. Ergebnis: Ein Klassenmodul und ein Datenspeicher fuer die Objekte der Klasse.

Abb. 4: Ein Object Request Broker mit den Lademodulen und Datenspeichern seiner Objektklassen: Die Einfachheit der objektorientierten Analyse bleibt bestehen.

*Martin Roesch ist Gruender und Inhaber der Roesch Consulting GmbH,in Kaarst bei Duesseldorf. Das Unternehmen ist Partner von Peter Coad und Object International sowie Mitglied der OMG. Der Autor verbindet seinen Bericht mit einer Aufforderung an Anwenderunternehmen, ihre Interessen in der OMG gegenueber Herstellerunternehmen zu vertreten. Ein Fragebogen (RFI) der OMG zu den Anforderungen an Corba 2.0 kann kostenfrei ueber Roesch Consulting bezogen werden.

Corba: Common Object Request Broker Architecture. Der erste Standard der OMG. Corba beschreibt, wie ein ORB aussehen sollte. Die OMG wird ab Corba 2.0 Compliance Tests durchfuehren.

Corba 1.1: Dieser Standard wurde im Januar 1992 vorgestellt. Er beschreibt, wie ein ORB arbeitet und wie er sich nach aussen - fuer Client-Objekte und Server-Objekte - darstellen sollte. Der Anschluss von C-Programmen an einen ORB ist ebenfalls dokumentiert.

Corba 2.0: Ergaenzt Corba 1.1 um die naechstwichtigsten Themen. Termin: Ende 1994. Was dabei beruecksichtigt wird , entscheiden Anwender und Hersteller mit ihren Antworten auf den RFI der OMG. Bisher sind unter anderem folgende Themen vorgesehen: Multimedia- Anwendungen, Zusammenarbeit fremder ORBs, Zugang zum ORB von anderen Programmiersprachen als C und Transaktionssicherung.

Compliance Test: Ab Corba 2.0 wird die OMG Tests durchfuehren, die die Einhaltung des Corba-Standards in Softwareprodukten ueberpruefen.

Abkuerzungen

OMG: Object Management Group, gegruendet 1989, heute zirka 300 Mitgliedsfirmen (Anwender und Hersteller), Sitz in Framingham, Massachusetts.

AORB: Object Request Broker. Ein ORB transportiert Nachrichten zwischen Objekten. Im Gegensatz zu Programmiersprachen und Datenbanken wie zum Beispiel C++, Smalltalk und Objectstore, die Objektorientierung im kleinen bieten, ermoeglichen Object Request Broker eine unternehmensweite Objektorientierung - ueber Rechner- und Betriebssystemgrenzen hinweg.

RFI: Request for Information. Erste Vorstufe jedes OMG-Standards. Mit dem RFI werden Anwender und Hersteller um Mithilfe gebeten.

Der Nutzen von ORBs

Der Einsatz von Object Request Brokern bringt folgende Vorteile:

- ORB-basierte Informationssysteme sind leichter wartbar, da die fertige Software noch die gleichen, einfachen Strukturen aufweist, die in der objektorientierten Analyse entstanden sind.

- Der Aufwand fuer die Programmierung von Netzwerkprotokollen entfaellt. Entwickler von Anwendungsobjekten koennen sich auf betriebswirtschaftliche Aufgaben konzentrieren.

- ORB-basierte Informationssysteme koennen leichter von einer Hardware-Betriebssystem-Kombination auf eine andere umgesetzt werden. Dies gilt jedoch nicht uneingeschraenkt .