In diesem Abschnitt sollen kurz Ansätze besprochen werden, aus denen bei der Implementation von Emerald "gelernt" wurde. Die Vorteile und Nachteile jedes Systems werden genannt.
RPC ist die Abkürzung von Remote Procedure Call, also entfernter Prozeduraufruf. Dieser zuerst von Xerox beschriebene Ansatz [7] ist heute in der Unix-Welt etabliert und wird häufig angewandt. RPC erlaubt dem Programmierer, auf Services zuzugreifen, die ihm auf einem anderen (oder auch lokalen) Rechner angeboten werden. Er verbindet sich explizit mit diesem Service, wobei auf seiner Seite automatisch Funktionen bereitgestellt werden, welche die Aufrufparameter einpacken, den entfernten Service aufrufen, die Rückgabe abwarten und den Rückgabewert zurückliefern. Diese Interfacefunktionen können im folgenden wie eine lokale Prozedur aufgerufen werden, so daß die Entferntheit des Aufrufes dem Programmierer verborgen bleibt.
Als Vorteil von RPC kann genannt werden, daß auch fremde Services, die nicht vom Programmierer selber ausgehen, angesprochen werden können. Durch ein fest definiertes Format für den Datenaustausch, XDR, kann der RPC auch zwischen hardwarefremden Systemen stattfinden [9]. Die freie Verfügbarkeit einer RPC-Implementation von Sun, die auf der Programmiersprache C aufbaut [8], hat stark zur Verbreitung beigetragen; Sun-RPC ist mittlerweile für alle Unix-Systeme erhältlich, mit entsprechenden Hilfsmitteln wird die Implementation auf Applikationsseite sehr vereinfacht.
Das System hat jedoch mehrere gravierende Nachteile. Der Programmierer muß die exakte Lokation des Service kennen, um sich mit ihm verbinden zu können. RPC ist ein immobiles System, es stellt keine Möglichkeiten zur Prozessmigration zur Verfügung, und auch dem Serviceanbieter ist es nicht erlaubt, sich zu bewegen. Der entfernte Service muß bereits beim Verbindungsaufbau existieren. Eine verteilt arbeitende Applikation muß beim Start jeweils feststellen, ob alle benötigten Services vorhanden sind, und falls dem nicht so ist, bleibt dem Programm keine andere Möglichkeit, als mit einem Fehler abzubrechen. Der schwarze Peter landet wieder beim Programmierer, der mittels umständlicher Betriebssystemaufrufe alle entfernten Services von Hand starten muß.
Die Eden Programming Language [4], die ebenfalls an der Universität Washington entwickelt wurde, war ein erster Versuch, die Netzwerktransparenz als festen Teil einer Programmiersprache zu etablieren. Eden bietet wie die Sprache C++ die Objektorientierung als Zugabe zu dem von Concurrent Euclid übernommenen prozeduralen Modell, wobei Objekte frei über Rechnergrenzen hinweg verschiebbar sind.
Dem Programmierer ist es freigestellt, ob Prozeduren als Objekte implementiert werden, und es ist theoretisch möglich, völlig auf Prozeduren zu verzichten. Dies hört sich positiv an, wird aber in der Praxis durch verschiedene Implementationsschwächen erschwert. Jedes Objekt ist in Eden ein eigenständiger Unix Prozeß. Auch kleine Objekte enthalten zusätzlich zu ihrer eigenen Implementation noch Teile des runtime systems zur Kommunikation, so daß die minimale Größe eines Objektes in der Größenordnung 100.000 bytes liegt. Ein zusätzliches Eden Objekt verschlingt daher einen überproportionalen Anteil an Ressourcen.
Zudem wird zum Zugriff auf ein Objekt stets ein allgemeines Modell verwendet. Auch innerhalb eines Rechners werden Daten über rechnerübergreifende Kommunikationskanäle ausgetauscht. Prozeduraufrufe eines Eden Objektes dauern auch innerhalb eines Rechners Millisekunden. Für ein extensiv objektorientiertes System ist diese Performance indiskutabel [2].
Auch die Mobilität von Objekten ist eingeschränkt, da Eden keine on-the-fly Bewegung unterstützt. In der Praxis wird ein Objekt, d.h. ein Unix Prozeß, auf einem Rechner zum Absturz gebracht und auf einem anderen Rechner neu gestartet. Falls Zugriffe auf das Objekt ausgeführt wurden, so gehen diese verloren.
Smalltalk [6] wird hier wegen seines objektorientierten Ansatzes erwähnt. Insbesondere die Implementation von Polymorphismus in Smalltalk ist interessant. Die Sprache verzichtet völlig auf Typisierung von Variablen, so daß zur Kompilierzeit keine Entscheidungen bezüglich der Konformität getroffen werden können; der Compiler muß jedem Aufruf einen Laufzeittest zur Typüberprüfung voranstellen. Erst bei der Ausführung des Programmes, wenn messages an ein Objekt verschickt werden wird festgestellt, ob dieses Objekt diese message versteht und im Fehlerfall das Programm abgebrochen.
Dieser Ansatz ist fehlerträchtig, und Programmierung ist aufwendig, da auch Tippfehler jedesmal bei der Ausführung einen Programmabbruch auslösen. Weiterhin muß auf Kosten der Effizienz ein allgemeiner Mechanismus zum Prozeduraufruf verwendet werden.
[Inhaltsverzeichnis] [Voriges Kapitel] [Nächstes Kapitel]
Frank Pilhofer <fp -AT- fpx.de> Back to the Homepage Last modified: Fri Mar 31 18:41:08 1995