Alle drei hier beschriebenen Eigenschaften, Objektorientierung, Polymorphismus und Mobilität werden von Emerald implementiert. An dieser Stelle sollen diese Stichwörter kurz allgemein erläutert werden.
In einem objektorientierten System hat ein Objekt eine genau spezifizierte Schnittstelle zur Außenwelt. Andere Objekte können nur über Funktionen dieser Schnittstelle auf das Objekt zugreifen, so daß die interne Repräsentation nicht sichtbar ist. Diese Abkapselung der inneren von der äußeren Darstellung hat den gewichtigen Vorteil, daß sich die Implementation eines Objektes ändern kann, ohne daß sich das Objekt nach außen hin anders verhält. Dieses Verhalten ist zwar auch in prozeduralen Modellen möglich, doch lädt die externe Sichtbarkeit der Implementation zum Mißbrauch der inneren Strukturen ein.
Objektorientierte Systeme implementieren meist auch Polymorphismus [3,11]. Polymorphismus heißt "die Fähigkeit, verschiedene Formen anzunehmen" und bedeutet, daß Prozeduren eines Objektes aufgerufen werden können, ohne den genauen Typ des Objektes zu kennen. Eng verbunden mit diesem Konzept ist der Begriff der Konformität. Ein Objekt verhält sich konform zu einem anderen Objekt, wenn es mindestens dessen Funktionalität anbietet. Ein Objekt kann durch ein konformes Objekt ersetzt werden.
Das Standardbeispiel für Konformität und Polymorphismus ist eine Bibliothek mit Grafikfunktionen, in der ein Objekt Gebilde existiert, welches die Funktionen drehen und bewegen anbietet. Die Objekte Rechteck und Dreieck verhalten sich konform zum Gebilde, da auch sie diese beiden Funktionen anbieten können. Wir können daher an jeder Stelle, an der wir das Gebilde verwenden können, auch ein Rechteck oder ein Dreieck verwenden. Dabei stellt der Polymorphismus sicher, daß bei jedem Aufruf der Funktion drehen auf einem Gebilde die richtige Funktion aufgerufen wird, also Rechteck.Drehen, falls das Objekt ein Rechteck ist, und Dreieck.Drehen, falls es sich um ein Dreieck handelt. Konformität ist trivialerweise reflexiv und transitiv, aber nicht symmetrisch. Zu beachten ist, daß das Gebilde nicht als eigene Implementation vorhanden sein muß; das Gebilde ist ein abstrakter Typ [1], der nur existiert, um die Beschreibungen des Rechteckes und des Dreieckes zu vereinen.
Mobilität ist eine wichtige Eigenschaft in verteilten Systemen. Üblicherweise wird Mobilität verlangt, um bei Überlastung eines Rechners Aufgaben oder auch Teile davon auf andere Rechner auszulagern. Es gibt jedoch noch andere Gründe, die Mobilität rechtfertigen. Mobilität kann nötig werden, damit Anwendungen auf spezielle Gegebenheiten eines Rechners, wie z.B. Numbercruncher-Hardware oder Grafikprozessoren Rücksicht nehmen können. Bei völliger Transparenz eines Netzwerkes wird diese Eigenschaft unumgänglich. Von grobkörniger Mobilität spricht man, wenn nur ganze Prozesse auf einmal bewegt werden können; in einem feinkörnig mobilen System sind auch Teile von Prozessen beweglich.
Mobilität ist allerdings nicht einfach zu implementieren, da ein Prozeß selten völlig von dem Quellrechner losgelöst werden kann. Hardware wie eine Festplatte, auf der temporäre Dateien lagern oder Ein/Ausgabe-Terminals sind unbeweglich, worauf stets Rücksicht genommen werden muß. Diese Probleme potenzieren sich beim Übergang von grobkörniger auf feinkörnige Mobilität. Bei der Bewegung eines Objektes ändert sich die komplette Umgebung des Objektes. Prozeduren, die vormals lokal waren, sind nun entfernt, während eventuell andere, früher entfernte Prozeduren plötzlich lokal sind. Ebenfalls müssen sich Objekte des Quellrechners, die vormals lokal auf das sich bewegende Objekt zugegriffen haben, auf die neue Situation einstellen.
Bisherige Systeme, die Mobilität implementieren, lösen derartige Probleme, in dem auf alle Objekte mit allgemeinen Mechanismen zugegriffen wird, auch wenn sich das Zielobjekt auf dem gleichen Rechner wie das aufrufende Objekt befindet. Dies resultiert in einer schlechten Performance.
[Inhaltsverzeichnis] [Voriges Kapitel] [Nächstes Kapitel]
Frank Pilhofer <fp -AT- fpx.de> Back to the Homepage Last modified: Fri Mar 31 18:41:09 1995