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.

01.10.1993

Im objektorientierten Lager bilden sich Fraktionen Hinter den Kulissen tobt der Kampf um Standards von morgen Von Hanns-Martin Meyer*

Auch die objektorientierte Programmierung (OOP) wird sich wohl erst dann zu einem ernstzunehmenden Softwarekonzept wandeln, wenn die Gretchenfrage beantwortet ist: Wie steht es mit den Standards? Die Software-Unternehmen sind also gefordert, solche Standards zu definieren. Allerdings existieren bereits zwei Lager.

Objektorientierte Programmierung bringt bereits leichte Vorteile fuer den Entwicklungs- und Wartungsprozess und produziert kompakteren (bis zum Faktor fuenf), uebersichtlicheren und leichter wartbaren Code. Die entscheidenden Vorteile der Objekt- orientierung wie Encapsulation, Re-Usability von Softwaremodulen, Durchgaengigkeit von der Analyse ueber das Design bis zur Implementierung und Interoperabilitaet sowie Konfigurierbarkeit von Anwendungskomponenten unterschiedlichster Herkunft ermoeglichen jedoch erst eine objektorientierte Software-Architektur.

Objekte rufen Methoden anderer Objekte auf

In einer solchen Architektur bilden interoperable, wiederverwendbare, portable Softwarekomponenten die Objekte der realen Welt nach. Sie modellieren nicht nur die Daten, sondern umfassen die Daten des Objektes und bieten anderen Objekten Methoden an. Sie bilden voneinander unabhaengige Einheiten. Die Funktionalitaet einer Anwen- dungssoftware mit einer objekt- orientierten Architektur wird allein dadurch erzeugt, dass Objekte die Methoden anderer Objekte aufrufen.

Nun soll sich aber ein solcher Methodenaufruf, also die Herstellung der Anwendungsfunk- tionalitaet, nicht nur auf den lokalen Aufruf innerhalb der Software eines Herstellers oder Entwicklers beschraenken. Er darf auch nicht auf einen Prozess oder - noch weiter gefasst - einen Rechner begrenzt sein. Das Ziel ist, objektorientierte Software-Architektur in einer Client-Server- Umgebung verteilt in einem Netz zu nutzen und damit Methodenaufrufe ueber Rechnergrenzen hinweg zu ermoeglichen.

Die Architektur muss sprachneutral sein

Eine objektorientierte Software-Architektur muss aber auch unabhaengig von der Implementierungssprache der jeweiligen Objekte sein. Der Anwender und der Entwickler duerfen nicht gezwungen werden, eine bestimmte Programmiersprache fuer die Entwicklung von objektorientier- ten Architekturen zu verwenden.

Die interagierenden Objekte muessen sowohl in klassischen Programmiersprachen, im Extremfall bis zu Assembler, als auch in den verschiedenen hochentwickelten, objektorientierten Sprachen wie C++, Smalltalk oder anderen implementierbar und trotzdem in einer Software-Architektur untereinander operabel sein.

Das Hauptproblem ist der standardisierte Methodenaufruf. Zu diesem gehoeren der Name des aufgerufenen Objektes und der Methode, sowie eine Menge von Parametern und von Resultaten. Ueber diese Angaben hinaus sollte ein Objekt A, das eine Methode eines Objektes B aufruft, keine Angaben machen muessen. Das heisst: Es muessen Services existieren, die diesen Aufruf zum aufgerufenen Objekt bringen, egal wo und auf welchem Rechner im Netz es residiert. Diese Services sollten das Resultat der Methode ebenso zurueckbringen, den gesamten Vorgang synchronisieren und eventuell notwendige Konvertierungen sowie Sicherheitsmassnahmen durchfuehren.

Innerhalb eines Entwicklungsprojektes kann man nun dazu eigene Verfahren entwickeln und vorschreiben, Services implemen- tieren und deren Verwendung zur Pflicht machen.

Dieses Vorgehen bringt wesentliche Schritte auf dem Weg zu den Vorteilen der Objekt- orientierung. Es laesst sich auf andere Projekte uebertragen bis hin zur Schaffung eines Unternehmensstandards. Auf diese Weise lassen sich sowohl Objekte (Klassen) aus schon durchgefuehrten Projekten wieder einsetzen, als auch Services erneut verwenden, die fuer den transparenten Methodenaufruf implementiert wurden. Ein Problem tritt dann auf, wenn man Klassen aus fremden Quellen verwenden will, die dann wahrscheinlich andere Standards des Methodenaufrufs definiert und verwendet haben.

Die Schwierigkeit verschaerft sich, wenn diese Klassen in einer anderen Programmiersprache implementiert sind, und es eskaliert, wenn die Objekte in einer klassischen Programmiersprache implementiert sind, jedoch ein Interface besitzen.

Um die Vision zu verwirklichen, Objekte aus beliebigen Quellen verteilt im Netz zu einer objektorientierten Architektur zu konfigurieren, bedarf es also eines standardisierten Object Request Brokers (ORB). Die ueber 300 Mitglieder starke Object Management Group (OMG) hat - inzwischen unterstuetzt durch die X/Open - eine Spezifikation einer Common Object Request Broker Architecture (Corba) erarbeitet und veroeffentlicht. Wesentlicher Bestandteil und Hauptverdienst von Corba ist die Definition einer Interface Definition Language (IDL), in der nach Corba die Interfaces fuer die Methoden spezifiziert werden. Im statischen Verfahren koennen dann Stubs fuer die eigentlichen Methodenaufrufe aus der IDL-Spezifikation generiert oder die Methoden dynamisch am ORB aufgerufen werden.

ORB-Implementierungen sind nicht interoperabel

Damit werden die Schnittstellen zwischen dem ORB nach Corba und dem Client-Objekt beziehungsweise dem Service-Objekt festgelegt und mit der IDL auch nach einheitlichem Verfahren spezifiziert.

Mit diesen Aktivitaeten der OMG ist man geneigt zu sagen: Die Loesung liegt in der Forderung, dass ORB-Produkte Corba-compliant sein muessen. Leider reicht das nicht aus. Setze ich als Anwender auf meinem Rechner eins einen ORB ein, auf Rechner zwei aber einen anderen, so koennen sich diese beiden ORB nicht "unterhalten", auch wenn sie beide Corba-compliant sind.

Fuer alle bekannten ORB-Implementierungen - System Object Modell (SOM) von IBM, Distributed Object Management Facility (Domf) von HP, Distributed Objects Everywhere (DOE) von Sunsoft und Distributed Object Management System (Doms) von Hyperdesk - ist die Corba-Compliance angekuendigt, aber diese Produkte sind deshalb untereinander noch nicht interoperabel. Corba ermoeglicht lediglich, dass Objekte, die gegen die IDL implementiert sind, fuer Corba genuegende ORBs rekompilierbar sind.

Microsoft geht einen eigenen Weg

Die OMG hat jetzt dazu aufgerufen, Beitraege fuer Corba 2 zu liefern. Corba 2 hat genau die Interoperabilitat der ORB zum Ziel. Inzwischen aber hat sich ein anderer auf einen alternativen Weg gemacht: Microsoft kommt zunaechst von einem scheinbar ganz anderen Ansatz her.

Objekt Linking und Embedding (OLE) ist ein dokumentenorientierter Ansatz und hat zum Ziel, Dokumente unterschiedlicher Herkunft und mit verschiedener Funktionalitaet (Text, Spreadsheet, Image etc.) in einem Dokument einschliesslich der spezifischen Verarbeitungsfunktionalitaet zu vereinen. Diese "Inplace- Activation" ist dabei nichts anderes, als die Funktionalitaet (die Methoden) des eingebetteten Dokumentes (Objektes) vom einbettenden Dokument (Objekt) aus aufzurufen.

Studiert man die Interfaces von OLE 2.0 genauer, so wird klar, dass OLE nicht nur Dokumente behandeln kann. OLE ist der Object Request Broker unter Windows und Windows NT, aber er ist nicht Corba- compliant.

OLE duerfte zum Client-Standard werden

Allerdings ist die Implementierung der schon in Richtung ORB ausgelegten Interfaces in OLE noch sehr einfach. OLE ist auch noch nicht rechneruebergreifend (nur im Fall "embedded", und dann wird die gesamte Information kopiert), es besitzt keinen Name-Service, wie man ihn bei einem ausgewachsenen Object Request Broker verlangt. Dennoch: Die Verbreitung von Windows duerfte OLE zum Industriestandard unter den Object Request Brokern machen. OLE wird damit zum Integrationsmittel der Wahl auf der Client-Seite.

Vermutlich muessen Produkte, die auch 1994/95 erfolgreich sein wollen, OLE-faehig sein. Damit koennte OLE durchaus die Moeglichkeiten fuer einen Markt der individuell konfigurierbaren und integrierbaren Anwendungskomponenten (und -klassen) oeffnen.

OLE 2.0 ist darueber hinaus von seinen Schnittstellen her sicher die Grundlage fuer das bei Microsoft als Nachfolger von Windows NT geplante objektorientierte Betriebssystem Cairo.

Ein anderer Ansatz - wohl als Gegenbestrebung zum aufkommenden Industriestandard OLE 2.0 zu verstehen - ist in seiner obersten Schicht noch staerker dokumentenorientiert; an der Basis setzt er jedoch auf SOM von IBM auf, und damit auf einen Object Request Broker, der Corba-compliant werden soll: Apple, Borland, IBM, Novell und Wordperfect haben sich zusammengeschlossen, um dieser Variante unter dem Namen "Open Doc" den noetigen Ruecken- wind zu verleihen. IBM sieht darin auch den Migrationspfad zum Gemeinschaftsprodukt mit Apple, naemlich zu Taligent, dem objektorientierten Betriebssystem, das aus dieser Allianz entstehen soll.

Vom technischen Konzept her scheint Open Doc verlockend. Die Verwendung von Corba stimmt den Verfechter offener Welten freundlich. Die heterogenen Plattformen sind eingeplant. Die Unabhaengigkeit von der Implementierungssprache ist durch den Einsatz von SOM vorgesehen. Wenn jedoch erst Anfang 1994 erste Spezifikationen fuer Open Doc zur Verfuegung stehen, so haben die fuenf Unternehmen gegenueber OLE noch viel Zeit aufzuholen.

Die Interaktion zwischen Objekten einer objektorientierten Architektur duerfte also der Schauplatz der naechsten Runde im Kampf der Betriebssysteme sein. OLE wird fuer Windows und Windows NT in die Arena geschickt, Open Doc fuer Taligent. Diese Art der Interaktion zwischen Objekten muss die naechste Generation von Betriebssystemen beherrschen. Die Runde wird offenbar in der richtigen Disziplin ausgefochten. Interprozesskommunikation ist doch auch ein Betriebssystem-Thema.

Fragen nach Persistenz und Objektverteilung

Zwei Fragen bleiben also noch offen zum Thema Standards fuer Objektorientierung, bevor wir ruhigen Gewissens in den diversen Objekt- und Klassenbibliotheken einkaufen gehen koennen. Zum einen: Auf welche Weise wird die Persistenz, also die permanente Speicherung von Objekten, geregelt? Zum anderen: Wie wird der Standard fuer die Verteilung von Objekten (einschliesslich der Implementierung ihrer Methoden) in heterogenen Netzen aussehen? Solange diese Fragen nicht beantwortet sind, bleibt die Objektorientierung doch die Privatsache der einzelnen Projektteams und des Entwicklungsstan- dards, die sie definieren. Und aus demWunschtraum des Einkaufens im Supermarkt fuer Klassenbibliotheken wird bestenfalls die Realitaet einiger geschlossener Gesellschaften.

*Dr. Hanns-Martin Meyer ist Geschaeftsfuehrer der Ixos Software GmbH, Grasbrunn bei Muenchen.