oberon index <- ^ -> mail ?
Weiter: Manualseiten, davor: Verteilte Briefkasten-Objekte, darüber: Verteilte Anwendungen.

Resümee

Die Beispiele dieses Kapitels waren nicht dazu gedacht, zu beweisen, daß alles, was hier erarbeitet wurde, so und nicht anders sein mußte. Wer eine Softwarebibliothek entwickelt, sollte viel größeren Wert auf Einfachheit und Vielseitigkeit der zur Verfügung gestellten Hilfsmittel legen, als darauf, daß ihnen ihr Verwendungszweck eindeutig anzusehen ist. Erfahrungen mit diesen und anderen Komponenten haben ergeben, daß es sehr attraktiv sein kann, pro Abstraktion nur wenige Eigenschaften festzulegen, um umso mehr Gewinn aus den verschiedenen möglichen Kombinationen zu ziehen. So sind im Ulmer Oberon-System etwa Exportierbarkeit und Persistenz in gewisser Weise analoge und doch voneinander unabhängige Konzepte. Sie treten kombiniert auf bei den persistenten Sichten, die eine erstaunliche neue Funktionalität einführen, und sie haben eine gemeinsame Wurzel bei den Diensten, die zwar für diesen Kontext entwickelt wurden, aber plötzlich auch völlig anderen Anwendungen zugute kommen.

In diesem Licht scheint es gerechtfertigt, einen größeren Aufwand für die Beschäftigung mit Grundlagen zu treiben, als "praktische Erfordernisse" zuweilen sinnvoll erscheinen lassen wollen. Auch die vorliegende Arbeit tendiert weniger zu fertigen Lösungen als in die Richtung möglichst solider Ausgangspunkte -- bei allen Zugeständnissen, die einem ein zeitlich begrenzter Rahmen und die natürliche "Lernkurve" beim Umgang mit einem sich rasch weiterentwickelnden System abnötigen.

Das soll nicht heißen, daß die Praxis außer acht gelassen würde. Vielmehr liefern reale Gegebenheiten und Analogien immer wieder die Motivation zu neuen Begriffsbildungen und Mechanismen des Zusammenwirkens verschiedener Komponenten. Letztlich steht und fällt gute Software mit der Schärfe der Problemanalyse und Ausdruckskraft der Spezifikation.

Die nächsten Schritte bei der Entwicklung von Namensräumen und daran ansetzenden Protokollen werden jedoch eindeutig näher zum Konkreten führen. Einer ersten Generation experimenteller Namensserver werden leistungsfähige Dienstprogramme folgen, die Persistenz, Sicherheit und schnelle Algorithmen in den Dienst verteilter Oberon-Anwendungen stellen werden. Namensräume werden die Rolle von portablen Schnittstellen zu vielerlei verwandten mehr oder minder stark systemabhängigen Bereichen annehmen, unter anderem den immer wieder ärgerlich uneinheitlichen Dateisystemen. Schließlich weisen auch Beispiele wie das World Wide Web auf ein besonderes Potential, das Namensräumen zu eigen ist, hin: die Fähigkeit zur Integration heterogener Umgebungen.


oberon index <- ^ -> mail ?
Weiter: Manualseiten, davor: Verteilte Briefkasten-Objekte, darüber: Verteilte Anwendungen.
Martin Hasch, Oct 1996