6. Resumé

Die Sprache Emerald stammt ursprünglich aus dem Jahre 1986. Verschiedene Dissertationen haben sich mit verteilter Programmierung auf Basis von Emerald beschäftigt, doch neuere Dokumente als aus dem Jahre 1989 waren nicht aufzufinden. Obwohl Beschreibung und Implementation der Sprache frei verfügbar sind, sind keine Applikationen bekannt, die größere Aufgaben als Tests vollbringen. Es muß also die Frage gestellt werden, was bei dem Design der Sprache falsch gemacht wurde, warum sich Emerald nicht besser verbreitet hat.

Von der Konzeption hat Emerald durchaus viele Vorteile. Bis heute ist Programmierung auf einem transparenten Netzwerk noch nirgendwo so elegant und effizient gelöst wie in dieser Sprache. Auch kann es kaum an der Objektorientierung liegen, schließlich feiert die ebenfalls objektorientierte Sprache C++ gerade ihren Siegeszug.

Die ablehnende Haltung der Sprache gegenüber dürfte vielmehr von der Syntax stammen. Die Syntax entspricht keiner verbreiteten Sprache, und die Umstellung ist vergleichsweise umständlich. Das verbreitete Klassenkonzept wurde nicht implementiert, was mit nicht nachvollziehbaren Erklärungen begründet wird. Die Tatsache, daß Deklaration des Interfaces und Implementation der Prozeduren fest verkoppelt sind, fördert nicht gerade die Übersichtlichkeit. Für jeden Typ von Objekt ein Objekt- Erzeuger-Objekt definieren zu müssen, erschwert den Überblick weiter. Das in Programm 1 gezeigte Beispiel zeigt auch eindrucksvoll, wieviel Typdeklarationen und Namen benötigt werden, einfach nur um mehrere Objekte gleichen Typs zu erzeugen.

Auch schmerzt die fehlende Unterstützung von Vererbung. Der Programmierer wird dadurch in vielen Fällen zur Wiederholung von Programmtext gezwungen, da gleich zu implementierende Prozeduren in allen Objekten neu programmiert werden müssen, anstatt daß die Prozeduren vom Vorgänger ererbt werden.

Ein Nachteil ist weiterhin, daß alle Aktionen von einer zentralen Stelle ausgelöst werden müssen. Eine Applikation, die auf einem Rechner gestartet wird, kann sich selber zwar auf beliebig viele Rechner ausbreiten; trotzdem ist es nicht möglich, Services anderer Applikationen in Anspruch zu nehmen oder selber Services anzubieten. Hierzu müßten zur Laufzeit externe Objekte angebunden werden, was von der Sprache nicht unterstützt wird.

Und gerade dies ist ein Jammer, denn die Möglichkeiten einer ORB-Architektur auf Basis einer verteilten Sprache sind überzeugend. Beim Zugriff auf einen Service würde sich der Serviceanbieter, üblicherweise ein unveränderliches Objekt, auf den Rechner des Klienten, oder zumindest einen Rechner im lokalen Netz, kopieren, dort seine Aufgaben lokal mit besserer Performance verrichten, und würde nach Abschluß der Dienstleistung automatisch wieder gelöscht werden.

Ein letzter Nachteil von Emerald ist unvermeidlich; alle angeschlossenen Rechner im Netzwerk müssen die gleiche Hardware, insbesondere den gleichen Prozessor, verwenden. Da Emerald-Prozeduren Assemblerbefehle sind, und der Code der Prozeduren zwischen Rechnern ausgetauscht werden muß, dürfen keine fremden Plattformen stören. Wiederum kann dieser Nachteil als Vorteil verstanden werden, da aufwendige Konvertierungen wie bei RPC und XDR hier nicht nötig sind.

Ein Wort noch zur Sicherheit. Zwar garantiert der Emerald-Compiler die Generierung von betriebssystemsicheren Code, doch ist dies ein Schutzmechanismus, der schnell umgangen werden kann. Unix- Systemadministratoren würden die Hände über dem Kopf zusammenschlagen, wenn es einem Anwender möglich ist, mit ein paar Maschinenbefehlen das gesamte Betriebssystem auszulesen und zu verändern. Die strenge Abkapselung des Betriebssystemes gegen mutwilliges Einbrechen, wie sie in Unix vorhanden ist [12], existiert in Emerald überhaupt nicht. Weiterhin verfügt Emerald bislang noch nicht über Rechnerschutzmechanismen. Jede Applikation kann sich auf alle Rechner verteilen, auf denen ein Emerald-Betriebssystem läuft. Ein "Virus", der sich selber auf alle Rechner kopiert, ist nur wenige Zeilen lang. Zwar sind diese beiden Punkte innerhalb eines verläßlichen, beschränkten Netzwerkes nicht von Belang; in großen Datennetzen mit unkontrollierbaren Benutzerzugriffen aber ist die Anwendung nicht mehr vertretbar.

Trotz alledem hat Emerald gezeigt, daß ein generelles Objektmodell, Netzwerktransparenz und Performance keine Widersprüche sind, sondern gemeinsam existieren können. Bei dem Vergleich der Syntax wurden oft Vergleiche zur bequemeren Handhabung von Objekten in C++ hergestellt, wobei berücksichtigt werden muß, daß Emerald zeitlich vor C++ entstanden ist. Es wäre sicherlich interessant, zu versuchen, die Vorteile beider Sprachen zu verbinden; die Intelligenz und Flexibilität des Emerald-Compilers und die gewohnten Syntaxregeln von C++.

[Inhaltsverzeichnis] [Voriges Kapitel] [Nächstes Kapitel]