oberon index <- ^ -> mail ?
Weiter: Realisierung, davor/darüber: Namensräume.

Konzeption

Assoziativität

Wann immer Informationen "allgemein", d.h. für Interessenten mit wenigen oder stark unterschiedlichen Vorkenntnissen, bereitgestellt werden sollen, kommt es besonders auf eine geeignete Strukturierung des Zugangs zu diesen Informationen an. Dabei bewährt sich das Prinzip der Assoziativität, daß also von einer Fundstelle Verweise zu thematisch zusammenhängenden anderen Stellen führen.

So kann etwa ein Benutzer einer öffentlichen Bibliothek vom Schlagwortkatalog zu einem Regalbrett mit spezieller Fachliteratur gelangen, dort ein Buch aufschlagen, über das Inhaltsverzeichnis ein bestimmtes Kapitel finden, im Text auf eine Fußnote stoßen, die wiederum einen Literaturhinweis enthält, der ihn zunächst wieder zum Katalog und schließlich genau zu einem benötigten Zeitschriftenartikel führt, von dessen Existenz er beim Betreten der Büchereiräume noch gar nichts wußte.

Abstrakt ausgedrückt handelt es sich bei assoziativ verknüpften Informationen um gerichtete Graphen. Ein sehr geläufiges Beispiel aus dem Bereich der Informatik für die Implementierung eines solchen Modells stellt das typische Dateisystem dar. Dateien (ordinary files) und Verzeichnisse (directories) entsprechen den Knoten, während die in einem Verzeichnis enthaltenen Namen die von dort wegführenden Kanten repräsentieren.

Reichweite

Das Dateisystem stellt einen Namensraum für die Daten, die ein Computer verwaltet, dar: Um eine bestimmte Datei anzusprechen, ist nur ein ihr zugeordneter Pfadname nötig und nicht etwa explizite Positionierungsbefehle für den Lesekopf des Plattenspeichers oder dergleichen. Entsprechend einfach sollen beliebige Objekte in Oberon durch Namensräume zugänglich gemacht werden.

Ähnlich, wie es durch geeignete Software ermöglicht wird, daß ein Dateisystem nicht nur lokale Dateien repräsentiert, sondern sich über ein ganzes Netzwerk erstreckt, ohne daß für entfernte und lokale Dateien etwa verschiedene Zugriffsoperationen benutzt werden müßten, sollen auch Objekt-Namensräume über mehrere Parteien verteilt sein können. Eine Partei ist hier ein beliebiger Prozeß mit Oberon-Objekten.

In einer konzeptionell so wenig begrenzten Welt ist Flexibilität ein Gesichtspunkt von zentraler Bedeutung. Ein Namensraum-Objekt muß dynamisch verändert werden können, wobei den beteiligten Parteien allerdings differenzierte Kontrollmöglichkeiten einzuräumen sind. Dazu gehören insbesondere Zugriffsbeschränkungen aller Art, aber auch rein passive Beobachtungsmechanismen. Nur so wird ein Objekt, das mit anderen zu kommunizieren bereit ist, nicht zwangsläufig beliebig manipulierbar.

Vielseitigkeit

Ein Namensraum soll Zugang zu vorher unbekannten Objekten vermitteln können. Bei konsequenter Auslegung muß sich diese Forderung nicht nur auf Instanzen, sondern auch auf Klassen erstrecken, d.h., bei den in die Graphenstruktur eingebetteten Objekten sollte kein bestimmter Datentyp vorausgesetzt werden. Neben Flexibilität innerhalb eines Namensraums verspricht dies auch Vorteile für die vielseitige Verwendbarkeit des Protokolls an sich. Gerade im Zusammenhang mit Namensräumen gibt es sehr gute Erfahrungen damit, ein und dieselbe Schnittstelle für Zugriffe auf die unterschiedlichsten Ressourcen zu verwenden, wie z.B. das 9P-Protokoll in Plan 9 [Pike93].

Eine weitere Konsequenz aus dem Bestreben, wenig Vorwissen zu verlangen, ist, daß auch die Namen selbst in Erfahrung zu bringen sein sollten. Das System soll also nicht nur bekannte Namen auf Objekte abbilden, sondern auch Auskunft darüber geben, welche Namen in einer gewissen lokalen Umgebung existieren. Eine globale Betrachtung verbietet sich selbstverständlich aus Gründen der Skalierbarkeit. Da das System dynamisch ist, kann eine einmalige Auskunft rasch veralten; wünschenswert erscheint deswegen auch ein Mechanismus, Veränderungen so zu propagieren, daß direkt darauf reagiert werden kann.

Versteht man Namen als Hinweise zur Bestimmung von Objekten, erkennt man leicht, daß es günstig sein kann, ein Objekt über mehrere verschiedene Namen anzusprechen, die dann verschiedene Kriterien wiedergeben, die es alternativ bezeichnen. Diese Abbildung mag dies illustrieren. Von Namensgraphen sollte also im allgemeinen keine Baumstruktur erwartet werden.

gif (Grafik, 4.4 KB)
Beispiel für einen Namensraum

Relativität

Namen werden unter anderem dazu verwendet, daß ein Objekt von verschiedenen Seiten referenziert werden kann. Als Minimalvoraussetzung dafür gilt, daß die Auflösung dieser Namen im jeweiligen Kontext zum gleichen Ergebnis führt [Needham93].

Viele Adressierungssysteme benutzen einen globalen Namensraum in der Weise, daß jedes Objekt einen überall gültigen Namen erhält. Zur eigentlichen Lokalisierung des Objekts und zur Umsetzung der absoluten Lokation in eine relative Verbindungsroute (routing) bedarf es dann einer geeigneten Suchstrategie, etwa in Gestalt einer Kaskade von Abfragen regionaler Agenten, die jeweils entweder die fragliche Adresse auflösen können oder den Auftrag an einen weiteren Agenten delegieren. Beispiele für diese Technik, die keineswegs zufällig der Zustellung von Briefpost ähnelt, finden sich unter anderem in Grapevine [Birrell82] und bei Host-Adressen im Internet [Clark82]. Ein anderer Zugriffsmechanismus, aber ebenfalls das Prinzip der Globalität wird in DHS, einem in Oberon geschriebenen verteilten Betriebssystem, verwendet [Traub94], [Lupper94].

Hingegen wird im Ulmer Oberon-System, wie im Abschnitt über RemoteObjects bereits angedeutet, der Aufbau von Verbindungen zu möglicherweise entfernten Objekten auf einer eigenen Abstraktionsebene gelöst, hängt also nicht von einer speziellen Eigenschaft der Abstraktion für Namensräume ab. Deswegen kann auf Globalität in dem Sinne, daß die Abbildung von Namen auf Objekte immer ortsunabhängig sein muß, verzichtet werden. Das ist ein Vorteil, denn so können innerhalb einer Laufzeitumgebung Teile desselben Namensraums für lokal gültige, andere für absolute Zuordnungen verwendet werden. Im Beispiel der vorherigen Abbildung könnte etwa der default-Zweig zur Laufzeit in Abhängigkeit von Umgebungsvariablen gebildet worden sein, während der Rest aus einer systemspezifischen Datenbank stammt und wieder ein anderer, nicht dargestellter Teil tatsächlich einen über externe Namensserver zugänglichen globalen Adreßraum realisiert.

Daß es nützlich sein kann, nur bestimmte Teile eines Namensraums für Objekte, die mehreren Parteien zugänglich sein sollen, zu verwenden, während der Rest proprietär ist, zeigt sich auch am Beispiel verteilter Dateisysteme wie z.B. Andrew [Satyanarayanan93].

Konkretisierung

Ausgehend von dem bisher Gesagten lassen sich nun einige wesentliche Eigenschaften einer Abstraktion von Namensräumen in Oberon festlegen:

In bezug auf diesen letzten Punkt könnte die Frage gestellt werden, warum die Knoten-Eigenschaften nicht einfach als spezielle Sicht auf ein ansonsten unspezifisches Objekt realisiert werden. Ein eigener Datentyp für Knoten spiegelt jedoch stärker die Tatsache wieder, daß diese Eigenschaften häufig nur für sich allein auftreten werden, besonders bei den Knoten, die Nachfolger haben, also höchstwahrscheinlich eher für eine Verallgemeinerung als etwas Konkretes stehen. Die Semantik ist in beiden Fällen dieselbe, d.h., zu einem Objekt gehört maximal ein Satz von Eigenschaften als Knoten im Sinne der Namensraum-Abstraktion. Sollte jedoch eines Tages der Wunsch nach konkurrierenden Namensräumen mit unterschiedlichen Eigenschaften für dieselben Objekte aufkommen, genügte es bei der gewählten Form, die Zuordnungsregel zu lockern, die, wie sich zeigen wird, ohnehin separat implementierbar ist. Bei der anderen Vorgehensweise bestünde diese Möglichkeit nicht.

Zusammenfassend kann festgestellt werden, daß mit der vorgestellten Art von Namensräumen die Voraussetzung für die Identifikation und Lokalisierung von Objekten auch über Prozeßgrenzen hinweg, aber dennoch mit der Möglichkeit zu beliebigen Abstufungen der Lokalität gegeben ist.


oberon index <- ^ -> mail ?
Weiter: Realisierung, davor/darüber: Namensräume.
Martin Hasch, Oct 1996