oberon index <- ^ -> mail ?
Weiter: Erzeugung von Knoten in fremdem Auftrag, davor/darüber: Verteilte Anwendungen.

Namensräume als Informationsträger

Vorbemerkungen

Alle Beispiele dieses Kapitels ranken sich um ein kleines, auf einem verteilten Namensraum basierendes System für persönliche Mitteilungen, das eigens zu Demonstrationszwecken entwickelt wurde. Will man den Erfordernissen der Skalierbarkeit und der Wiederverwendbarkeit von Software Rechnung tragen, wird man sich naturgemäß nur solcher Techniken bedienen, die nicht auf einen bestimmten Systemumfang zugeschnitten sind. Im Kleinen zeigt sich, wenn schon nicht ihre wahre Leistungsfähigkeit, so doch wohl immerhin ihre Form und Art der Verwendung. Übertrieben realistische Komplexität wäre dem beabsichtigten instruktiven Charakter ja auch nicht förderlich, und schließlich wird immer erst etwas Zeit vergehen müssen, bis für eine neu entwickelte Bibliothek umfangreichere Anwendungen vorliegen.

Das ausgewählte Problem animiert, wie es sich erweisen wird, dazu, manche Eigenschaften der im vorherigen Kapitel eingeführten Namensräume auf eine vielleicht etwas ungewöhnliche Weise zu nutzen. Allerdings ist in jeder aus erweiterbaren Abstraktionen aufgebauten Bibliothek ein Potential für Nutzungsmöglichkeiten zu erwarten, an die ursprünglich keineswegs gedacht wurde.

Aufgabenstellung

Die konkrete Aufgabenstellung soll zunächst durch einige funktionelle Anforderungen umrissen werden:

Lösungsansatz

Mit einer grundsätzlichen Entscheidung sei festgelegt, daß das logische Medium für Mitteilungen und Briefkästen ein Namensraum sein soll. Einige Charakteristiken der Lösung ergeben sich daraus fast von selbst. Ein Knoten in einem Namensraum kann von sich aus Daten aufnehmen, und zwar in Form der von ihm wegführenden Kanten. Ein Name für eine Kante ist bekanntlich eine beliebige Anzahl beliebiger Zeichen, kann also ohne weiteres aus dem Inhalt einer eingegebenen Mitteilung und einigen Zusatzinformationen bestehen. Also sollten Knoten als Briefkästen dienen können. Da jede Kante zu einem Knoten führt, bietet es sich sich an, hier genau den Absenderbriefkasten zu referenzieren. Mit geeignet zu vergebenden Berechtigungen kann sichergestellt werden, daß das Einfügen neuer Kanten (Mitteilungen) allgemein zugelassen, das Lesen und Löschen hingegen auf einen autorisierten Besitzer beschränkt wird.

gif (Grafik, 2.8 KB)
Beispiel für einen Graphen des Mitteilungs-Systems

Diese Abbildung verdeutlicht die Verhältnisse an einem Beispiel. Es zeigt ein von drei Personen, Friedrich, Karl-Otto und Theodor, genutztes Mitteilungssystem, nachdem Theodor eine Nachricht A an Karl-Otto und dieser eine Nachricht B an Friedrich und Theodor gesandt hat. Zu beachten ist, daß die Pfeile die Kanten des entstandenen Graphen und nicht etwa Richtungen des Datentransports wiedergeben.

Modulstruktur

gif (Grafik, 3.1 KB)
Modulhierarchie für das Mitteilungs-System

Diese Abbildung zeigt eine sich ergebende Modulhierarchie, die im folgenden motiviert wird. Fest steht zunächst, daß es angebracht ist, das System zu verteilen, denn Sitzungen für Benutzer sollen mit ihnen kommen und gehen, die verwalteten Briefkästen und Mitteilungen dagegen eine Zeitlang resident bleiben. Zu diesem Zweck sollten Knoten nicht nur, wie sonst üblich, lokal in jeweils dem Prozess angelegt werden, der sie hervorruft, sondern alternativ auch in besonders dazu bestimmten länger laufenden Serverprozessen. Eine Methode dafür realisiert das Modul PersMesgMaintenance.

Abgesehen von dieser besonderen Art, Knoten anzulegen, lassen sich alle denkbaren Operationen im Umgang mit Briefkästen und Mitteilungen auf Methoden von Names zurückführen. Die Aufgabe des Moduls PersonalMessages ist es, diese Details zu verbergen und die Operationen in einer problembezogenen Form zur Verfügung zu stellen, sodaß Programme mit Benutzerschnittstellen es möglichst einfach haben, darauf zurückzugreifen. PersMesgClient realisiert eine derartige Schnittstelle, während PersMesgServer ein Hauptprogramm für einen passiven, auf Aufträge von PersMesgMaintenance eingerichteten Namensserver darstellt.


oberon index <- ^ -> mail ?
Weiter: Erzeugung von Knoten in fremdem Auftrag, davor/darüber: Verteilte Anwendungen.
Martin Hasch, Oct 1996