Objekttechnik von Microsoft im Vergleich mit dem offenen Standard der OMG OLE versus Opendoc: Streit auf dem Ruecken der Anwender

10.03.1995

CW-Bericht, Ulrike Litzba

Pure Polemik bestimmt zunehmend die Diskussion um die Objekttechniken OLE von Microsoft und das konkurrierende Opendoc von IBM, Apple und Novell. Die Opendoc-Fraktion bezeichnet OLE abschaetzig als Neandertaler aus einem Nebenzweig der Software- Evolution. Die OLE-Anhaenger halten die MS-Technik dagegen fuer eine technische Schoenheit und einen geschaeftlichen Geniestreich. Die Folge des Gerangels: Der Anwender muss sich nicht nur mit dem Zweck der Component-Technologien, mit Preisen und Verfuegbarkeit, sondern auch mit Produktphilosophien und -architekturen auseinandersetzen.

OLE steht zwar fuer Object Linking and Embedding, dient jedoch nur zu 25 Prozent der Erstellung von zusammengesetzten Dokumenten, den Compound Documents.* Damit beinhaltet ein Vergleich der rivalisierenden Techniken eine programmiertechnische Komponente - die Architekturen OLE/COM und der Standard Corba (Common Object Request Broker Architecture) - und eine anwendungsbezogene: OLE contra Opendoc.

Das Fundament der Microsoft-Architektur OLE 2.0 bildet das "Component Object Model" (COM). In der OLE-Terminologie wird unter einer Komponente ein Softwarebaustein verstanden, dessen Funktionalitaet in standardisierter Form abrufbar ist. Die Bezeichnung Objekt wird hier meistens als Synonym fuer Komponente verwendet. In diesem Sinne definiert das Modell einen Mechanismus fuer die Koppelung von Objekten und ein Protokoll fuer die Kommunikation zwischen ihnen.

Binaere Schnittstellen ermoeglichen Interoperabilitaet der Windows- Objekte. Interfaces stellen Methoden dar, die semantisch zusammengehoeren. OLE-Objekte unterscheiden sich somit nach aussen nur in der Art und Zahl der unterstuetzten Interfaces. Der Zugriff auf die Objekte erfolgt einzig ueber diese Schnittstellen.

Durch den binaeren Standard der Interfaces wird zwar Sprachneutralitaet erreicht, gleichzeitig verhindert er jedoch Moeglichkeiten der Vererbung. Da diese Eigenschaft zum Kern der objektorientierten Technik gehoert, ist OLE damit allenfalls objektbasiert, nicht objektorientiert. Statt Vererbung stellt die MS-Technik Container-Objekte, Objekt-Pointer und einige polymorphe Schnittstellen zur Verfuegung.

Auf diese Weise kann ein Objekt andere Objekte enthalten. Zum Beispiel lassen sich spezialisierte Dokumententeile komplett in ein aufnehmendes Dokument (Container) kopieren beziehungsweise einbetten - wie etwa eine Excel-Tabelle in einen Winword-Text (Object Embedding), oder via Objekt-Linking mit dem aufnehmenden Dokument verbinden. Im zweiten Fall wird lediglich der Verweis auf das Original im Container registriert.

Nimmt ein komplexes Objekt ein einfaches ueber Containment auf, koennen die Methodenaufrufe vom umfassenden Objekt beantwortet werden. Deswegen bietet ein OLE-Container mindestens zwei Interfaces an. Dagegen bedarf das aggregierte Objekt, auf das verwiesen wird, eines eigenen Containment-faehigen Interface, damit es selbst in Kontakt mit anderen Objekten treten kann. Dazu muss es wissen, dass es in einem anderen Objekt implementiert ist. Die Aufgabe, auch nur einen einfachen Container zu implementieren, ist mit erheblichem Programmieraufwand verbunden. Greift der Entwickler bei der Programmierung von OLE-Applikationen nicht auf das von Microsoft vermarktete Framework MFC (Microsoft Foundation Classes) zurueck, muessen etwa alle Schritte zur Bildung von Container- und Server-Objekten per Hand ausgefuehrt werden.

Das soll sich mit der Version 4.0 von Visual Basic sowie mit Visual C++ 2.0 aendern. OLE Custom Controls werden die bisherigen Basic Extensions ersetzen. OLE-Objekte sollen dann mittels grafischer Elemente in die Entwicklungsumgebung und Standardanwendungen eingebunden werden koennen.

Um Objekte aktivieren oder manipulieren zu koennen, um etwa ein Dokumententeil aus oder von einer anderen Anwendung zu starten, stellt OLE den Mechanismus "Automation" bereit. Ein OLE- Automation-Objekt ist eine Komponente, mit der von aussen Einfluss auf die Applikation genommen werden kann, Eigenschaften (Properties) und Methoden koennen exportiert werden. Sie lassen sich ueber sogenannte Automation-Controller wie Visual Basic oder direkt ansprechen. In diesem Fall muss der Entwickler ein bestimmtes Application Programming Interface aufrufen, um die gewuenschte Automation-Klasse zu erzeugen, und die vorgesehenen Interfaces benutzen.

Bisher ist OLE lediglich ein Windows-Zusatz sowohl fuer die 16-Bit- als auch fuer die 32-Bit-Version. Anwender, die OLE nutzen wollen, muessen daher entsprechende Bibliotheken, die Dynamic Link Libraries (DLLs) selbst installieren. Mit Windows 95 und Cairo soll sich das aendern.

Der groesste Nachteil von OLE/COM: Die MS-Technik ist nicht netzwerkfaehig; alle Objekte muessen auf einem System registriert und ablaufbereit sein. Auch das soll sich mit Cairo aendern. Eine gravierende Einschraenkung bedeutet ausserdem die Tatsache, dass OLE einzig in der Microsoft-Welt einsetzbar ist.

Opendoc leidet nicht unter derartigen Schwaechen, versprechen die Hersteller. Doch waehrend sich OLE de facto als Desktop-Standard etabliert hat, sind erste Opendoc-Auslieferungen erst Mitte des Jahres zu erwarten. Opendoc von IBM, Apple und Wordperfect basiert auf der Object Management Architecture (OMA) und ist Corba-kompatibel.

OMA entspricht einem Referenzmodell fuer verteilte heterogene objektorientierte Systeme und wurde von dem ueber 400 Mitglieder zaehlenden Herstellergremium Object Management Group (OMG) erstellt. Der gewaehlte Loesungsansatz ist maechtiger und allgemeiner als OLE, was jedoch einen laengeren Standardisierungsprozess zur Folge hat. Die OMG-Dokumente sind frei verfuegbar (Internet- Adresse: OMGunderscoreserver OMG.org).

In der Objekttechnik funktioniert ein Programm im wesentlichen durch die Kommunikation zwischen den Objekten als Sequenz aus Nachrichten beziehungsweise Methodenaufrufen. Jeder Object Request Broker (ORB) soll remote und transparent Methodenaufrufe ermoeglichen. Ohne zu wissen, wo sich die anderen Objekte befinden oder wie der Transportweg verlaeuft, koennen Objekte die Methoden anderer nutzen. Corba 2.0 definiert einen Standard fuer die objektorientierte Interaktion auf vernetzten Systemen.

Ein Corba-Objekt entspricht einem Interface-Typ, der festlegt, welche Methoden jeweils aufrufbar sind. Ein Interface enthaelt keine Daten. Ein Aufruf oder Request spezifiziert einen Methodennamen, das Zielobjekt, Parameter und einen optionalen Kontext. Der Common ORB sendet einen Aufruf an das Zielobjekt und meldet Ergebnisse oder Fehlerbedingungen an den Anrufer zurueck.

Mit Hilfe einer Interface Definition Language (IDL) werden Schnittstellen definiert, wobei man sich ein Interface in etwa wie eine Klassendefinition in C++ vorstellen kann. IDL soll die Sprachenunabhaengigkeit der OMG-Architektur garantieren. Zur Zeit werden allerdings lediglich C, C++ und Smalltalk unterstuetzt. Ein IDL-Compiler erzeugt aus der IDL-Definition sogenannte Stubs, kleine Subroutinen, die in das aufrufende Programm eingebunden werden koennen. Um Objekte zu implementieren, muss das Aufruf- Interface, das IDL-Skeleton, mit Code gefuellt werden.

Ausserdem ist die Objektimplementierung beim Objektadapter anzumelden. Die Aufgaben dieses Corba-Bausteins sind beispielsweise die Generierung und Interpretation von Objektreferenzen, die Aktivierung und Deaktivierung von Objekten, der Methodenaufruf sowie die Registrierung von Implementierungen. Ein "Implementation Repository" enthaelt die persistenten Objekte, die IDL-Informationen und zusaetzliche Informationen repraesentieren.

Das sogenannte "Dynamic Invocation Interface" erlaubt die Abfrage von Typinformationen aus diesem Repository und ermoeglicht den dynamischen Zusammenbau und das Versenden von Objektaufrufen.

Zu den weiteren Bausteinen der OMG-Architektur gehoeren neben dem ORB die "Object Services", "Common Facilities" und "Applikation Objects". Zu den Object Services zaehlen alle grundlegenden Operationen fuer die logische Modellierung und physikalische Speicherung von Objekten. Im Augenblick sind Events, Naming, Persistence, Lifecycle sowie Transactions, Relationships, Externalization und Concurrency Control standardisiert.

Die Common Facilities bilden eine Sammlung von Klassen und Objekten, die fuer mehrere Anwendungsdomaenen nuetzlich sind wie Funktionen der Graphical User Interfaces (GUIs), Druckerdienste, Electronic Mail sowie vor allem Opendoc. Im Gegensatz zu den Object Services sind diese Funktionen nicht auf allen Plattformen verfuegbar.

Die Anwendungsobjekte, die die Funktionalitaet fuer ein bestimmtes Anwendungsgebiet repraesentieren, sind zwar auf demselben Level wie die Common Facilities definiert, aber nicht Gegenstand der Standardisierung.

Beide Plattformen bieten Objektmodelle, bei denen die Objekte nach aussen nur ueber Methoden-Schnittstellen sichtbar sind. Dabei bekommen die Client- und Server-Objekte keine Implementierungsdetails des jeweiligen Kommunikationspartners zu sehen. Das OMG-Modell unterstuetzt, weil objektorientiert, die mehrfache Vererbung ist dagegen in OLE nur bis zu einem gewissen Grad simulierbar, allerdings ohne Unterstuetzung von Polymorphie. OLE laesst allerings mehrere Schnittstellen pro Objekt zu.

Sowohl OLE 2.0 als auch Corba unterstuetzen das "Remoting" von Schnittstellen, der Zugriff auf eine Objektmethode erfordert bei beiden Techniken keine Kenntnis ueber den aktuellen Aufenthalt des Zielobjekts. Beide erlauben die dynamische Abfrage von Informationen ueber momentan sichtbare Objekte und das dynamische Absetzen von Methodenaufrufen an diese Objekte.

Beide Plattformen unterstuetzen Stubs. Waehrend die Corba- Schnittstellen Objekte ueber IDL exportieren, bietet OLE Automation hierfuer eine eigene, proprietaere Sprache an, die Object Definition Language.

Die Interoperabilitaet zwischen OLE und Corba beschraenkt sich auf den Austausch von Nachrichten auf der COM-Ebene. Die Moeglichkeit, Messages hin- und herzuschicken, schliesst jedoch Funktionen aus, wie OLE-Objekte auf ein Unix-System zu kopieren; auch die umgekehrte Moeglichkeit ist nicht gegeben. Opendoc bietet jedoch eine OLE-Schnittstelle, so dass Objekte zwischen beiden Welten ausgetauscht werden koennen, sofern sich die Komponenten auf einem Rechner befinden.