Anhang B: Übersicht über Namensverwaltungen und Verzeichnisdienste

Die in der Literatur unter dem Schlagwort „Naming“ aufgeführten Systeme lassen sich in verschiedene Kategorien einteilen. Dieser Anhang gibt eine Übersicht über bestehende Ansätze zur Namensverwaltung, nimmt eine Klassifikation des Anwendungsspektrums vor, diskutiert Einzelaspekte und beschreibt exemplarisch Konzepte und Realisierungen. Im Fokus stehen dabei Konzepte zur dynamischen und globalen Namensverwaltung.

Anhang B .1: Dynamische Namensverwaltungen

Basis einer Systemkonfiguration ist in der Regel eine zentrale Konfigurationstabelle. Diese enthält die vollständige Spezifikation der Geräteausstattung und Schnittstellenbelegung eines Rechnersystems. Ist eine dynamische Konfigurationsverwaltung in zentralen Systemen vornehmlich eine Frage der Administration, so wird sie in verteilten Systemen durch die größere Gerätebasis und die höhere Dynamik der Systemkomponenten obligatorisch. Das verteilt verfügbare Gerätepotential läßt sich auch nur dann effizient nutzen, wenn ihre Konfiguration flexibel an die Gegebenheiten und Anforderungen angepaßt werden kann.

Der nachfolgende Abschnitt gibt einen Überblick über verschiedene dynamische Namensverwaltungen, die dem Anwender erlauben, den Namensraum selbständig ohne das Eingreifen eines Administrators zu gestalten, und eine dynamische Bindung von Namen an Objekte ermöglichen.

Anhang B .1.1: Statische Konfigurationsverwaltung in SUN Yellow Pages

Die Notwendigkeit zur zentralen Verwaltung von Konfigurationsdaten in Rechnernetzen erkannten auch die Hersteller von Rechnersystemen. Als Folge entstanden zahlreiche Produkte, deren bekanntester Vertreter die in der Netzwerksoftware für SUN-Betriebssysteme enthaltenen „Yellow Pages“ [SUN, 86] sind. Bis zur Einführung dieses Dienstes hielt jeder Knoten im Netzwerk eigene Tabellen mit Eintragungen ihm bekannter Knoten, Netzwerke und enthaltener verfügbarer Dienste. Diese Listen wurden in ausgezeichneten Dateien (z.B.: /etc/hosts, /etc/networks und /etc/services) gehalten und lokal vom System-Administrator verwaltet. Mit den „Yellow Pages“ bot sich nun die Möglichkeit, alle lokalen Tabellen zu einer zentralen Tabelle zusammenzufassen. Der Informationsgehalt der zentralen Tabelle wurde dabei im Vergleich zu den lokalen Tabellen nicht erhöht. Er entspricht nach wie vor dem der lokalen Tabellen und geht somit nicht über Adreß- und Protokollinformationen hinaus. Namen für die Netzwerkkomponenten können nahezu beliebig vergeben werden. Zugriffe auf die zentrale Tabelle sind von Programmen aus über bereitgestellte Bibliotheken möglich. Die Verfügbarkeit der Konfigurationsdaten kann durch Replikation der Tabelle auf ausfallentkoppelten Knoten gesteigert werden. Modifikationen an den Konfigurationsdaten können nur über einen ausgezeichneten Master vorgenommen werden. Eine Weiterentwicklung der „Yellow Pages“ ist der Network Information Service (NIS), der heute mit jedem SunOS ausgeliefert wird.

Eine wesentliche Einschränkung der Konfigurationsverwaltung durch Yellow Pages und NIS liegt in der fehlenden Skalierbarkeit. Durch die Datenhaltung in zentralen Tabellen ist das Konzept lediglich für kleinere Konfigurationen geeignet. Mit zunehmender Zahl der Systemkomponenten ist das Aufkommen an Modifikationen administrativ nicht mehr zu bewältigen. Als Konsequenz ergibt sich, daß die Aktualität der Konfigurationstabellen oft nicht gegeben ist.

Anhang B .1.2 Dynamische Konfigurationsverwaltung in AppleTalk

Eine interessante Alternative zur Konfigurationsverwaltung in der UNIX-Welt bietet das Macintosh Betriebssystem. Mit Hilfe eines Name-Binding-Protokolls können hier zur Laufzeit dynamisch neue Dienste wie Dateiserver und Drucker im Netzwerk bekannt gemacht und ausgewählt werden.

Das AppleTalk Name Binding Protocol (NBP) [Apple, 90] übernimmt in AppleTalk-Netzwerken die Zuordnung von Dienstenamen zu Socket-Adressen. Somit erhalten Dienste, die an Sockets gebunden sind, Namen und können über diese angesprochen werden. Das NBP unterhält für jeden Knoten eine eigene Tabelle mit Namen und Adressen, die dynamisch vereinbart werden. Die Funktionen des NBP erlauben es, Namen an Socket-Adressen in der lokalen Names Table zu binden, wieder zu löschen, nach Einträgen zu suchen und deren Eindeutigkeit zu prüfen. Verwendung finden die Funktionen des NBP beispielsweise im Auswahl-Programm [Denny, 86], um Geräte und Dienste im Netzwerk zu lokalisieren (vgl. Abbildung Anhang B .1).

Ein Eintrag in der Names Table eines Knotens mit Namen und Adresse wird NBP-Tupel genannt. Die Gesamtheit der lokalen Names Tables in einem Netz bildet das Names Directory. Namen in AppleTalk setzen sich zusammen aus Objekt-, Typ- und Zonen-Namen.

< Objekt >.< Typ >.< Zone >

Jede Komponente kann bis zu 32 Zeichen lang sein. Bei der Suche nach Namen auf einem Netzwerk können Wildcards eingesetzt werden. Ein „=“-Zeichen steht hier für alle Typen und Namen. Ein Stern „*“ bedeutet, daß Geräte der lokalen Zone gewünscht werden. So liefert ein Name LookUp mit dem Tupel „=.=.*“ alle benannten Einträge, die in der lokalen Zone bekannt, d.h. in den Names Tables aller Knoten auf dem lokalen Netz vorhanden sind.

Abbildung Anhang B .1: Die Auswahl im Macintosh System

Bei der Registrierung eines Namens wird zunächst mit einem Broadcast im Netzwerk nach dem zu registrierenden Eintrag gesucht, um die Eindeutigkeit zu prüfen. Ist der Eintrag im Netzwerk noch nicht vorhanden, so ist er eindeutig und kann in die lokale Names Table aufgenommen werden. Das Löschen von Einträgen aus der lokalen Names Table geschieht stets lokal ohne Interaktion mit anderen Knoten. Bei der Suche nach benannten Einträgen im Netzwerk wird zuerst die eigene Names Table konsultiert. Anschließend werden Broadcast-Pakete an alle Teilnehmer der spezifizierten Zone übermittelt. Die Knoten im Netz liefern alle Einträge, die der gesuchten Beschreibung (auch Wildcards) entsprechen.

Das NBP ist eine flexible Möglichkeit, kleinere Konfigurationen zu verwalten. Wesentlichster Nachteil des Systems ist die unzulängliche Skalierbarkeit. Diese wird insbesondere durch die Stützung des Protokolls auf die Broadcast-Fähigkeit des Kommunikationsmediums begrenzt. Broadcasts sind in großen Netzwerken extrem teuer und können somit nur in lokalen Netzwerken effizient eingesetzt werden. Außerdem erlaubt im WAN-Bereich oftmals die zugrundeliegende Netzwerktopologie keinerlei Mehrpunktverbindungen (vgl. hierzu [Lupper, 90]). Auch der dreistufige Namensraum des NBP setzt der Skalierbarkeit einer AppleTalk-Konfiguration enge Grenzen, wobei es mit steigender Anzahl der benannten Dienste zunehmend schwieriger wird, aussagekräftige Namen zu finden. Das NBP unterstützt das Vorhalten (Caching) von Namen auf der Anwendungsebene durch eine Funktion zum Verifizieren vorgehaltener Namenseinträge. Im NBP selbst sind keinerlei Mechanismen vorgesehen, um NBP-Tabelleneinträge zu replizieren und vorzuhalten. Häufige Zugriffe auf dieselben Namenseinträge führen somit zu Leistungseinbußen. Nachteilig macht sich auch bemerkbar, daß zwischen dem Namensraum des Dateisystems im Macintosh OS und den NBP-Einträgen des AppleTalk keine Verbindung existiert. Dateinamen und NBP-Namen sind völlig orthogonal zueinander und werden durch unterschiedliche Mechanismen und Programme (Finder und Auswahl) verwaltet.

Anhang B .1.3 Der Windows Internet Name Service (WINS)

WINS [Microsoft, 96] stellt eine dezentralisierte Datenbank für die Registrierung und Auflösung dynamischer NetBIOS-Namen zu IP-Adressen in einer gerouteten Netzwerkumgebung zur Verfügung. Er wurde entworfen, um die Probleme zu lösen, die bei der Auflösung von NetBIOS-Namen in komplexen, gerouteten Netzwerken auftreten.

Die LMHOSTS-Datei behob nur einen Nachteil broadcast-basierter Systeme; sie ermöglichte die Auflösung von Namen über Router hinweg. Da das System selbst immer noch auf Broadcast-Nachrichten basierte, wurden die Probleme des Broadcast-Verkehrs und der Belastung lokaler Knoten nicht gelöst. Die RFCs 1001/1002 behandeln diese Probleme und definieren ein Protokoll, das selbst über Router hinweg die Registrierung und Auflösung von Namen durch Unicast-Datagramme beim NetBIOS-Name Server (NBNS) erlaubt. Dies macht eine LMHOSTS-Datei nicht mehr notwendig, stellt die dynamische Natur der NetBIOS-Namensauflösung wieder her und ermöglicht somit die Kooperation mit dem Dynamic Host Configuration Protocol (DHCP) [Droms, 93]. Wenn beispielsweise die dynamische Adreßzuweisung durch DHCP neue IP-Adressen für Rechner liefert, die sich zwischen Subnetzen bewegen, werden die Änderungen automatisch in der WINS-Datenbank aktualisiert. Weder der Benutzer noch der Netzwerkadministrator muß in solch einem Fall eine Anpassung der Bindung des Namens and die Adresse vornehmen.

Abbildung Anhang B .2: Konfiguration eines WINS-Klienten

Das WINS-Protokoll basiert auf den NBNS-Protokollen, die in den RFCs 1001/1002 definiert wurden, so daß es mit anderen Implementierungen dieser RFCs zusammenarbeitet. Eine andere RFC-konforme Implementierung des Klienten kann den WINS-Server kontaktieren, und genauso kann ein Windows TCP/IP-Klient mit anderen Implementierungen des NBNS-Servers kommunizieren. Weil jedoch das WINS-Server-zu-Server- Replikationsprotokoll nicht im Standard spezifiziert wird, kooperiert der WINS-Server nicht mit anderen Implementierungen eines NetBIOS-Name Servers. Zwischen WINS-Servern und NICHT-WINS NBNS werden daher keine Daten repliziert. Folglich bildet das WINS-System kein gemeinsames Ganzes und die Namenauflösung kann nicht garantiert werden. Das WINS-System besteht aus zwei Hauptkomponenten, den WINS-Servern und den WINS-Klienten.

WINS Server:

· Bearbeitet Aufträge für die Registrierung und Freigabe von Namen von WINS-Klienten und registriert bzw. entfernt ihre Namen und IP-Adressen.

· Antwortet auf Namensanfragen von WINS-Klienten, indem die IP-Adresse des angefragten Namens zurückgegeben wird, sofern der Name vorhanden ist.

· Repliziert die WINS-Datenbank bei einem anderen WINS-Server.

WINS Klient:

· Registriert bzw. löscht seinen Namen beim WINS-Server, sobald er im Netzwerk aktiv bzw. inaktiv wird.

· Kontaktiert den WINS-Server für die Auflösung eines Namens.

Anhang B .1.3.1 Integration von WINS und Domain Name System (DNS)

In Windows NT 4.0 ist Microsoft’s Implementierung von DNS [Mockapetris, 84a] fest in WINS integriert. Dies macht es NICHT-WINS Klienten möglich, NetBIOS-Namen aufzulösen, indem ein DNS-Server kontaktiert wird. Administratoren können nun alle statischen Einträge für Microsoft-basierte Klienten in den Zonendateien von DNS-Servern zugunsten der dynamischen Integration von WINS/DNS entfernen. Wenn beispielsweise ein nicht-Microsoft-basierter Klient eine WWW-Seite auf einem HTTP-Server zugreifen möchte, der DHCP/WINS verwendet, so kann der Klient beim DNS-Server nachfragen, der DNS-Server wiederum kann bei WINS anfragen und der Name kann aufgelöst und die Adresse zum Klienten zurückgegeben werden. Vor der Integration mit WINS gab es wegen der dynamischen Host-Adressierung mit DHCP keine Möglichkeit, den Namen zuverlässig aufzulösen. Die Details über die Integration von WINS und DNS erfährt der Leser im White Paper der WINS Implementierung für Windows NT 4.0 [Microsoft, 97a].

Anhang B .1.3.2 Funktionale Beschreibung von WINS

Die folgende Funktionsbeschreibung behandelt speziell die Registrierung und Auflösung von Namen innerhalb eines WINS-Systems. Broadcast-basierte Systeme können von Zeit zu Zeit zum Vergleich erwähnt werden, werden aber nicht im Detail behandelt.

In einem WINS-System werden alle Namen in einem WINS-Server eingetragen (vgl. Abbildung Anhang B .3). Die Namen werden in einer Datenbank auf dem WINS-Server gespeichert, der Anfragen für die Auflösung von Namen zu IP-Adressen basierend auf den Einträgen in dieser Datenbank beantwortet. Ausfallsicherheit und Lastausgleich werden realisiert, indem mehr als ein WINS-Server im WINS-System installiert wird. Diese Server gleichen ihre Datenbankeinträge periodisch untereinander ab, um die Konsistenz des Namensraums sicherzustellen.

Abbildung Anhang B .3: Die WINS-Datenbank eines WINS-Servers

Jeder Name hat einen Eintrag in der Datenbank. Er wird primär von dem WINS-Server verwaltet, bei dem er registriert wurde, und auf allen anderen WINS-Servern als Kopie gespeichert. Jeder Eintrag besitzt einen Zustand, der ihm zugeordnet ist. Der Namenseintrag kann im aktiven, freigegebenen oder gelöschten Zustand sein. Die Namenseinträge werden zusätzlich mit einer Versionsnummer versehen, die für die Replikation verwendet wird.

Das WINS-System erlaubt auch das Registrieren statischer Namen. Hierdurch kann der Administrator Namen für Betriebssysteme registrieren, die keine dynamische Registrierung von Namen unterstützen. WINS unterscheidet zwischen dynamischen und statischen Einträgen. Statische Namen werden ein wenig anders behandelt als dynamische Namen.

Anhang B .1.3.3 Registrieren, Aktualisieren und Freigeben von Namen

WINS ist eine dynamische Namensverwaltung, die das Registrieren, Aktualisieren und Freigeben von Namen durch Klienten erlaubt (vgl. Statistik eines WINS-Servers in Abbildung Anhang B .5). Die Registrierung von Namen ist eine Anfrage für den Gebrauch eines Namens. Die Anfrage kann für einen eindeutigen Namen oder einen Gruppennamen sein. NetBIOS-Anwendungen können einen oder mehrere Namen registrieren. Namen werden dynamisch durch den Registrierungsvorgang belegt, wobei jede Anwendung mit anderen Anwendungen konkurriert.

Um einen Namen zu registrieren, schickt der Klient einen Name Registration Request direkt zum WINS-Server. Der WINS-Server nimmt die Registrierung an oder weist sie zurück, indem er eine positive oder negative Antwort (Name Registration Response) an den Klienten zurücksendet. Die Maßnahmen, die durch den WINS-Server ergriffen werden, hängen von verschiedenen Faktoren ab, ob der Name bereits in der Datenbank existiert und welchen Zustand dieser besitzt, ob er dieselbe oder eine andere Adresse hat und ob die Registrierung für einen eindeutigen oder einen Gruppennamen erfolgen soll.

Abbildung Anhang B .5: Zugriffsstatistik eines WINS-Servers

Wenn der Name nicht in der Datenbank existiert, wird er dort mit einer Versionsnummer, einem Zeitstempel mit der aktuellen Uhrzeit+Erneuerungsintervall und der Identifikation des primären WINS-Servers eingetragen. Eine positive Antwort auf die Registrierungsanforderung wird gesendet. Das Erneuerungsintervall gibt die Zeit an, die der Namen Gültigkeit besitzt.

Wenn der Name bereits in der Datenbank mit der gleichen IP-Adresse wie angefordert eingetragen ist, so hängen die zu ergreifenden Maßnahmen vom Zustand des Namenseintrags und den Besitzverhältnissen ab. Wenn der Zustand aktiv ist und der Eintrag diesem WINS-Server gehört, wird der Zeitstempel aktualisiert und eine positive Antwort auf die Registrierungsanforderung gesendet. Wenn der Eintrag sich im freigegebenen oder im gelöschten Zustand befindet, oder wenn der Eintrag einem anderen WINS-Server gehört, so wird die Registrierung wie für einen neuen Eintrag behandelt. Der Zeitstempel, die Versionsnummer und die Besitzverhältnisse werden aktualisiert und eine positive Antwort auf die Registrierungsanforderung wird gesendet.

Falls der Name in der WINS-Datenbank bereits unter einer anderen IP-Adresse registriert ist, muß der WINS-Server darauf achten, daß der Name nicht doppelt vergeben wird. Wenn sich der Namenseintrag im freigegebenen oder im gelöschten Zustand befindet, kann der WINS-Server diesen Namen zuweisen. Der Antrag wird wie eine Neueintragung behandelt, und eine positive Name Registration Response wird zurückgesendet. Wenn sich jedoch der Eintrag im aktiven Zustand befindet, muß der Knoten, der den Namen trägt, kontaktiert werden, um zu prüfen, ob er noch im Netzwerk existiert.

Der WINS-Server sendet zuerst ein Wait for Acknowledgment (WACK) zum anfordernden Knoten und gibt eine Zeit an, die der Klient warten sollte, um eine Antwort zu erhalten. Der WINS-Server sendet dann eine Namensanfrage an den Knoten, der in der Datenbank für den Namen registriert ist. Wenn der Knoten existiert, sendet er eine positive Name Query Response an den WINS-Server zurück. Der WINS-Server sendet dann seinerseits eine negative Name Query Response an den anfordernden Knoten und weist damit die Registrierung des Namens zurück. Wenn eine positive Name Query Response empfangen wird, schickt der WINS-Server die Namensanfrage ungefähr in einem Abstand von 500ms zwei weitere Male. Nach drei Versuchen ohne Antwort wird eine positive Name Query Response an den anfordernden Knoten gesendet und der Name wird in die WINS-Datenbank als Neueintragung aufgenommen.

Abbildung Anhang B .7: Konfigurierung der Parameter zur Wahrung der Konsistenz der WINS-Datenbank

Namen, die von WINS verwaltet werden, erhalten bei der Registrierung eine Time to Live (TTL) oder ein Erneuerungsintervall (vgl. Abbildung Anhang B .7). Ein Name muß erneuert werden, bevor diese Zeit verstrichen ist, sonst wird er freigegeben. Es liegt in der Verantwortlichkeit des Klienten, den Namen durch einen Name Refresh Request an den WINS-Server zu erneuern, bevor das Erneuerungsintervall abläuft. Windows NT-Klienten erneuern den Eintrag nach der halben Zeit des Erneuerungsintervalls. Andere Klienten können mit anderen Frequenzen erneuern. Der Klient kann die Erneuerungsfrequenz erhöhen, wenn der WINS-Server nicht auf den Erneuerungsauftrag reagiert. Der WINS-Server behandelt einen Erneuerungsauftrag für einen Namen wie die Registrierung eines Namens.

NetBIOS-Namen können explizit oder implizit freigegeben werden. Namen werden explizit freigegeben, wenn ein Knoten ordnungsgemäß abgemeldet wird. Eine implizite Freigabe tritt gewöhnlich auf, wenn ein Knoten ausfällt oder abgeschaltet wird, und wird vom WINS-Server erkannt, wenn ein Name nicht innerhalb des vereinbarten Zeitintervalls erneuert wird.

Wenn ein Name freigegeben wird, wird der Namenseintrag in der WINS-Datenbank als freigegeben gekennzeichnet und mit einem Zeitstempel aus aktueller Uhrzeit+Löschintervall versehen. Diese Information wird nicht an die replizierenden WINS-Servers weitergegeben. Wenn die Freigabe explizit erfolgt, wird der WINS-Server zum Eigentümer des Namenseintrags, wenn er es nicht bereits ist.

In Windows NT 4.0 wird die Freigabe anders behandelt, wenn die Identifikation des verwaltenden Servers unterschiedlich ist (der Klient gibt den Namen bei einem anderen WINS-Server frei, als er ihn registrierte). In diesem Fall wird der Eintrag als gelöscht gekennzeichnet und der Zeitstempel wird auf die aktuelle Uhrzeit+Löschintervall+Löschauszeit gesetzt. Dieses ist notwendig, um in Windows Inkonsistenzen zwischen einem sekundären und einem primären WINS-Server zu vermeiden. Ohne diese Maßnahme würde der Name auf einen WINS-Server freigegeben und länger als gewünscht auf dem anderen Server aktiv bleiben, weil ein freigegebener Namenseintrag nicht wieder repliziert wird, da er ja bereits einmal repliziert worden ist. Das Versetzen eines freigegebenen Namenseintrags in den gelöschten Zustand erzwingt seine Replikation und synchronisiert die WINS-Datenbanken schneller. War beispielsweise der primäre WINS-Server eines Klienten nicht erreichbar, als er abgeschaltet wurde, so wurde die Namensfreigabe an den sekundären WINS-Server gerichtet. Wäre der primäre WINS-Server wieder verfügbar, sobald der Klient neu bootet, so würde der Klient sich beim primären WINS-Server erneut registrieren und fortfahren seinen Namenseintrag beim primären WINS-Server zu erneuern, der den Klienten noch im aktiven Zustand glaubt. Die Datenbank des sekundären WINS-Servers würde den Klienten im freigegebenen Zustand halten.

Anhang B .1.3.4 Konflikterkennung während der dynamischen Registrierung

Wenn ein Klient einen Namen registriert oder erneuert, kann dieser Name in der WINS-Datenbank bereits existieren. Die Maßnahmen, die durch den WINS-Server ergriffen werden, hängen davon ab, in welchem Zustand sich der Namenseintrag befindet. Der Name kann eindeutig oder ein Gruppenname sein. Er kann statisch oder dynamisch registriert worden sein. Der Namenseintrag kann im Original oder als Kopie vorliegen. Er kann aktiv, freigegeben, oder gelöscht (Grabdenkmal) sein. Die IP-Adresse kann übereinstimmen oder unterschiedlich sein.

Zwei Fälle sind sehr einfach und immer gleich zu behandeln. Die normalen Gruppeneinträge und die statischen Einträge werden nie überschrieben. Der WINS-Server antwortet immer mit einer negativen Name Registration Response auf den Registrierungsauftrag für einen Namen, der in der Datenbank als Gruppenname oder statischer Name eingetragen ist. Spezielle Gruppen erhalten zusätzliche Mitglieder durch eine spezielle Gruppenregistrierung. Im Falle, daß sich der vorhandene Namenseintrag im freigegebenen oder im gelöschten Zustand befindet, erfolgt die Registrierung wie bei einem neuen Eintrag. Hierdurch erhält man eindeutige dynamische Einträge.

Status	Aktion
Owned active	Time stamp
Replica active	Time stamp, take ownership, new version ID
Released	Time stamp, make active, new version ID
Owned tombstone	Time stamp, make active, new version ID
Replica tombstone	Time stamp, take ownership, make active, new version ID

Tabelle Anhang B .1: Aktivitäten in Abhängigkeit vom Zustand des Namenseintrags in WINS

Wenn die IP-Adressen übereinstimmen, liefert der WINS-Server eine positive Name Registration Response und ergreift die in Tabelle Anhang B .1 aufgeführten Maßnahmen. Wenn die IP-Adressen unterschiedlich sind und der Namenseintrag freigegeben oder gelöscht ist, wird die Registrierung wie für einen neuen Namen behandelt. Eine positive Name Registration Response wird zurückgesendet und der Eintrag aktualisiert, um die neue Zeit, den Eigentümer, die neue Versionsnummer und den aktiven Zustand festzuhalten.

Wenn der Namenseintrag sich im aktiven Zustand befindet und eine andere IP-Adresse besitzt, muß der WINS-Server feststellen, ob der Name mit der alten IP-Adresse noch existiert. Eine Namensanfrage wird zum Knoten mit der alten IP-Adresse geschickt. Wenn die alte Adresse mit einer positiven Name Query Response antwortet, weist der WINS-Server seinerseits die Neueintragung mit einer negativen Name Registration Response zurück. Wenn die alte Adresse nicht auf die Namensanfrage reagiert, wird die Neueintragung angenommen.

Anhang B .1.3.5 Namensanfragen in WINS

Namensanfragen werden durch Klienten initiiert, um die IP-Adressen zu NetBIOS-Namen zu ermitteln. Der WINS-Server antwortet auf Abfragen mit einer Liste von IP-Adressen für jeden Namen (mehr als eine Adresse, nur wenn es sich um einen Special Group- oder einen Multihomed-Namen handelt). Der WINS-Server schickt so viele Antworten, wie in ein UDP-Paket passen. Weil Special Groups auf 25 Namen begrenzt sind, passen alle Informationen immer in ein UDP-Paket.

Ein Windows NT 3.5 Rechner fragte nur beim sekundären WINS-Server für die NetBIOS-Namensauflösung nach, falls er keine Antwort vom primären WINS-Server erhielt. Wurde hingegen der NetBIOS-Name nicht in der primären WINS-Datenbank gefunden, kontaktierte Windows NT 3.5 den sekundären WINS-Server nicht. In Windows NT 3.51, Windows 95 und Windows für Workgroups 3.11 wurde die Suchordnung so geändert, daß der sekundäre WINS-Server auch kontaktiert wird, wenn der gesuchte Name nicht in der Datenbank des primären WINS-Servers gefunden wurde.

Abbildung Anhang B .8: Beispiel einer Netzwerk-Konfiguration mit WINS-Servern

Wenn in Abbildung Anhang B .8 Klient B mit Klient C kommunizieren möchte, muß der Name „Klient C“ zur IP-Adresse 128.11.33.104 aufgelöst werden. Klient B sucht dazu zuerst in seinem Namenscache nach der IP-Adresse von „Klient C“. Wenn Klient B den Namen vor kurzem verwendet hat, ist er noch im Cache vorhanden.

Wenn der Namenseintrag mit der Adresse nicht im Cache enthalten ist, schickt Klient B eine Namensanfrage zum WINS-Server WINS A. Wenn WINS A den Namen in seiner Datenbank findet, sendet er eine positive Name Query Response mit der IP-Adresse von Klient C zu Klient B, andernfalls eine negative Name Query Response. Es gibt verschiedene Gründe, warum der Name „Klient C“ nicht in der Datenbank von WINS A gefunden werden könnte:

· Klient C ist noch nicht von WINS B bei WINS A repliziert worden. Der Name kann nicht aufgelöst werden, bis die Replikation erfolgt ist.

· Klient C ist ein Broadcast-Knoten und registriert sich nicht bei WINS. Der Name kann nur aufgelöst werden, wenn er in eine LMHOSTS-Datei eingetragen wird.

· Klient C ist ein DNS-Knoten und kein NetBIOS ist installiert. Der Name kann aufgelöst werden, wenn Klient B so konfiguriert wird, daß er einen DNS-Server kontaktiert.

Erhält Klient B eine negative Name Query Response, so hängt seine Reaktion davon ab, welchen TCP/IP-Protokollstapel er verwendet. Arbeitet Klient B mit dem Microsoft TCP/IP-Stapel, so kontaktiert er den sekundären WINS-Server. Wenn dieser auch eine negative Name Query Response liefert, verteilt Klient B, vorausgesetzt er ist als Broadcast-Knoten konfiguriert, die Namensanfrage per Broadcast. Die Anfrage wird in diesem Fall erfolglos bleiben, weil Klient C sich in einem anderen Netz befindet und der Router Broadcast-Nachrichten nicht weitergibt. Als nächstes würde Klient B in der LMHOSTS-Datei nachschlagen und beim DNS-Server anfragen, um den Namen aufzulösen.

Obwohl RFC 1001 empfiehlt, daß Broadcast-Knoten nicht in gerouteten Netzwerken verwendet werden, befinden sich in der Praxis dennoch gelegentlich Broadcast-Knoten in gerouteten Netzen. Oft gibt es gute Gründe, warum diese Broadcast-Knoten nicht sofort entfernt oder aktualisiert werden können. Aus diesem Grund führte WINS das Konzept der Proxy-Server ein.

Proxy-Server sind Knoten, die auf Namensoperationen (Registrieren, Freigeben, Abfragen) von Broadcast-Knoten achten und für jene Namen antworten, die nicht im lokalen Netz sind. Proxy-Server kommunizieren mit dem WINS-Server mit gerichteten Datagrammen, um die Informationen zu erhalten, die notwendig sind, um auf Broadcast-Nachrichten zu antworten.

Anhang B .1.4 Abschließender Vergleich dynamischer Namensverwaltungen

Die Verwaltung von Geräten und Diensten anhand von Namen ist ein grundlegendes Problem in Betriebssystemen. Unterschiedliche Ansätze zur Geräteverwaltung durch zentrale Tabellen und dynamische Verfahren wurden im vorangegangenen Abschnitt präsentiert.

Die dezentrale dynamische Verwaltung lokal registrierter Dienste und Geräte, wie etwa durch das AppleTalk Name Binding Protocol (NBP), hat gegenüber der Verwaltung zentral administrierter Tabellen den Vorteil, daß sie stets den aktuellen Stand der Gerätebasis widerspiegelt. Ein Nachteil ist die immanente Abhängigkeit von der Mehrpunktfähigkeit des Kommunikationsmediums und die Belastung des Netzwerks und der Rechner durch Broadcast-Nachrichten. Die in NBP verwendeten Methoden zur Namensverwaltung skalieren daher nicht und sind somit nur für den lokalen Netzwerkbereich sinnvoll einsetzbar.

Der Microsoft Windows Internet Name Service (WINS) hat gegenüber anderen Namensverwaltungen den Vorteil, daß er dynamisch eine zentrale Datenbank für Rechnernamen verwaltet. WINS verwaltet die NetBIOS-Namensdatenbank mittels gerichteter Nachrichten, wodurch der IP-Broadcast-Verkehr im Netzwerk reduziert wird und Klienten Rechner in lokalen oder Weitbereichsnetzwerken lokalisieren können. Ferner besteht für Klienten die Möglichkeit in einem Windows NT server-basierten Netz in entfernten Domänen zu blättern, ohne daß ein lokaler Domänen-Verwalter auf der anderen Seite des Routers existiert. Die Skalierbarkeit von WINS ist auf wenige Netzwerksegmente beschränkt, da lediglich eine flache Verwalterstruktur vorgesehen ist. Über Proxy-Server werden Namensoperationen, die auf Broadcast-Nachrichten basieren, über das lokale Netzwerk hinaus wirksam und erhöhen somit die Skalierbarkeit von WINS. Sekundäre WINS-Server steigern die Verfügbarkeit der zentralen WINS-Datenbank und erhöhen die Ausfallsicherheit.

Die Verwaltung von Namen für Systemkomponenten und -objekte muß dynamisch erfolgen, um der wachsenden Dynamik gerade verteilter Systeme gerecht zu werden.

Anhang B .2 Verteilte Dateiverzeichnisse

Eine verbreitete Form der Datenhaltung in verteilten Systemen sind verteilte Dateisysteme. In den letzten Jahren wurde eine Vielzahl von verteilten Dateisystemen entwickelt. Oftmals sind sie Bestandteil verteilter Betriebssysteme (LOCUS, Clouds, Chorus, Amoeba, V-system, SOS, DACNOS, BirliX, MOS etc.). Tannenbaum [Tannenbaum, 85] gibt einen Überblick über die Problematik der verteilten Dateisysteme und trägt hier wesentlich zur Begriffsbildung bei. Borghoff beschreibt in [Borghoff, 89] eine vollständige Charakterisierung verteilter Dateisysteme anhand verschiedener Transparenzarten.

Ein verteiltes Dateisystem ist eine logische Zusammenfassung lokaler Dateiverzeichnisse, die sich auf verschiedenen Rechnern eines Rechnernetzes befinden, zu einem gemeinsamen Dateisystem. Dies führt zur Entkopplung der logischen von der physikalischen Struktur des Dateisystems. Verteilte Dateisysteme erlauben den transparenten Zugriff auf alle Objekte eines verteilten Systems, die unter der Dateiabstraktion zu erfassen sind. Insbesondere in UNIX-Systemen kann somit ein großer Teil der Systemfunktionalität verteilt zugegriffen werden. Zur Konstruktion gemeinsamer Dateiverzeichnisse kommen in verteilten Dateisystemen unterschiedliche dynamische Mechanismen zur Anwendung, die im folgenden dargestellt werden.

Anhang B .2.1 Verteilte Verzeichnisse durch eine zusätzliche Dimension

Auf den ersten Blick neigt man dazu, anzunehmen, daß der Zugriff auf Verzeichnisse entfernter Knoten die Einführung einer zusätzlichen Dimension bedürfe. Schließlich kann derselbe Pfadname auf unterschiedlichen Knoten unterschiedliche Dateien bezeichnen. Diesen Ansatz verfolgte das IBIS-Projekt [Tichy, 84], welches den Versuch unternahm, auf Benutzerebene UNIX BSD-Dateisysteme gemeinsam zu verwenden. In IBIS wurde der Namensraum von Dateien zu einem dreidimensionalen Raum erweitert.

Abbildung Anhang B .9: Vereinigen der Namensräume durch eine zusätzliche Dimension

Bei dieser Methode bestehen Dateinamen aus zwei Komponenten: Einem Knotennamen und dem üblichen UNIX-Pfadnamen (vgl. Abbildung Anhang B .9). Ein Name „Knoten:Pfad“ wird als Pfad auf dem Rechner „Knoten“ interpretiert. Die Komponente „Knoten“ ist dabei optional. Fehlt die Angabe des Knotens, so wird der Pfad lokal interpretiert. Diese Methode bietet Zugriffstransparenz für Dateien. Der Benutzer muß keine Knotenadresse oder Routing-Information angeben. Derselbe Name kann überall im Netzwerk verwendet werden. Dieses Schema ist jedoch nicht rückwärtskompatibel zur UNIX-Namenssyntax. So müssen beispielsweise Programme, die Dateinamen interpretieren, angepaßt werden. Die neue Syntax weist dem Doppelpunkt „:“ eine besondere Bedeutung zu. Außerdem kann die neue Syntax mehrdeutig sein, wie im Beispiel von „Knoten1:Knoten2:Pfad“, in dem „Knoten2:Pfad“ in Knoten1 interpretiert werden kann oder „Knoten1:Knoten2“ die Adresse angeben kann, unter der „Pfad“ interpretiert wird. Auch relative Namen, wie „Knoten1:usr/bin/type“, bereiten Probleme, da nicht festgelegt ist, wozu der Pfadname relativ ist.

Ein ähnliches Konzept zur Bildung eines gemeinsamen Namensraums findet sich auch im Apple File Sharing Protocol [Apple, 87]. Dabei spannen jedoch nicht die Knoten eine weitere Dimension auf, sondern die Volumes eines Knotens. Die Volume-Namen werden dabei transparent an den Pfadnamen angefügt (z.B.: PowerMac:HD250: Dokumente: Informatikbericht).

Anhang B .2.2 Verteilte Verzeichnisse durch eine gemeinsame Wurzel

Einen Mechanismus zur Verbindung lokaler Namensräume, der die Aufgabe der UNIX-Dateinamensyntax nicht erzwingt, bot als eines der ersten Systeme UNIX United der Newcastle Connection [Brownbridge, 82]. Hier wurden UNIX-Dateiverzeichnisse orts- und zugriffstransparent mit Hilfe der sogenannten super root zu einem einzigen Verzeichnis zusammengefaßt.

Abbildung Anhang B .10: Vereinigen der Namensräume durch eine super root

Durch die super root wird eine virtuelle, globale Struktur erzeugt, die alle Unterbäume verbindet (vgl. Abbildung Anhang B .10). Die super root-Einträge sind virtueller Natur und werden durch die Software-Schichten der Newcastle Connection unterstützt. Der Aufstieg vom lokalen Verzeichnis „/“ zur super root wird durch die Sequenz „/..“ erreicht. Daher verweist „/../Knoten 1“ auf die Wurzel des Knotens 1. Auf diese Art bleibt das globale Dateisystem eine Baumstruktur, insbesondere enthält das Dateisystem keine Zyklen[AL1] , mit Ausnahme der konventionellen „.“ und „..“ Zyklen. Den „..“ Bezeichner kommt jedoch eine andere Bedeutung zu als in herkömmlichen UNIX-Systemen.

Anhang B .2.3 Verbinden lokaler Namensräume durch Montieren

Einen anderen Ansatz zur Konstruktion rechnerübergreifender Namensräume verfolgt u.a. das sog. Network File System (NFS) [Sandberg, 85] [SUN, 89], das de facto zum Standard für verteilte Dateisysteme avancierte. NFS ist ein zugriffstransparentes Dateisystem, das von SUN Microsystems, Inc. entwickelt wurde. In NFS ist es möglich, jedes Unterverzeichnis eines entfernten Knotens an jedes lokale Verzeichnis zu binden (mount).

Klienten richten einen knotenübergreifenden Namensraum aus Dateinamen ein, indem sie entfernte Verzeichnisse dem lokalen Namensraum anfügen (vgl. Abbildung Anhang B .11). Diese müssen zuvor von dem Knoten, der sie bereitstellt, explizit exportiert werden. Erst wenn ein Verzeichnis montiert wurde, kann es zugegriffen werden. Der Punkt im lokalen Verzeichnis, in dem das entfernte Verzeichnis montiert wird, kann vom Klienten bestimmt werden. Daher erzwingt NFS keinen systemweiten einheitlichen Namensraum. Entfernte Dateien können auf unterschiedlichen Klienten unterschiedliche Pfadnamen besitzen. Durch die hohe Flexibilität bei der Konstruktion eines verteilten Namensraums erlaubt NFS jedoch ohne weiteres mittels geeigneter Konfigurationstabellen in den Klienten die Realisierung eines einheitlichen Namensraums. Hierdurch kann auch das Ziel der Ortstransparenz weitgehend erreicht werden.

Abbildung Anhang B .11: Montieren von Unterverzeichnissen in NFS

Das Montieren von Verzeichnissen ermöglicht eine dynamische Administration und gibt dem Anwender einen hohen Grad an Freiheit in der Konfiguration seines Dateisystems. Inhärent ist jedoch die Gefahr der Erzeugung eines „Spaghetti“-Systems, wobei entfernte Verweise hin und zurück verweisen können, da jeder Punkt in einem „gemounteten“ Verzeichnis selbst wieder ein „Mount“-Punkt werden kann. Durch den hohen Grad an Transparenz dieses Schemas hat der Ausfall eines Knotens das Verschwinden einer für den Benutzer oft unübersehbar großen Menge von Unterverzeichnissen zur Folge.

Die vorgestellte Methode des Montierens führt eine neue Art von Zyklen in den Namensgraphen ein. Das ist jedoch nicht als zusätzliche Komplikation zu werten, da UNIX selbst bereits symbolische Verweise (Links) unterstützt. Die „Mount“-Methode realisiert die volle Konnektivität von Mount-Punkten, so daß jeder erreichbare Punkt einen Rückwärtspfad besitzt. Volle Konnektivität wird auch verlangt, damit jede Datei im System einen absoluten Pfadnamen besitzt, auch wenn dieser nicht notwendigerweise eindeutig ist.[AL2]

UNIX-Dateisysteme übersetzen beim Zugriff auf Dateien mehrteilige Pfadnamen sukzessive in i-Node-Referenzen. In NFS können Pfadnamen nicht im Server übersetzt werden, da der Pfadname einen „Mount“-Punkt beim Klienten überschreiten kann. Daher werden Pfadnamen geparsed und ihre Übersetzung wird vom Klienten kontrolliert. Jeder Teil eines Namens, der auf ein entferntes Verzeichnis verweist, wird durch eine eigenständige lookup-Anfrage an den Server in ein File Handle übersetzt. In jedem Schritt wird anhand der Mount-Tabelle des Klienten überprüft, ob auf einen anderen Server zugegriffen werden muß. Die Resultate eines jeden Schrittes der Übersetzung des Pfadnamens werden vorgehalten, um die Effizienz dieses Vorgangs zu erhöhen. Dabei macht man sich die Lokalität von Dateireferenzen zunutze. Programm und Benutzer greifen typischerweise auf Dateien zu, die sich nur in einem oder wenigen Verzeichnissen befinden.

Abschließend seien nochmals die Schwächen des NFS resümiert:

• Die Schaffung einer einheitlichen ortstransparenten Struktur der Verzeichnisse ist nur durch manuelle Administration möglich. Die notwendigen Mechanismen stellt NFS hierfür bereit, die adäquate Ausführung bleibt jedoch letztendlich dem Systemadministrator überlassen.

• NFS bietet keine Migrationstransparenz. Wechselt ein Benutzer den Knoten, so findet er eine andere Verzeichnisstruktur vor.

• Eine Änderung der Verzeichnisstruktur impliziert eine aufwendige manuelle Administration der Mount-Tabellen eines jeden Klienten.

• Verzeichniseinträge und Dateien befinden sich in NFS immer auf demselben Knoten. Eine Replikation von Verzeichniseinträgen ist nicht vorgesehen. Lediglich die Zugriffszeit auf entfernte Einträge wird durch das Vorhalten von Pfadnamen verkürzt.

• NFS bietet keine globale Struktur, die alle Dateien weltweit verwaltet, sondern faßt immer nur die Verzeichnisse kleinerer und mittlerer Rechnerverbunde zu einem einheitlichen Namensraum zusammen.

• NFS verwaltet nur Systemobjekte, die sich der UNIX-Dateienabstraktion unterordnen. Allgemeine Objekte moderner Betriebssysteme sind durch dieses Konzept nicht erfaßt.

Parallel zu NFS entstand am Information Technology Center (ITC) der Carnegie-Mellon University in Pittsburgh, USA das Andrew File System (AFS) [Howard, 88], [Morris, 86], [Satyana., 85] [Satyana., 90a] [Satyana., 90b]. AFS entwickelte sich aus den Vorläufersystemen VICE/Virtue/Venus. Im Laufe der Zeit erfuhr das System mehrere grundlegende Revisionen und wurde schließlich als AFS3 zum Produkt. Das DFS in OSF DCE stellt ebenfalls eine Überarbeitung von AFS3 dar. Eine Weiterentwicklung von AFS ist Coda [Satyana., 87], das in erster Linie eine hohe Ausfallsicherheit und Skalierbarkeit anstebt. Coda bietet im Gegensatz zu AFS zusätzlich Unterstützung zur Behandlung modifizierter Replikationen bei Vorliegen einer Netzwerkpartitionierung.

Abbildung Anhang B .13: Lokale und gemeinsame Namensräume in AFS

AFS unterscheidet auf der Anwendungsebene zwischen lokalen und gemeinsamen Namensräumen für Dateinamen (vgl. Abbildung Anhang B .13). Der gemeinsame Namensraum ist auf allen Arbeitsstationen identisch und erscheint, obwohl er über mehrere Server verteilt ist, den Klienten völlig homogen. Da Dateinamen keine Kennung des Servers enthalten, besteht für eine Anwendung keine Möglichkeit, aus dem Pfadnamen den Server zu ermitteln, der eine bestimmte Datei enthält. Der lokale Namensraum ist klein und enthält entweder Dateien für die lokale Initialisierung oder Temporärdateien. In der Praxis befinden sich nahezu alle Dateien, die ein Anwender benutzt, im gemeinsamen Namensraum. Ein Anwender kann daher die Arbeitsstation wechseln und behält eine konsistente Sicht seiner Dateien.

Sowohl der lokale als auch der gemeinsame Namensraum in AFS ist hierarchisch strukturiert und ähnlich dem eines UNIX-Dateisystems. In der UNIX-Terminologie repräsentiert der lokale Namensraum das root file system einer Arbeitsstation und der gemeinsame Namensraum wird bei der Initialisierung der Arbeitsstation auf das Verzeichnis „/cmu“ montiert. Da die Namen aller gemeinsamen Dateien das Präfix „/cmu“ teilen, kann problemlos zwischen lokalen und entfernten Dateien unterschieden werden. Der Namensraum wird unterteilt in eigenständige Unterbäume, die jeweils von einem einzigen Server verwaltet werden.

AFS unterstützt im Gegensatz zu NFS nicht nur das Vorhalten von Verzeichniseinträgen, sondern auch das Vorhalten und die Replikation von Dateien. Hierdurch wird in AFS eine weit höhere Skalierbarkeit erreicht, als dies in NFS aus Leistungsgründen realisierbar ist.

Anhang B .2.4 Einheitliche gemeinsame Verzeichnisstruktur in LOCUS

Alle bisher beschriebenen Systeme vereingen konventionelle UNIX-Dateisysteme verschiedener Knoten, um einen verteilten logischen Verzeichnisbaum zu realisieren. Einen völlig anderen Ansatz verfolgt das LOCUS System [Walker, 83] [Popek, 87], das an der University of California at Los Angeles entwickelt wurde. LOCUS realisiert realisiertdie Verteilung des Systems auf der Ebene einzelner Dateien. Dem Benutzer wird ein einziger UNIX-ähnlicher Verzeichnisbaum präsentiert, der sich aus logischen Dateigruppen (file groups) zusammensetzt. Als Dateigruppen dienen Plattenpartitionen mit eigenen Dateisystemen und den zugehörigen Tabellen mit i-Nodes. Die einzelnen Dateigruppen werden durch einen Mount-Mechanismus zusammengebunden. Die zugehörigen Mount-Tabellen sind auf allen Knoten repliziert. Eine Dateigruppe alloziiert bestimmte Plätze im Netzwerk, die als physikalische Container bezeichnet werden und der Aufnahme von Dateien und i-Nodes dienen. Eine gegebene Datei besitzt gewöhnlich mehrere Replikationen, die in verschiedenen logischen Containern gespeichert werden, um die Zuverlässigkeit des Dateisystems zu erhöhen. Es wird jedoch immer nur ein konventioneller UNIX-Dateisystembaum unterhalten. Replikation findet auf der Basis von i-Nodes statt.

Abbildung Anhang B .14: Verteilung eines LOCUS-Verzeichnisses auf file groups

Jede Datei und jedes Verzeichnis in LOCUS ist einer Menge von physikalischen Containern auf verschiedenen Knoten zugeordnet (vgl. Abbildung Anhang B .14). Zusätzlich zu den normalen Informationen in UNIX i-Nodes unterhält LOCUS Versionsvektoren, die angeben, wo die Versionsnummer eines jeden physikalischen Containers gespeichert wird. Die Konflikterkennung vergleicht die Versionsvektoren unterschiedlicher physikalischer Kopien. Der Aufwand hierfür verhält sich jedoch quadratisch zur Anzahl der Replikationen und setzt somit der Skalierbarkeit des Systems Grenzen. LOCUS garantiert die Konsistenz replizierter Dateien und Verzeichnisse, sofern keine Partitionen auftreten. Wird die Verbindung zwischen replizierten Verzeichniseinträgen unterbrochen, so übernimmt LOCUS den automatischen Abgleich (Mischen) der Namensverzeichnisse, die unabhängig voneinander in verschiedenen Partitionen geändert wurden.

In LOCUS wird in jedem Knoten eine Tabelle mit „Mount“-Punkten und physikalischen Containern für alle Dateigruppen des Systems unterhalten. Geht man davon aus, daß jeder Knoten wenigstens einen physikalischen Container unterhält, so ist der systemweite Speicheraufwand für diese Tabellen und die Konsistenzprüfung von quadratischer Ordnung (vgl. [Barak, 86]).

Anhang B .2.5 Abschließender Vergleich verteilter Dateiverzeichnisse

Abschließend werden die verschiedenen Methoden zur Schaffung gemeinsamer Namensräume in verteilten Dateisystemen noch einmal gegenübergestellt. Tabelle Anhang B .1 gibt eine Zusammenfassung der Vergleichskriterien.

Die meisten der im vorangegangenen Abschnitt diskutierten Systeme sind konform zur UNIX-Dateinamenssyntax, wodurch , wdem Anwender der Einsatz verteilter Dateisysteme erleichtert wird. Alle vorgestellten Systeme bieten, zumindest bedingt, Orts- und Zugriffstransparenz, wobei LOCUS durch den einheitlichen Namensraum den höchsten Grad an Ortstransparenz realisiert. Weiterentwickelte Transparenzformen wie Fehler- und Replikationstransparenz offerieren lediglich LOCUS, AFS und Coda.

	IBIS	UNIX United	Novell Netware	Locus	NFS	AFS	Coda
Transparenz	Orts, Zugriffs, Replikations	Orts, Zugriffs	Orts, Zugriffs	Orts, Zugriffs, Replikations, Fehler	Orts, Zugriffs	Orts, Zugriffs, Replikations	Orts, Zugriffs, Replikations
Namensraum-mechanismus	zusätzliche Dimension	super root	Montieren von Volumes auf Pfade	gemeinsamer Verzeichnis-baum	Montieren entfernter Verzeichnisse	Montieren entfernter Verzeichnisse	Montieren entfernter Verzeichnisse
Namenssyntax	UNIX, modifiziert	UNIX	DOS	UNIX	UNIX	UNIX	UNIX
Replikation von Verzeichnissen	Nein	Nein	Nein	Ja	Nein	Ja	Ja
Vorhalten von Verzeichnissen	Nein	Nein	Nein	Ja	Ja	Ja	Ja
Replikation von Dateien	Ja	Nein	Nein	Ja	Nein	Ja	Ja
Partitionen	Nein	Nein	Nein	Ja	Nein	Nein	Ja
Skalierbarkeit	LAN	LAN	Betrieb	LAN	LAN	global	global

[AL3] Tabelle Anhang B .1: Gegenüberstellung der Eigenschaften verteilter Dateisysteme

Durch die Replikation von Verzeichniseinträgen und Dateien wird die Skalierbarkeit der Systeme erhöht und die Verfügbarkeit und Zugriffszeit optimiert. Dabei gewährleistet sowohl LOCUS als auch Coda bei vorliegenden Netzwerkpartitionen die Konsistenz replizierter Verzeichniseinträge und Dateien durch Merge-Protokolle.

Verteilte Dateiverzeichnisse werden durch unterschiedliche Mechanismen gebildet. Gegenüber der wenig transparenten Anfügung des Rechnernamens als Präfix und der super root-Methode hat sich die Mount-Methode durchgesetzt. Sie bietet sowohl Transparenz als auch lokale Autonomie. Verteilte Dateisysteme, die das Montieren entfernter Verzeichnisse unterstützen, geben dem Anwender die Möglichkeit zur individuellen Gestaltung ihres Namensraums. Verzeichnisse können, die entsprechenden Rechte vorausgesetzt, dynamisch in den Namensraum eingefügt und entfernt werden. Das Montieren entfernter Verzeichnisse erfordert jedoch die lokale Verwaltung von Mount-Tabellen. Hierdurch wird maßgeblich die Skalierbarkeit verteilter Dateisysteme bestimmt, so daß deren Ausdehnung auf lokale bis mittlere Netzwerke beschränkt bleibt.

Die Restriktion auf die Verwaltung von Dateien und Verzeichnissen in verteilten Dateisystemen impliziert, daß in den zugehörigen Namensräumen lediglich Objekte erfaßt werden, die der Dateiabstraktion genügen. Allgemeine Objekte im Sinne des objekt-orientierten Programmierparadigmas oder Rechner- und Netzwerknamen sind in diesen Verzeichnissen nicht erfaßt. Verteilte Dateisysteme bedienen sich ihrerseits zur Lokalisierung von Rechnern anhand von Namen globaler Namensverwaltungen. Interne Verweise auf Verzeichnisse entfernter Rechner betreffen somit außer das Dateiverzeichnis auch andere Namensräume.

Die Namensräume verteilter Dateisysteme sind dynamisch modifizierbar und bieten einen hohen Grad an Transparenz. Sie verwalten jedoch lediglich Objekte, die der Dateiabstraktion genügen, und erfordern einen erheblichen administrativen Aufwand, der die Skalierbarkeit einschränkt.

Anhang B .3 Dynamisch verwaltete Objektverzeichnisse

Im Rahmen der Betriebssystementwicklung zeichnet sich immer mehr ab, daß Dateien als Datenabstraktion von Objekten, die den Konzepten der objekt-orientierten Programmierparadigmen nahe stehen, abgelöst werden. Moderne Betriebssysteme haben das Prozeßkonzept als Ausführungsumgebung und das Dateikonzept als Datenabstraktion, wie es z.B. in UNIX-Systemen vorherrscht, aufgegeben. Gemäß dem Objekt-Modell wird das verteilte System als Menge kooperierender Objekte betrachtet. Eine strukturierte Darstellung der Daten in Form typisierter Objekte erleichtert die Verarbeitung und definiert exakt diejenigen Methoden, die auf bestimmte Typen von Objekten anwendbar sind. Es wird keine Kenntnis über die interne Repräsentation der Daten vorausgesetzt. Das Objekt ist durch seinen Typ und die verfügbaren Methoden vollständig charakterisiert. Der Zugriff auf Objekte kann somit typensicher gestaltet werden. Unvollständige Objektspezifikationen erlauben es Objekte zu ermitteln, die ähnliche Funktionalität besitzen [Ravindran, 91a].

Namensverwaltungen übernehmen in objekt-orientierten Systemen , wie NEXUS [Tripathi, 87], MUSE [Yokote, 88], SOS [Shapiro, 89], COOL [Habert, 90], Vangard [Finlayson, 91] die Aufgabe, die notwendigen Informationen für die Aktivierung von Objekten bereitzustellen und eine Objektbeschreibung durch den Objekttyp und die anwendbaren Methoden zu verwalten. Der Zugriff auf Objekte kann, falls bekannt, durch die Angabe des Objektnamens oder aber auch durch die Angabe von Objekteigenschaften, wie Objekttyp und implementierte Methoden, erfolgen. Objekte werden dabei dynamisch an Namen gebunden.

Anhang B .3.1 Namen zur Objekt-Invokation durch Request Broker

Die Objekt Management Group (OMG), eine 1989 gegründete Interessengemeinschaft verschiedener Unternehmungen der Informationsindustrie mit dem Ziel der Förderung und Verbreitung objekt-orientierter Techniken, entwickelte mit der Common Object Request Broker Architecture (CORBA) [OMG, 91] [Bayer, 93] eine objekt-orientierte Plattform für verteilte, heterogene Anwendungen.

Zentrale Komponente ist der Object Request Broker (ORB), der mittels eindeutiger Objektreferenzen lokations- und implementierungsunabhängige Objektaufrufe ermöglicht. Gemäß dem Objekt-Modell wird das verteilte System als Menge kooperierender Objekte betrachtet. Der ORB ermöglicht die Kooperation zwischen den Objekten in heterogenen, verteilten Umgebungen. Er stellt Mechanismen zur Verfügung, mit denen Klienten Operationen auf anderen Objekten ausführen. Dazu nimmt der ORB Aufrufe von Klienten entgegen (gemäß definierter Schnittstellen), sucht eine passende Instanz eines Objekts, das diesen Aufruf ausführen kann, übergibt den Aufruf an das Objekt und schickt die Ergebnisse nach Beendigung des Aufrufes an den Klienten zurück. Der Klient sieht dabei nur die Schnittstelle des Objekts, nicht jedoch die Lokation oder die Art der Implementierung des Objekts selbst. Schnittstellen werden in einer vorgegebenen Schnittstellen-Notation wie beim RPC beschrieben. Die verschiedenen Schnittstellendefinitionen werden in einem Interface Repository abgelegt, wo sie zur Laufzeit zugänglich sind, z.B. um dynamisch zur Laufzeit Aufrufe auf einem Objekt zu tätigen, das zum Zeitpunkt der Kompilation noch nicht bekannt war.

Eine Besonderheit des ORB-Konzepts sind zwei unterschiedliche Möglichkeiten, Objekte aufzurufen. Zum einen sind, wie beim DCE RPC, sogenannte statische Stub-Interfaces vorgesehen, die durch eine Interface Definition Language (IDL) beschrieben werden, zum anderen können Methodenaufrufe dynamisch über ein generisches Interface konstruiert werden. Hier hat der Klient die Möglichkeit, zur Laufzeit aus einem Interface Repository die Schnittstellenbeschreibung zu erfragen und daraus einen Methodenaufruf zu erzeugen.

Die bisherige Arbeit der OMG beschäftigte sich primär mit dem Aufruf sowie der Installation von Objekten. Zur Zeit wird aber auch der Einsatz eines Trading-Dienstes geprüft. Konkrete Ergebnisse sind jedoch noch nicht in Erfahrung zu bringen.

Anhang B .3.2 Dynamische Namensverwaltung für Trading

Verteilte Systeme offerieren eine Vielzahl von Diensten. Mit steigender Anzahl der in verteilten Systemen verfügbaren Dienste und Nutzer werden neue Konzepte für das Netzwerkressourcen-Management benötigt, da sowohl die Anbieter von Diensten als auch die Dienstenehmer untereinander konkurrieren. Angesichts der Vielzahl der angebotenen Dienste steht der Klient vor der schwierigen Aufgabe, den für seine Anforderungen adäquaten Dienstanbieter zu selektieren. Die für eine solche Entscheidung notwendigen Informationen, wie z.B. die speziellen Eigenschaften eines Servers, sind von der Anwendung kaum mehr beherrschbar. Dies führte dazu, daß in neueren verteilten Umgebungen ein zusätzlicher Dienst integriert wird, der sog. Trading-Dienst. Ein Klient wendet sich mit einer Dienstanfrage an einen Trader, der den Trading-Dienst realisiert. Der Trader seinerseits ermittelt das verfügbare Diensteangebot im System und versucht bei einer Dienstanfrage den für den Klienten geeigneten Dienstanbieter zu ermitteln.

Trading in verteilten Systemen ist ein relativ neues Konzept. In seiner Grundform kann es als ein Mechanismus betrachtet werden, welcher angeforderte Dienstleistungen auf verfügbare Dienstanbieter abbildet. Der Trading-Dienst bietet somit gegenüber gebräuchlichen Namensverwaltungen zusätzliche Funktionalität.

Abbildung Anhang B .15: Kollaboration des Traders mit der Namensverwaltung

Namensverwaltungen liefern auf Anfragen, die generische Namen oder attributierte Beschreibungen des gesuchten Objekts enthalten, u.U. eine Menge von Objekt-Bezeichnern. Da auf die Beschreibung eines Objekts somit eine Vielzahl von Objekten zutreffen kann, bieten verschiedene fortgeschrittene Namensverwaltungen Gruppennamen an, die es erlauben, gleichartige Objekte unter einem gemeinsamen Namen anzusprechen. Es bleibt dem Benutzer schließlich überlassen, aus der Menge der ermittelten Objekte das für ihn adäquate Objekt zu extrahieren.

Das Konzept des Traders geht nun einen Schritt weiter. Es versucht den Auswahlprozeß für den Klienten transparent vorzunehmen. Hierzu übergibt der Klient dem Trader ähnlich wie zuvor der Namensverwaltung lediglich eine Beschreibung des gesuchten Objekts, inklusive Art und Anforderungen an den angeforderten Dienst. Der Trader wird nun seinerseits die Namensverwaltung kontaktieren, um Objekte, die den spezifizierten Dienst offerieren, zu lokalisieren (vgl. Abbildung Anhang B .15). Eventuell in der Anfrage vorhandene dynamische Dienstattribute werden direkt beim Dienstanbieter erfragt. Schließlich wird der Trader aus der Menge der von der Namensverwaltung gelieferten Objekte unter verschiedenen Optimalitätskriterien eine Auswahl für den Klienten treffen. Die Optimalitätskriterien können dabei entweder vordefiniert oder bei der Anfrage vom Klienten spezifiziert sein. Der Trader entbindet Klienten somit von der besonders in verteilten Systemen häufig anzutreffenden Informationskomplexität der Diensteverwaltung.

Objekt-orientierte Systeme, Trading-Dienste und Request Broker in verteilten Systemen setzen stets Namensverwaltungen voraus, die neben der Objektinvokation anhand des Objektnamens auch den dynamischen Aufruf von Objekten anhand einer Objektbeschreibung ermöglichen.

Anhang B .4 Globale Namensverwaltungen

Der folgende Abschnitt präsentiert exemplarisch Systeme und Konzepte zur Verwaltung globaler Namensräume. Globale Namensverwaltungen basieren auf dem Rekursionsprinzip, das die Delegation von Zuständigkeiten für Unterbereiche von Namensräumen erlaubt und somit eine verteilte Operation erst ermöglicht. Sowohl die Namensverwalter als auch der Namensraum selbst sind hierarchisch organisiert. Während frühe Systeme Namensräume mit einer festen Anzahl von Hierarchiestufen verwalteten, brachte die Generalisierung des Prinzips der hierarchischen Namensverwaltung Systeme hervor, die sowohl im Namensraum als auch bei der Verwalterhierarchie keine Beschränkung mehr aufwiesen. Beispiele für beide Arten von Systemen und Mischformen finden sich im folgenden Abschnitt.

Anhang B .4.1 Grapevine und Clearinghouse

Grapevine [Birell, 82] ist ein verteiltes Mailsystem, das unter anderem auch Dienste zur verteilten Namensverwaltung und zur Authentisierung von Benutzern und Servern anbietet. Der von Grapevine verwaltete Namensraum ist zweistufig. Namen haben die Form

<Benutzer>.<Bereich>

Die beteiligten Namensverwalter sind dezentral organisiert und administrieren jeweils einen oder mehrere Bereiche. Die Namenseinträge eines Bereichs sind im allgemeinen bei mehreren Namensverwaltern repliziert. Die Konsistenzerhaltung der Replikate erfolgt durch ein Zeitstempel-basiertes Verfahren. Der Wurzelkontext, also der Kontext aller Bereiche, wird nicht durch einen bestimmten Namensverwalter verwaltet, sondern wird bei allen Namensverwaltern repliziert. Dadurch wird die Einführung einer zentralen Instanz vermieden und die Anzahl der erforderlichen Nachrichten pro Anfrage reduziert. Zur Verwaltung dieser Replikate wird ein spezielles Verfahren mit stärkerer Konsistenzgarantie verwendet. Anfragende Klienten halten sich Namen und zugehörige Adressen in einem Cache. Den Anwendungsprogrammen selbst und nicht dem Namensverwalter obliegt es, veraltete Einträge zu erkennen. Neben einzelnen Benutzereinträgen unterstützt das System auch Gruppennamen. Erfahrungen mit dem Betrieb des Systems im Hinblick auf seine Leistungsgrenzen werden in [Schroeder, 84] diskutiert. Dabei wird zum Beispiel deutlich, daß durch die Replikation des Wurzelkontextes in sehr großen Systemen Speicher zum kritischen Faktor werden kann. Ferner wirken sich die Verzögerungen bei der Propagierung von Änderungen teilweise deutlich auf Anfragen in Form von temporären Inkonsistenzen aus. Allerdings wurde auch gezeigt, daß mit einer geeigneten Verwalterkonfiguration durchaus mehrere tausend Benutzernamen verwaltet werden können.

Ein Folgesystem von Grapewine ist das bei Xerox entwickelte Verzeichnissystem Clearinghouse [Oppen, 83]. Clearinghouse erweitert den zweistufigen Namensraum von Grapewine zu einem dreistufigen Namensraum. Namen haben die Form

<lokaler Name>:<Bereich>:<Organisation>.

Benannte Objekte haben einen eindeutigen primären Namen sowie optional auch mehrere Synonyme. Ein Name kann auf eine Reihe von typisierten Attributen mit entsprechenden Attributwerten abgebildet werden. Umgekehrt können Attribute auch zur Spezifikation von Namensanfragen auf der Basis unvollständiger Information vorgegeben werden[AL4] . Ein Attributwert kann sich auch wiederum aus einer Menge von Namen zusammmensetzen. Auf diese Weise ist Clearinghouse auch in der Lage, Gruppennamen zu unterstützen. Die Verwalterstruktur besteht aus mindestens einem Namensverwalter pro Bereich innerhalb einer Organisation und wiederum mindestens einem globalen Namensverwalter für jede Organisation. Diese Namensverwalter werden nach Bedarf repliziert. Mehrere Namensverwalter für verschiedene Bereiche können innerhalb eines physikalischen Knotens zusammengefaßt werden. Zusätzlich werden die Adressen aller globalen Organisations-Namensverwalter in jedem Namensverwalter auf jeder Ebene repliziert. Auf diese Weise werden – wie auch in Grapevine – Anfragen optimiert und ein hoher Grad an Fehlertoleranz erreicht. Zur Replikationsverwaltung wird ebenfalls ein Zeitstempel-basiertes Verfahren mit abgeschwächter Konsistenzgarantie verwendet. Das Vorhalten (Caching) von Namen wird auf Ebene der Bereichs-Verwalter eingesetzt. Dadurch ist es möglich, Anfragen nach Namen in Bereichen anderer Organisationen zu behandeln, ohne den entsprechenden Organisationsverwalter einbeziehen zu müssen. Zum Schutz der Verzeichniseinträge bietet Clearinghouse zusätzlich einen Authentisierungsdienst an.

Anhang B .4.2 DEC Global Name Service

Der von Lampson et. al. [Lampson, 86] vorgeschlagene und am DEC Systems Research Center implementierte Global Name Service (GNS) zielte hauptsächlich auf die Handhabung globaler Namensräume mit langlebigen Objekten ab. Dabei war die Verfügbarkeit gegenüber der Zugriffseffizienz von vorrangiger Bedeutung. GNS verfolgt das Ziel der Anpassungsfähigkeit an die Veränderungen und das Wachstum von Netzwerkstrukturen. Das Wachstum des Namensraums hat Freiheitsgrade in der Breite und in der Tiefe, erlaubt Verbindungen zu Unterverzeichnissen, die Restrukturierung des Namensraums und die Kombination von Teilbäumen. Schutzaspekte sind durch Zugriffsfunktionen auf Verzeichnisse und Einträge gegeben, die Schreib-, Lese-, und Testfunktionen zulassen.

Abbildung Anhang B .16: Die Verzeichnisstruktur von GNS

Der Global Name Service realisiert ein System zur Verwaltung hierarchischer Namensräume mit beliebiger Schachtelungstiefe. Die Namen in GNS sind analog zu hierarchischen Dateinamen strukturiert, haben also beispielsweise die Form „EC/DE/UNI/ULM/INFORMATIK“. GNS ist für sehr große Systeme konzipiert und betont daher Möglichkeiten zur dynamischen Erweiterung des Namensraums und der Anzahl der Namensverwalter. Im Gegensatz zu anderen Ansätzen wie zum Beispiel dem Stanford Naming Service ist keine feste Anzahl von Hierarchiestufen der Namensverwalter vorgesehen. Prinzipiell können in GNS Namensverwalter wie auch Namen in beliebig vielen Hierarchiestufen organisiert sein.

Das System verwaltet Namenverzeichnisse für Dateien und berücksichtigt aus diesem Grund keine kurzlebigen Verarbeitungsobjekte. Die kleinste Einheit der Replikation ist das Verzeichnis. Einheiten der Abstraktion sind aus Sicht des Klienten Verzeichnisse und deren Einträge, aus Sicht des Administrators Kopien von Verzeichnissen und Verwaltern, auf denen diese implementiert sind.

Verzeichnisse gleichen Niveaus werden prinzipiell bei mehreren Namensverwaltern repliziert. Die Replikate werden durch ein Zeitstempel-Verfahren schwach konsistent gehalten. Aktualisierungen erfolgen periodisch in Form eines logischen Rings zwischen den replizierenden Namensverwaltern. Die Konsistenz dieser Verzeichnisse wird durch ein Aktualisierungsprotokoll gewahrt, das die im Ring replizierten Namensverzeichnisse anhand von Zeitmarken prüft und aktualisiert. Die Verwendung von Zeitmarken erübrigt die explizite Synchronisation von Aktualisierungsschritten, impliziert jedoch eine exakte gemeinsame Systemzeit. Der Replikationsgrad kann verändert werden, indem Namensverwalter dynamisch in einen Ring eingegliedert bzw. aus ihm ausgegliedert werden. Zusätzlich können Aktualisierungen auch sofort weitergemeldet werden, ohne aber eine zuverlässige Nachrichtenübertragung in jedem Fall zu garantieren. Im Sinne hoher Verfügbarkeit und zur Steigerung der Zugriffsgeschwindigkeit schlägt Lampson ein lokales Vorhalten (Caching) mit garantiertem Gültigkeitsintervall vor.

Zur Gewährleistung einer dynamischen Evolution des Namensraums wird neben der Hierarchie von Kontexten auch ein verteiltes Verzeichnis aller vorhandenen Kontexte mit eindeutigen Kontextnummern geführt (vgl. Abbildung Anhang B .16). Dies ermöglicht es dann zum Beispiel, zwei Namensräume (z.B. die zu „EC“ und „NA“ gehörigen) unter einem neuen Wurzelkontext (z.B. WORLD) zusammenzufassen und immer noch die alten Namen weiterzuverwenden. Dazu werden im neuen Wurzelkontext Verweise eingeführt, die eine Identifikation der nun eingefügten Unterkontexte ermöglichen. Im Beispiel würde der gegebene Name „EC“ auf den neuen Namen „WORLD/EC“ abgebildet, wobei die Abbildungsfunktion die korrekten Kontextnummern liefert. Diese Methode erlaubt auch andere Umstrukturierungen, so zum Beispiel das Anfügen eines existierenden Teilbaums an eine Zwischenebene eines anderen Teilbaums.

Zusammenfassend läßt sich festhalten, daß GNS erfolgreich Fragen der Skalierbarkeit und der Rekonfiguration behandelt. Die Vorschläge zum Abgleich und zum Verschieben von Verzeichnisbäumen erfordern jedoch eine Datenbank mit well-known-directories, die in allen Knoten repliziert ist. In globalen Netzwerken können Rekonfigurationen auf allen Ebenen auftreten, so daß diese Datenbank sehr schnell wachsen kann, wodurch die Skalierbarkeit begrenzt ist.

Anhang B .4.3 Namensverwaltung im Stanford Naming Service (V-System)

Eines der bekanntesten verteilten Betriebssysteme ist das V-System [Cheriton, 88]. Im V-System integriert ist der Stanford Naming Service [Cheriton, 84a], [Cheriton, 84b], [Cheriton, 86], der in seinen Konzepten und seiner Realisierung [Cheriton, 89] als sehr effiziente globale Namensverwaltung gewertet werden kann. Der Stanford Naming Service basiert auf den Multicast-Eigenschaften des V-Kernels und klientenseitigen Präfixlisten [Welch, 86].

Alle Namen bilden einen einzigen Namensraum. Der Namensraum im V-System besitzt einen hierarchischen Aufbau mit dynamisch variabler, beliebiger Schachtelungstiefe. Dies ist vor allem erforderlich, um Dateinamen des verteilten Dateisystems in V mit beliebigen Hierarchien von Dateiverzeichnissen zu verwalten. Die Namensverwaltung beschränkt sich aber nicht auf Dateinamen, sondern erlaubt die Verwaltung beliebiger Objektnamen. Eine weitere Besonderheit der Namensverwaltung im V-System ist, daß ein bestimmter Name immer zusammen mit dem zugehörigen Objekt gespeichert wird. Der Grund hierfür ist, daß Namen und benannte Objekte nur gemeinsam benutzbar sind, also ein verfügbarer Namensverwalter ohne verfügbaren Objekt-/Dateiserver oder umgekehrt nicht von Nutzen ist. Außerdem wird davon ausgegangen, daß eine Namensabbildung immer auch einen Objektzugriff impliziert; daher werden durch die gemeinsame Speicherung entfernte Zugriffe auf zwei getrennte Server vermieden. Dieser Entwurf ist allerdings stark durch die speziellen Eigenschaften der verteilten Dateiverwaltung motiviert und ist nicht ohne weiteres generalisierbar.

Zur Handhabung hierarchischer Namen bzw. Namenspfade stehen im Stanford Naming Service Zugriffsmechanismen, wie absolute und relative Namen sowie die Kennzeichnung des Wurzelverzeichnisses und aktueller Verzeichnisse zur Verfügung. Das verteilte Betriebssystem V [Cheriton, 88] unterstützt ein Modell zur Namensverwaltung bestehend aus drei Schichten. Auf der obersten Schicht werden Namen, die aus Zeichenketten bestehen, Objekten zugeordnet. Diese symbolischen Namen sind kontextabhängig, wobei jeder Namensverwalter seinen eigenen Kontext besitzt, und unter Verwendung eines Prefixing-Verfahrens nach Typen partitioniert. Jeder Klient besitzt dabei eine Caching-Tabelle für die Abbildung eines Prefix auf den zuständigen Namensverwalter.

Obwohl ein Namensraum in System V beliebig viele Hierarchiestufen umfassen kann, sind die Namensverwalter fest auf drei Hierarchiestufen angesiedelt, die sinngemäß als global, administrativ und direkt verwaltend bezeichnet werden (vgl. Abbildung Anhang B .17). Die Namensverwalter der verschiedenen Hierarchieebenen sind in Multicast-Gruppen zusammengeschlossen, von denen jeder Namensverwalter seine Lage im Namensbaum kennt. Die Namensverwaltung adressiert im Normalfall, d.h. bei Vorliegen des Namens oder Teilen des Namens in der Präfixliste, direkt den Namensverwalter, der eine Namen-Objekt-Bindung verwaltet. Im Fall des Fehlens oder der Ungültigkeit eines Eintrags werden alle partizipierenden Namensverwalter mittels Multicast auf Kenntnis des Namens geprüft. Dies vermeidet im Normalfall, daß durch Anforderungen der Namensverwaltung im Netzwerk zusätzlicher Kommunikationsaufwand entsteht.

Zusätzliche Sicherheit bei Ausfall und Initialisierung der hierarchischen Namensverwaltung ist bei V dann gegeben, wenn sich die Multicast-Eigenschaften über das lokale Netzwerk hinaus in den Bereich globaler Netze ausdehnen lassen. Bei Ausfall oder Initialisierung von Namensverwaltern kann bei Namensverwaltern benachbarter Netzwerke nach Namensinformationen gesucht werden. Notwendige Voraussetzungen hierzu sind eindeutige, vom Senderknoten unabhängige Knotenadressen, die Möglichkeit, Knotengruppen zu bilden und zu adressieren und die Möglichkeit, Datagramme zwischen beliebigen Knoten auszutauschen.

Ein Namensverwalter auf administrativer Ebene repliziert alle Namen, die zu den ihm zugeordneten, direkt verwaltenden Namensverwaltern gehören, jedoch nicht die benannten Objekte. Anfragen innerhalb eines administrativen Bereichs können durch einen Multicast an alle direkt verwaltenden Namensverwalter abgewickelt werden; eine Besonderheit des Systems V ist es, einen solchen Multicast sehr effizient innerhalb eines Teilnetzes zu unterstützen. Falls der entsprechende Namensverwalter nicht verfügbar ist und nach Timeout nicht antwortet, kann immer noch der administrative Namensverwalter befragt werden, ob der entsprechende Name überhaupt gültig ist oder nicht.

Abbildung Anhang B .17: Namenshierarchie im V-System

Anfragen in einem fremden administrativen Bereich werden über die globalen, replizierten Namensverwalter abgewickelt, die replizierte Verzeichnisse der administrativen Namensverwalter führen. Multicast-Anfragen werden also tatsächlich nur innerhalb eines administrativen Bereiches benötigt; systemweit wären sie im allgemeinen aus Aufwandsgründen nicht vertretbar. Für die Replikation von administrativen und globalen Namensverwaltern werden zeitstempel-basierte Verfahren vorgeschlagen; die Replikation wird jedoch nicht vollständig realisiert.

Ein direkt verwaltender Namensverwalter speichert komplette Teilbäume des Namensraums zusammen mit den benannten Objekten. Zusätzlich halten sich die Klienten einen Cache von früher bereits interpretierten Namen mit den zugehörigen Namensverwaltern. Ein Cache-Eintrag wird immer nur zur Anfrage bei dem jeweiligen Namensverwalter verwendet und enthält nicht selbst die Objektdaten. Dadurch werden veraltete Einträge in jedem Fall erkannt. Die Cache-Einträge müssen nicht vollständige Namen enthalten, sondern lediglich den Präfix-Anteil des Namens, der zur Identifikation eines Namensverwalters durch Präfix-Vergleich erforderlich ist. Durch diese Technik kann ein Eintrag einen ganzen Teilbaum von Namen repräsentieren.

In [Cheriton, 89] wird zudem ein Mechanismus zur Authentisierung und Zugriffskontrolle vorgeschlagen, der jedoch nicht vollständig implementiert wurde. Eine Besonderheit hierbei ist, daß auch Namensverwalter eine Autorisierung zur Verwaltung eines bestimmten Namensbereiches benötigen, also nicht a priori als vertrauenswürdig erachtet werden. Zur Autorisierung erhalten sie von Klienten verschlüsselte Capabilities.

Anhang B .4.4 Das Internet Domain Name System (DNS)

Die Entwicklung von der zentralen Konfigurationstabelle hin zur globalen Namensverwaltung wird besonders gut anhand des DARPA^[1] Internet deutlich. Ausgehend von einer auf manueller Basis am Network Information Center zentral verwalteten Host-Tabelle mit Zuordnungen von Rechnernamen zu Netzwerkadressen entwickelte sich mit zunehmender Ausdehnung des Internet die ursprünglich zentrale Konfigurationsverwaltung schrittweise zum Domain Name System [Austein, 87] [Mockapetris, 87a].

DNS wurde von Mockapetris [Mockapetris, 84a] vorgeschlagen, um das bisherige Prinzip der Namensverwaltung im Internet abzulösen. Vor DNS wurden alle Host-Namen und Adressen in einer einzigen zentralen Datei auf dem NIC Name Server [Pickens, 79] gehalten. Bei Bedarf wurde diese Datei via FTP von diesem Server von diesem Rechnergeladen (vgl. [Harrenstein, 85]). Diese zentrale Namensverwaltung im Internet stieß schnell an ihre Grenzen, da sie nicht skalierbar war und mit der rasant wachsenden Anzahl von Knoten im Internet nicht schritthalten konnte. Außerdem wollten lokale Organisationen ihre eigenen Systeme zur Namensverwaltung betreiben und administrieren. Zusätzlich entstand der Bedarf nach einer allgemeinen Namensverwaltung, die nicht nur in der Lage ist, Rechneradressen zu ermitteln.

Der größte Unterschied von DNS zu anderen Systemen besteht in der Skalierbarkeit. Millionen von Namen werden weltweit von DNS im Internet verwaltet und Anfragen werden auf der ganzen Welt gestellt. Durch die hierarchische Partitionierung der Namensdatenbank, die Verwendung von Replikation und durch das Vorhalten (Caching) von Anfrageergebnissen kann jeder Name in relativ kurzer Zeit von jedem Klienten aufgelöst werden.

Namen in DNS werden als Domain-Namen bezeichnet. Der aufgespannte Namensraum besitzt eine Baumstruktur (vgl. Abbildung Anhang B .19). Ein Domain-Name wird aus mehreren Zeichenketten, labels genannt, konkateniert, die durch Punkte „.“ separiert werden. Am Anfang und am Ende eines Domain-Namens findet sich kein Separator. Für administrative Zwecke wird die Wurzel des DNS-Namensraums gelegentlich durch einen Punkt „.“ gekennzeichnet. Domains sind Ansammlungen von Domain-Namen. Syntaktisch repräsentiert das gemeinsame Suffix den enthaltenen Domain-Namen, ansonsten ist er nicht von einem Rechnernamen zu unterscheiden. Hierzu ist anzumerken, daß die Bezeichnung „Domain-Name“ etwas verwirrend ist, da nur wenige Domain-Namen auch tatsächlich Domains bezeichnen.

Abbildung Anhang B .19: Die Struktur des Domain Name System

Prinzipiell können in DNS alle Arten von Objekten benannt und willkürliche Attribute verwaltet werden. Die Architektur des Systems läßt viele Freiräume und erlaubt verschiedene Implementierungen, wobei jede ihren eigenen Namensraum unterstützen kann. In der Praxis wird jedoch nur eine Implementierung von DNS flächendeckend eingesetzt, nämlich diejenige, die im Internet Host-Namen von Rechnern auf deren IP-Adressen abbildet. Als Attribute zu den Namen werden dann in den Name Servern IP-Adressen gespeichert.

Eine Anfrage an DNS wird durch den Domain-Namen, eine Klasse und einen Typ spezifiziert. Für die Auflösung von Internet-Adressen nach Namen wurde eine spezielle Domain eingerichtet, die IP-Netzwerknummern enthält. Die Klasse wird verwendet, um beispielsweise die Internet-Namensdatenbank von den anderen, experimentellen DNS-Namensdatenbanken zu unterscheiden. Für eine bestimmte Datenbank ist eine Menge von gültigen Typen definiert.

Der DNS-Namensraum im Internet ist organisatorisch und geographisch partitioniert. Namen werden in einer Notation angegeben, die die Domain der höchsten Ebene ganz rechts aufführt. Kommunikationspartner werden im Internet durch hierarchisch strukturierte Namen identifiziert, die auf Internet-Adressen abgebildet werden. Prinzipiell kann ein Domain-Name beliebig viele Teilkomponenten enthalten. In der Praxis werden häufig 3–4 Komponenten verwendet. Die Namensstruktur korrespondiert im allgemeinen nicht mit der hierarchischen Adreßstruktur. So können zum Beispiel zwei physikalisch völlig getrennte Teilnetze unter der gleichen Domain zusammengefaßt werden. Die Namenskomponenten auf der obersten Hierarchieebene sind standardisiert. Sie enthalten für Adressen außerhalb der USA eine geographische Landeskennung aus zwei Buchstaben. Innerhalb der USA wird organisatorisch dagegen feiner unterschieden (vgl. Tabelle Anhang B .2).

Wie Tabelle Anhang B .2 verdeutlicht, hat die von den USA ausgehende Evolution des DNS-Namensraums zu einem globalen System und die dezentrale Administration der Domains in der Namensstruktur von Domain-Namen zu Inkonsistenzen geführt. So sind die organisatorischen Bereiche COM, EDU, MIL, GOV, NET etc. innerhalb der USA direkt unter der Wurzel neben den geographischen Domain-Namen anderer Länder wie DE, UK, JP etc. zu finden. Innerhalb der Domains für die übrigen Länder sind dabei in der Regel die Domains für die Bereiche COM, EDU, MIL, GOV, NET etc. entweder durch andere Domain-Namen (z.B. in Österreich oder Großbritannien EDU durch AC) ersetzt oder fehlen gänzlich (z.B. in Deutschland oder der Schweiz). In manchen Fällen wird das Fehlen der organisatorischen Domain durch Einbringen eines zusätzlichen Separators in den Namen kaschiert. So müßte konsequent der Domain-Name „uni-ulm.de“ lauten „ulm.uni.edu.de“. Aus diesen Inkonsistenzen resultieren erhebliche Schwierigkeiten bei der Ableitung eines Domain-Namens aus der postalischen Adresse. Es bleibt an dieser Stelle noch festzuhalten, daß auch wenn ein Name ein geographisches Suffix wie „de“ enthält, eine enthaltene Domain z.B. „macs.polarcamp.de“ nicht notwendigerweise in Deutschland positioniert sein muß. Mit anderen Worten, Domain-Namen sind ortsunabhängig.

Top-Level-Domain-Name	Bedeutung
COM	Kommerzielle Organisationen (in den USA)
EDU	Bildungseinrichtungen (in den USA)
GOV	Regierungsstellen (in den USA)
MIL	Militärische Einrichtungen (in den USA)
NET	Netzwerk Provider und Betreiber im Internet
ORG	Andere Organisationen
INT	Interne Organisationen
USA	Ländercode für die USA
UK	Ländercode für Großbritannien
DE	Ländercode für Deutschland
AU	Ländercode für Australien
FR	Ländercode für Frankreich
JP	Ländercode für Japan
etc.	Ländercodes für geographische Zuordnungen
firm	Firmen (geplant Mitte 1997)
store	Online-Shopping (geplant Mitte 1997)
web	Dienste im World-Wide Web (geplant Mitte 1997)
arts	Kunst und Kultur (geplant Mitte 1997)
rec	Hobby und Unterhaltung (geplant Mitte 1997)
info	Informationsdienste (geplant Mitte 1997)
nom	Für persönliche Namen im Internet (geplant Mitte 1997)

Tabelle Anhang B .2: Verwendete Top Level Domain-Namen im Internet

Organisationen und enthaltene Abteilungen können ihre eigenen Namensdaten verwalten. Die Administration von Sub-Domains kann Domains überlassen werden. Die Domain „informatik.uni-ulm.de“ – die Fakultät für Informatik der Universität Ulm – kann jeden beliebigen Namen enthalten, den die Fakultät wünscht. Der Domain-Name „informatik.uni-ulm.de“ selbst jedoch ist mit der Administration der Universität abzustimmen, die die Domain uni-ulm.de verwaltet. Ähnlich ist der Name der Domain „uni-ulm.de“ mit den Verwaltern der Top-Level-Domain „de“ zu koordinieren, usw.

DNS-Server akzeptieren keine relativen Namen. Alle Namen beziehen sich auf die globale Wurzel. Anwendungsprogramme können jedoch an Namen, die nur aus einer einzigen Komponente bestehen, die Bezeichnung des Default-Domain-Namens anhängen und damit die Auflösung veranlassen. Erst wenn diese fehlschlägt, wird der einfache absolute Name direkt an den Name Server an der Wurzel weitergegeben.

Die Skalierbarkeit des DNS wird durch eine Kombination aus Partitionierung der Namensdatenbank, Replikation und Vorhalten von wiederholt verwendeten Einträgen erreicht. Die DNS-Datenbank ist über eine logische Struktur von Name Servern verteilt. Jeder Name Server enthält einen Teil der Namensdatenbank, primär die Daten für seine lokale Domain. Die meisten Anfragen beziehen sich auf Rechner in der lokalen Domain und können von Servern der lokalen Domain behandelt werden. Darüber hinaus hält jeder Name Server eine Liste mit Domain-Namen und Adressen anderer Name Server, so daß Anfragen, die Einträge außerhalb des Administrationsbereichs des Servers betreffen, an diese Server delegiert werden können.

Die DNS-Namensdaten werden in Zonen unterteilt (vgl. Abbildung Anhang B .21). Eine Zone enthält Angaben über die Attribute von Namen in einer Domain, die Namen und Adressen von Name Servern mit maßgeblichen Daten für eine Zone und für delegierte Unterzonen und Parameter für das Management der Zone, wie für das Vorhalten (Caching) und die Replikation. Einem Name Server kann die Verwaltung der maßgeblichen Informationen für eine oder mehrere Zonen übertragen werden. Um die Verfügbarkeit von Namensdaten zu gewährleisten, auch wenn einzelne Name Server ausfallen, sieht die DNS-Architektur vor, daß jede Zone auf mindestens zwei voneinander unabhängigen Servern zu replizieren ist. Die maßgeblichen Daten für eine Zone werden vom Systemverwalter in Form einer Konfigurationsdatei bereitgestellt. Es gibt zwei Arten von Servern, primäre Server, die ihre Daten direkt aus der lokalen Konfigurationsdatei lesen, und sekundäre Server, die ihre Zonendaten vom primären Server laden. Der sekundäre Server prüft periodisch die Aktualität seiner Daten. Die vom Systemadministrator als Zonenparameter vorgegebene Frequenz der Validierung beträgt ein bis zwei Kontrollen pro Tag.

Abbildung Anhang B .21: Domains und Zonen in DNS

Jeder Server kann sich vorbehalten, Daten von anderen Servern vorzuhalten, um wiederholte Anfragen für dieselben Namen zu vermeiden. Bevorzugt werden Namen, zugehörige Adressen und befragte Server auf den unteren Serverebenen sowie durch die anfragenden Klienten vorgehalten. Cache-Einträge werden nicht generell durch Nachfrage beim entsprechenden maßgeblichen Server verifiziert, sondern nur auf explizite Anforderung eines Klienten hin. Die Einträge einer Zone haben einen time-to-live-Wert (TTL-Wert) als Parameter. Ein Server notiert den TTL-Wert eines vorgehaltenen Eintrags. Der Eintrag steht den Klienten für Anfragen exakt in dieser Zeitspanne zur Verfügung. Nach Ablauf dieser Frist werden Anfragen wieder an den maßgeblichen Server verwiesen und somit die vorgehaltenen Einträge verifiziert. Der Administrator einer Zone kann für jeden Eintrag den TTL-Wert entsprechend der Variabilität der gebundenen Attribute definieren. Falls die minimalen Zeitintervalle zwischen Namensänderungen an die jeweiligen TTL-Werte angepaßt sind, sind aktuelle Cache-Einträge in der Regel korrekt. Die meisten Namensanfragen können daher im Internet sehr effizient bearbeitet werden.

Bei der Namensinterpretation ist generell ein Name Server für eine bestimmte Zone verantwortlich. Die Server an der Wurzel der Hierarchie von Name Servern (root server) halten in der Praxis Einträge für mehrere Ebenen von Domains und nicht, wie man vermuten könnte, nur Einträge der ersten Ebene von Domain-Namen. Ebenso können in untergeordneten Servern mehrere Ebenen übersprungen werden. Diese Maßnahme resultiert aus der Notwendigkeit zur Reduzierung der Navigationsschritte. Die Einträge der Root Domain sind repliziert und jeder DNS-Name Server kennt die Adresse von mindestens einem globalen Name Server, der für den Kontext auf der obersten Ebene zuständig ist. Zusätzlich speichert ein Server auch die Adresse des Servers der ihm übergeordneten Domain. Dadurch kann jede Anfrage prinzipiell von einem lokalen Name Server direkt an einen globalen Server weitergegeben werden, um dann eine iterative Interpretation zu beginnen (vgl. Abbildung Anhang B .23). Lokale Namen werden aber direkt vom lokalen Name Server interpretiert. Im Schnitt kann eine Anfrage durch nur zwei Resolutionsschritte aufgelöst werden.

Abbildung Anhang B .23: Iterative Auflösung des Namens my.mac.gov.au in DNS

Gegebenenfalls werden Anfragen nach Ablauf einer Zeitspanne wiederholt gesendet. Für den Fall des Ausfalls eines Servers kann dem Klienten eine Liste von Servern vorgegeben werden, die sukzessive kontaktiert werden sollen. Die DNS-Architektur erlaubt sowohl die rekursive als auch die iterative Navigation. Rekursive Navigation bindet jedoch Server-Prozesse (oder erfordert zustandsorientierte Protokolle bei nur einem Prozeß), so daß sie in der Regel keine Verwendung findet.

Mechanismen zur dynamischen Anpassung von Verzeichniseinträgen von Seiten der Anwender wurden in DNS nicht integriert, da DNS nur für die Verwaltung selten modifizierter Namenseinträge konzipiert wurde. Die Domain Name System Working Group der Internet Engineering Task Force (IETF) hat diesen Mangel inzwischen erkannt und reagiert. So wird in [Rekhter, 94a] ein Verfahren vorgeschlagen, um dynamisch eine Anpassung der Einträge in DNS durchführen zu können. Unabhängig davon hat Ohta ein weiteres Verfahren [Ohta, 94b] skizziert, um DNS-Einträge anzupassen. Diese Ansätze, DNS aufzuwerten, können jedoch nur als Versuche gewertet werden, die Defizite des DNS zu mildern. An der prinzipiell statischen Natur des DNS ändern sie wenig.

Anhang B .4.5 Abschließender Vergleich globaler Namensverwaltungen

Zusammenfassend läßt sich bemerken, daß alle vorgestellten globalen Namensverwaltungen hierarchische Namensräume mit fester oder variabler Anzahl von Hierarchiestufen für Namen von Benutzern, Rechnern oder Dateien unterstützen. Die zugehörigen Namensverwalter werden nach Organisationen oder Netzwerkbereichen hierarchisch organisiert. Lediglich der Global Name Service und der Stanford Naming Service ermöglichen eine beliebige Anordnung der Namensverwalter in einer Hierarchie. Zur Steigerung der Ausfallsicherheit und Erhöhung der Fehlertoleranz werden die Namenseinträge der vorgestellten Systeme zumindest auf den oberen Hierarchieebenen repliziert. Um wiederholte Namensanfragen zu beschleunigen, halten Klienten Namenseinträge vor. Lediglich Clearinghouse und DNS unterstützen das Vorhalten von Namenseinträgen in regionalen Namensverwaltern. Zur Konsistenzerhaltung vorgehaltener und replizierter Namenseinträge werden zeitstempel-basierte Verfahren mit schwacher Konsistenzgarantie verwendet. Der DEC Global Name Service realisiert eine ringförmige, periodische Propagierung von Änderungen.

	Grapevine	Clearinghouse	Global Name Service	Stanford Naming Service	Domain Name System
Art der benannten Objekte	Benutzer	Rechner	Dateisysteme	Dateien, bel. Objekte	Rechner
Art des Namensraums	2 stufig, hierarch.	2 stufig, hierarch.	beliebig, hierarch.	beliebig, hierarch.	beliebig, hierarch.
Gruppennamen	Ja	Ja	Ja	Nein	Nein
Synonyme	Nein	Alias	Alias	Alias	Alias
Attributierte Anfragen	Nein	Ja	Nein	Nein	Nein
Art der Namensauflösung	transitiv	rekursiv	iterativ	iterativ, parallel	iterativ
Kommunikation	Point to Point	Point to Point	Point to Point	Multicast	Point to Point
Verteilung der Nameserver	Bereich	Bereich, Organisat.	beliebig	bel. auf 3 Ebenen	Organisat.
Art des Vorhaltens	klientenseitig	regional	klientenseitig	klientenseitig	regional
Fehlertoleranz	Ja	Ja	Ja	Ja	Ja
Replikationskonsistenz	Zeitstempel	Zeitstempel	Zeitstempel	Zeitstempel	Zeitstempel
Rekonfiguration	Nein	Nein	Ja	Nein	Nein
Dynamische Verwaltung	Nein	Nein	Nein	Nein	Nein
Objektmigration	Nein	Nein	Nein	Nein	Nein
Authentisierung	Ja	Ja	Ja	Nein	Nein

Tabelle Anhang B .4: Gegenüberstellung der Eigenschaften globaler Namensverwaltungen

Clearinghouse unterstützt als einziges der vorgestellten Namensverwaltungen attribut-basierte Namensanfragen mit der Möglichkeit, auch generische Anfragen zu stellen. Bis auf DNS und den Stanford Naming Service unterstützen alle Systeme auch Gruppennamen, und mit Ausnahme von Grapevine bieten alle Namensverwaltungen Alias-Namen.

Die Interpretation eines Namens erfolgt meist syntaxgesteuert mit automatischer Identifikation des geeigneten Servers. Bei der Auflösung von Namen kommen vorwiegend iterative, jedoch auch transitive und rekursive Verfahren über Punk-zu-Punkt-Verbindungen zum Einsatz. Der Stanford Naming Service ermöglicht zusätzlich die parallele Auflösung von Namen über Broadcast-Nachrichten. In DNS kann ein Klient aber durch Angabe eines Suchpfades explizit Einfluß auf diesen Vorgang nehmen, während GNS die Einrichtung einer Working Root erlaubt.

Die Rekonfiguration globaler Namensverwaltungen ist ein von vielen Systemen vernachlässigtes Problem. Die Reorganisation des Namensraums erfordert in den meisten Systemen ein manuelles Rekonfigurieren des Verwalternetzes oder das Entfernen und Neueintragen von Namenseinträgen. Nur GNS ermöglicht eine flexible dynamische Erweiterungen und Reorganisation des Namensraums und des zugehörigen Verwalternetzes im laufenden Betrieb. Keine der vorgestellten globalen Namensverwaltungen erlaubt das dynamische Registrieren und Freigeben von Namen durch Klienten und bietet somit auch keine Unterstützung bei der Migration benannter Objekte.

Erst die hierarchische Organisation des Namensraums und der zugehörigen Namensverwalter ermöglicht eine effiziente Verteilung der Zuständigkeiten und bietet die für globale Namensverwaltungen notwendige Skalierbarkeit.

Anhang B .5 Globale Verzeichnisdienste

Mit zunehmender Ausdehnung der Netzwerke verlangen die Anwender nach Namensverwaltungen, die eine ähnliche Funktionalität wie Telefonverzeichnisse besitzen. Um an die gesuchten Informationen zu gelangen, können Anwender unterschiedlichste Anfragen an Verzeichnisdienste für Netzwerk-Ressourcen stellen, die weit über die an ein einfaches Telefonverzeichnis hinausgehen. Mögliche Anfragen sind beispielsweise

• das Ermitteln der E-Mail Adresse eines bestimmten Benutzers (White Pages).

• das Anzeigen der Namen und Telefonnummern aller chinesischen Restaurants in Ulm (Yellow Pages).

• das Ermitteln persönlicher Daten, wie die Größe, das Gewicht, die Augenfarbe oder das Bild einer Person.

Enthält das Verzeichnis Einzelheiten über System-Ressourcen und Dienste, so kann ein derartiger Verzeichnisdienst dieselben Anforderungen erfüllen, wie eine konventionelle Namensverwaltung. Er kann aber ebenso benutzt werden, um generische Anfragen zu bearbeiten, die darauf abzielen, Informationen über Benutzer oder Netzwerkressourcen zu sammeln. Benutzer können in Anfragen anhand von Bescheibungen Dienste identifizieren, die bestimmten funktionalen Anforderungen genügen, und sie können das Verzeichnis nach spezifischen Informationen durchsuchen, auch wenn sie nur partielle Kenntnisse über Namen, Struktur oder Inhalt besitzen. Einzelpersonen und Organisationen nutzen einen Directory Service, um ein breites Spektrum an Informationen über sich selbst oder über Dienste, die sie im Netzwerk zur Verfügung stellen, anzubieten.

Anhang B .5.1 Der X.500 Directory Service

Um ein breites Spektrum von Anfragen an globale Verzeichnisse zu unterstützen, wurde von der CCITT (Commité Consultatif International de Télégraphique et Téléphonique) [CCITT, 89] und der ISO (International Standards Organisation) [ISO, 88] der X.500- bzw. ISO 9594-Standard zur attribut-basierten Namensverwaltung verabschiedet. Zusätzliche Normen (ISO 9594-1 bis 9594-8 bzw. CCITT X.500 bis X.521) regeln Detailaspekte, wie zum Beispiel Protokolle zum entfernten Zugriff auf Namensverwalter oder Klassen für Namensattribute. X.500 ist im ISO/OSI-Schichtenmodell als Dienst der Anwendungsebene spezifiziert, aber sein Entwurf wurde in keiner Weise als Erweiterung des OSI-Modells ausgerichtet, vielmehr kann X.500 als Entwurf für einen universell einsetzbaren Verzeichnisdienst betrachtet werden.

Bereits in der Namensgebung der Standardisierungsorganisationen CCITT und ISO, die X.500 als „Directory Service“ und nicht als „Naming Service“ bezeichnet, drückt sich der Unterschied zu herkömmlichen Namensverwaltungen, wie DNS und GNS aus, die lediglich dazu dienen Namen aufzulösen, die exakt bekannt sind. Der Standard zielt darauf ab, Informationen über Personen bereitzustellen, kann aber ebenso gut für die Verwaltung von Informationen über andere System- und Netzwerkressourcen herangezogen werden.

Die in X.500-Verwaltern gespeicherten Daten sind wie in anderen Namensverwaltungen in einer Baumstruktur organisiert. In X.500 wird jedoch in jedem Knoten im Baum eine Vielzahl von Attributen gespeichert. Der Zugriff kann jedoch nicht nur über Namen erfolgen, sondern auch über jede denkbare Kombination von Attributen. Der X.500-Namensbaum wird als Directory Information Tree (DIT) bezeichnet. Die gesamte Verzeichnisstruktur zusammen mit den knotenbezogenen Daten wird Directory Information Base (DIB) genannt. Es wird beabsichtigt, eine einzige integrierte DIB aufzubauen, die alle Informationen zur Verfügung stellt, die weltweit von Organisationen angeboten werden. Die DIB ist partitioniert. Teile der DIB befinden sich in einzelnen X.500-Verwaltern und können in verschiedenen Verwaltern repliziert sein. Eine größere Organisation sollte mindestens einen Verwalter bereitstellen, der die Details der Einträge der Organisation enthält.

Der Namensraum in X.500 wird in Kontexte aufgeteilt, wobei jeweils ein Verwalter einen oder mehrere Kontexte administriert. Jeder Eintrag in der DIB besteht aus einem Namen und einer Menge von Attributen. Wie in anderen Namensverwaltungen auch, korrespondiert der vollständige Name eines Eintrags mit dem Pfad durch den DIT, der von der Wurzel zum Eintrag führt. In Ergänzung zu vollständigen oder absoluten Namen kann ein Klient einen Kontext einrichten, der einen Basisknoten miteinbezieht, und so kürzere relative Namen verwenden, die den Pfad vom Basisknoten zum Namenseintrag beschreiben.

Abbildung Anhang B .25: Die Verzeichnisstruktur von X.500

Abbildung Anhang B .25 zeigt die Struktur eines DIT. Die Datenstrukturen für die Einträge der DIB und des DIT sind sehr flexibel. Ein DIB-Eintrag besteht aus einer Menge von Attributen, wobei jedes Attribut sich aus einem Typ und einem Wert zusammensetzt. Die Attribute können mehrwertig sein und so auch Gruppennamen unterstützen. Der Typ eines Attributs wird durch einen Typnamen festgelegt (z.B.: CountryName, OrganisationName, CommonName, TelephoneNumber, ObjectClass). Neue Attributtypen können bei Bedarf definiert werden. Zu jedem einzelnen Typnamen existiert eine korrespondierende Typdefinition, eine Syntaxdefinition in ASN.1-Notation zur Beschreibung aller zugelassenen Werte eines Typs. Eine Besonderheit ist, daß die Namenshierarchie ebenfalls unter Verwendung solcher Attribute als Teilkomponenten der Namen definiert wird. Der Name eines DIB-Eintrags, der die Position im DIT-Baum bestimmt, wird durch die Auswahl eines oder mehrerer seiner Attribute als bevorzugte Attribute festgelegt. Die für diesen Zweck ausgewählten Attribute werden als Distinguished Name eines Eintrags bezeichnet.

DIB-Einträge werden in einer ähnlichen Art und Weise klassifiziert, wie es bei Objektklassen in objekt-orientierten Programmiersprachen gebräuchlich ist (vgl. Abbildung Anhang B .25). Jeder Eintrag beinhaltet ein Objektklassenattribut, das die Klasse eines Objekts bestimmt, auf das der Eintrag verweist. Country, Organisation und Document sind Beispiele für objectClass-Werte. Weitere Klassen können bei Bedarf definiert werden. Die Definition einer Klasse bestimmt, welche Attribute obligatorisch und welche fakultativ für Einträge einer bestimmten Klasse sind. Die Definitionen der Klassen sind in einer Vererbungshierarchie organisiert, in der alle Klassen mit Ausnahme der topClass über ein objectClass-Attribut verfügen und die Werte des objectClass-Attributs den Namen einer oder mehrerer Oberklassen enthalten müssen. Gibt es mehrere objectClass-Werte, dann vererbt das abgeleitete Objekt die obligatorischen und die optionalen Attribute jeder Oberklasse. Eine Unterklasse erbt also die Namensattribute der Oberklassen. Dadurch ist eine flexible Modellierung von attributierten Namensräumen möglich.

Abbildung Anhang B .26: Die Interaktionen von DUA und DSA

Die Namensinterpretation in X.500 erfolgt dezentral. Klienten greifen auf das Verzeichnis zu, indem sie eine Verbindung zu einem der X.500-Namensverwalter herstellen und ihre Anfragen absetzen. Klienten können sich mit jeder Anfrage an jeden Verwalter wenden. Falls die gewünschten Informationen nicht in dem Teil des Verzeichnisses vorhanden sind, der vom kontaktierten Verwalter verwaltet wird, so wird dieser zur Beantwortung der Anfrage andere Verwalter hinzuziehen oder den Klienten an einen anderen Verwalter verweisen. Zur verteilten Durchführung von Namensanfragen werden im Standard verschiedene Verfahren vorgeschlagen, unter anderem die hierarchische Verkettung der an einer Suche beteiligten Namensverwalter, die Möglichkeit einer Multicast-Anfrage bei verschiedenen Namensverwaltern und ein iteratives Suchverfahren, das immer wieder über die initiierende Instanz läuft und ihr immer präzisere Information über die zu befragenden Namensverwalter liefert.

Zur Kommunikation zwischen Namensverwaltern wird ein sogenanntes Directory System Protocol (DSP) definiert. Die Kommunikation einer Anwendung mit einem Namensverwalter erfolgt über das sogenannte Directory Access Protocol (DAP). In der Terminologie des X.500-Standards werden Verwalter als Directory System Agents (DSAs) und Klienten als Directory User Agents (DUAs) bezeichnet. Abbildung Anhang B .26 zeigt die Softwarearchitektur und eines der möglichen Navigationsmodelle. Dabei verhandelt der DUA mit einem DSA, der wiederum andere DSAs hinzuzieht, um die Anfragen aufzulösen. Es gibt zwei Typen von Klientenanfragen an DSAs:

• Die read-Anfrage, der ein absoluter oder relativer Name für einen Eintrag zusammen mit einer Liste von Attributen, die gelesen werden sollen, übergeben wird. Der DSA lokalisiert den benannten Eintrag durch Navigation im DIT und reicht Anfragen an andere DSAs weiter, falls relevante Teile des Baums nicht vorhanden sind. Der DSA ermittelt die angeforderten Attribute und gibt sie an den Klienten zurück.

• Bei der search-Anfrage handelt es sich um eine attribut-basierte Anfrage. Als Argumente werden ein Basisname und eine Filterausdruck (Prädikat) übergeben. Der Basisname bestimmt den Knoten im DIT, von dem aus die attributierte Suche aufgenommen wird. Der Filterausdruck ist ein logischer Ausdruck, der in jedem Knoten unterhalb des Basisknotens ausgewertet wird. Der Filterausdruck spezifiziert das Suchkriterium, eine logische Verknüpfung von Tests für die Werte der betroffenen Attribute in einem Eintrag. Das search-Kommando liefert eine Liste mit den Namen aller Einträge zurück, die unterhalb des Basisknotens liegen und für die der Filterausdruck erfüllt ist.

Ein zentraler Punkt in X.500 ist die Administration und die Anpassung der Directory Information Base (DIB). Das DUA-Interface beinhaltet Operationen für das Hinzufügen, Löschen und Modifizieren von Einträgen. Als positiv an X.500 ist zu werten, daß eine Zugriffskontrolle für Anfrage- und Änderungsfunktionen vorhanden ist, so daß der Zugriff auf Teile des DIT auf bestimmte Benutzer oder Benutzergruppen eingeschränkt werden kann.

Der momentane X.500-Standard enthält keine definitiven Aussagen zur Replikation von Kontexten oder zum Vorhalten (Caching) von Verzeichniseinträgen. Entsprechende Erweiterungen sind jedoch in Arbeit und sollen in den ISO-Standard integriert werden. Als Standard behandelt X.500 auch keine Implementierungsaspekte. Es ist jedoch klar, daß jede Art von Realisierung von X.500, die eine Vielzahl von Verwaltern in einem weitläufigen Netzwerk umfaßt, extensiv Replikations- und Caching-Techniken einsetzen muß, um die Anzahl der globalen Anfragen zu reduzieren. Es gibt Implementierungen [Rose, 92], in denen individuelle DIB-Einträge repliziert und vorgehalten werden. Unterhalb eines Knotens wird auf der Basis von Gruppen von Einträgen repliziert. Es wird hier davon ausgegangen, daß Werte bei Änderungen inkonsistent werden und die Zeitspanne, bis die Konsistenz wiederhergestellt ist, einige Minuten betragen kann.

X.500 befindet sich noch immer in einem Pilotstadium. Viele Organisationen haben inzwischen X.500-DSAs eingerichtet, die Datenbanken mit Informationen über Personen und Ressourcen vorhalten. Das System ist jedoch noch nicht genug verbreitet, um abschließend die Effizienz von X.500 beurteilen zu können. Es fehlt bisher auch an Vereinbarungen, um eine Vereinheitlichung der in der DIB gespeicherten Objektklassen herbeizuführen. Ferner mangelt es an geeigneten Anwendungen auf Klientenseite, die die benutzerfreundliche Verwendung des X.500-Services erlauben. Haupthindernis ist dabei die ASN.1-Notation der attributierten Namen, die nicht direkt textuell eingegeben werden kann. Bestrebungen sind im Gange, das DAP zu vereinfachen, um die Implementierung von X.500-Klienten zu erleichtern und somit die Verbreitung von X.500 zu forcieren (Lightweight Directory Access Protocol) [Yeong, 92].

Anhang B .5.2 Der Global Directory Service in OSF DCE

Auch in Distributed Computing Environment der Open Software Foundation (OSF-DCE) [OSF, 90b] werden Mechanismen zur verteilten Namensverwaltung angeboten. Basis des Global Directory Service (GDS ) in DCE ist die DIR.X V3.0-Implementierung des X.500-Standards der Firma Siemens [SNI, 93b]. Die Funktionalität des X.500-Standards wird der Anwendung über die Schnittstelle des X/Open Directory Service angeboten.

Abbildung Anhang B .27: Der DCE Directory Service als integraler Bestandteil der DCE-Architektur

In OSF-DCE kooperiert GDS mit dem Cell Directory Service (CDS) (vgl. Abbildung Anhang B .27). CDS speichert Namen und Attribute von Objekten, die sich innerhalb einer DCE-Zelle befinden. Eine DCE-Zelle besteht aus einer Gruppe verschiedener Rechner, die durch ein Netzwerk verbunden sind. Jede DCE-Zelle enthält einen CDS-Server. GDS dient dabei als allgemeinnützige Datenbank, die Informationen außerhalb einer CDS-Zelle zur Verfügung stellt. GDS verbindet die verschiedenen Zellen, wobei die Lokalisierung entfernter Zellen unterstützt wird.

GDS ist eine Ergänzung des X.500-Standards. Zusätzlich zur X.500-Basisfunktionalität bietet die Implementierung in OSF-DCE aber noch spezielle Unterstützung für verteilungsspezifische Probleme:

• Ein Verfahren zur konsistenten Replikation von Kontexten (Shadow-Information) bei verschiedenen DSAs. Durch gezielte Replikation wird der lesende Zugriff effizienter.

• Die Ergebnisse einer Anfrage werden von den beteiligten Komponenten vorgehalten, um gleichartige Anfragen später schneller bearbeiten zu können.

• Der Authentisierungsdienst Kerberos [Steiner, 88] wurde integriert, um einen Zugriffsschutz auf Verzeichnisse und die Authentisierung von Klienten aufgrund privater Schlüssel unter Verwendung des Data Encryption Standards (DES) zu ermöglichen.

• Zusätzlich zur Authentisierung des Objektzugriffs ist eine Kontrolle des Zugriffs auf die einzelnen Attribute realisiert. Den Attributen können verschiedene Zugriffsklassen zugeordnet werden. Für jedes Attribut wird eine Zugriffskontrolliste angelegt.

• Im X.500-Standard wird nur das Einfügen, Löschen und Umbenennen von Blatteinträgen im DIT definiert. GDS ermöglicht zusätzliche Teilbaumoperationen, um neue Kontexte anzulegen und das schrittweise Wachsen eines großen verteilten Systems zu unterstützen.

• Der X.500-Standard sieht nur die lokale Administration vor. Jeder DSA muß demnach vom Administrator lokal gewartet werden. GDS bietet zusätzlich die Möglichkeit zur entfernten Administration.

• Zur Interaktion zwischen verschiedenen DSAs wird der OSF Remote Procedure Call [OSF, 90a] eingesetzt, der eine von speziellen Transportprotokollen unabhängige Realisierung der Kommunikation garantiert.

Insgesamt bietet die Namensverwaltung des OSF Distributed Computing Environments eine relativ reiche Funktionalität. Die Konformität zum ISO-Standard wird die Verbreitung erheblich erleichtern. Für den praktischen Einsatz der Konzepte ist die Existenz einer realen Implementierung sicherlich die wichtigste Rahmenbedingung.

Anhang B .5.3 Profile und Univers

Das System Profile [Peterson, 88a] realisiert eine verteilte Namensverwaltung für attributierte Namen. Attribute sind wie in Clearinghouse typisiert. Eine Reihe von Attributtypen wird bereits vom System vorgegeben, so zum Beispiel Name, Adresse, Telefon, Benutzernummer oder Default-Name Server einer bestimmten Person. Attribute können in Anfragen verwendet werden und auch in den Ergebnissen enthalten sein. Eine eigene Notation unterstützt die flexible Definition von Attributwerten. Für Anfragen werden spezielle Interpretationsfunktionen vorgegeben, die exakte bzw. generische Entsprechungen der Attributwerte verlangen. Eine weitere Besonderheit des Ansatzes ist, daß kein hierarchischer Namensraum realisiert wird. Vielmehr können Namensanfragen Teilkomponenten enthalten, die durch einen Separator getrennt sind. Jeder Teil stellt einen attributierten Namen dar und wird als Komponente eines routing-orientierten Namensraums interpretiert. Die Auswahl des Name Servers, der eine bestimmte Namenskomponente interpretiert, ist also von der Interpretation des vorhergehenden Name Servers auf dem gewählten Interpretationspfad abhängig. Dieser Pfad kann zusätzlich explizit durch Angabe eines Suchpfad-Ausdrucks bestimmt werden, der eine Folge von Name Servern enthält. Diese recht systemnahe Vorgehensweise dient speziell zur Optimierung weiträumiger Anfragen bei entfernten Name Servern im Internet. Profile unterstützt keine automatische Replikation von Namenseinträgen; vielmehr muß ein Anbieter einen Namen explizit bei mehreren Servern registrieren, um ihn zu replizieren. Auch das Vorhalten von Einträgen wird anwendungsabhängig vorgenommen. Diese Eigenschaften sind jedoch nicht als generelle Schwächen des Ansatzes anzusehen. Sie resultieren vielmehr aus der Zielsetzung, eine lose Kopplung von Name Servern im Internet zu ermöglichen.

Das System Univers [Bowman, 90a] ist eine Weiterentwicklung und Verallgemeinerung des Profile-Ansatzes. Es erlaubt eine noch flexiblere Attributdefinition, wobei beispielsweise zwischen eindeutigen, obligatorischen und optionalen sowie zeitabhängigen Attributen unterschieden wird. Das System ist jedoch in sich nicht verteilt. Vielmehr wurde zum Beispiel ein einzelner Profile-Name Server unter Verwendung von Univers zur Validierung des Ansatzes realisiert.

Zusammenfassend läßt sich festhalten, daß attribut-basierte Namensverwaltungen, wie Profile, ein Alternative zu globalen hierarchischen Verzeichnisdiensten darstellen. In attribut-basierten Namensverwaltungen werden Objekte durch eine Sammlung von Attributen benannt. Bei der Benennung von Objekten können Attribute entfallen, solange genügend Informationen bereitstehen, um das Objekt eindeutig zu identifizieren. Ein Vorteil von attributierten gegenüber hierarchischen Namensräumen besteht darin, daß sie auf vielfache Weise organisiert sein können. Benutzer können Objekte identifizieren, selbst wenn Teile des Namens unbekannt sind. Die Attribute jedoch, die Anwender für die Suche verwenden, müssen zuvor registriert werden.

Der entscheidende Nachteil ist darin zu sehen, das die Konzepte der attribut-basierten Namensverwaltung in ihrer reinen Form nicht skalieren. Es bleibt schwierig, eine Datenbank mit Attributen über eine große Anzahl von Servern zu verteilen[AL5] . Ohne die Möglichkeit eine Anfrage an den zuständigen Server zu leiten, müssen Anfragen an alle Server gerichtet werden, was in globalen Netzwerken kaum durchführbar ist. Profile [Peterson, 88a] beschränkt die Menge der in die Suche einbezogenen Server und unterhält Querverweise, die die Anfrage an die zuständigen Server leiten, die nicht in der ursprünglichen Menge enthalten sind. Dieser Ansatz verlangt, daß Querverweise existieren, bevor eine Anfrage erfolgt. Somit geht der Vorteil attribut-basierter Namensverwaltungen verloren, daß Verweise für eine Anfrage nicht a priori vorhanden sein müssen.

Anhang B .5.4 Novell Directory Services (NDS)

Der Novell Directory Service [Novell, 96] ist eine Technologie, die eine einheitliche, globale logische Sicht aller Netzwerkdienste und -ressourcen einer komplexen physikalischen Infrastruktur bietet. NDS realisiert eine in Netware 4 integrierte, verteilte Datenbank, die Informationen über Netzwerkbenutzer, Gruppen, Drucker, Volumes und andere Ressourcen und Geräte in einer einzigen logischen Datenbank verwaltet. Das ermöglicht es Benutzern, Netzwerkdienste und -ressourcen mit einem einzigen Paßwort zu verwenden, unabhängig davon, wo der Benutzer oder die Ressourcen sich befinden. Benutzer melden sich über NDS beim Netzwerk mit mehreren Servern an und sehen dieses als einheitliches Informationssystem, anstelle einer Sammlung einzelner Server. NDS bietet die Möglichkeit zur zentralen Administration des Verzeichnisses mittels eines bedienungsfreundlichen graphischen Werkzeugs.

Anhang B .5.4.1 Verzeichnisdienste versus Namensverwaltungen

NDS ist ein echter Verzeichnisdienst, der weit mehr leistet, als die reine Abbildung von Namen auf Adressen. Namensdienste, wie das Domain Name System [Mockapetris, 84a], unterscheiden sich grundlegend von Verzeichnisdiensten wie NDS. Namensdienste bilden einfach Netzwerknamen auf den Netzwerkadressen ab und sind daher nur begrenzt, z.B. für E-Mail-Systeme und zur Benutzerauthentisierung, einsetzbar. Eine Hauptbeschränkung der Namensdienste ist, daß sie serverspezifisch sind, d.h. sie verlangen das Erzeugen und die Wartung einer separaten Namensdatenbank auf jedem Server. Diese zusätzliche Administration erhöht die Wartungskosten immens.

Verzeichnisdienste ermöglichen andererseits eine zentrale Administration für das gesamte Netz. Wie Namensdienste bilden Verzeichnisdienste auch Netzwerknamen auf Netzwerkadressen ab. Zusätzlich weisen Verzeichnisdienste bei der Namensvergabe allen Netzwerkressourcen eine freie und im gesamten Netzwerk eindeutige Identität zu.

Somit ermöglichen Verzeichnisdienste den globalen Zugriff auf Netzwerkressourcen, unabhängig von ihrem Aufenthaltsort. Dieses erlaubt Benutzern und Verwaltern den transparenten ortsunabhängigen Zugriff auf Drucker, Server und andere Ressourcen, sowie auf andere Benutzer. Zusätzlich vereinfacht es die Verwendung und das Management des Netzwerks, indem es die Netzwerkressourcen für Benutzer, unabhängig von ihrem Aufenthaltsort oder dem Speicherort der Netzwerkressource, zugänglich macht.

Namensdienste wie Netware 3 Bindery und Windows NT Server Domain Name Service halten nur die notwendige Minimalinformation über das Netzwerk, einschließlich der grundlegenden Objekte wie Benutzer, Gruppen, Drucker und Dateiservers. Diese Objekte enthalten eine begrenzte Anzahl von Attributen mit sehr allgemeinen Informationen. NDS hingegen unterstützt viele unterschiedliche Arten von Objekten mit umfangreichen Attributinformationen. Die NDS-Datenbank ist erweiterbar und ermöglicht das Registrieren kundenspezifischer Objekte und Eigenschaften. Diese Erweiterbarkeit ermöglicht den Zugriff auf jede intelligente Einheit im Netz.

NDS bietet umfangreiche Abfrage- und Suchmöglichkeiten für die Verzeichnisdatenbank und erlaubt Benutzern, nach Netzressourcen mit Attributen als Suchkriterien zu suchen. Beispielsweise kann ein Benutzer nach allen Farb-PostScript-Druckern suchen. Das macht den Zugriff und die Verwaltung von Netzwerkressourcen sehr viel einfacher als mit Namensverwaltungen.

Ein anderer Hauptunterschied zwischen Verzeichnisdiensten und Namensverwaltungen ist, daß Verzeichnisdienste auf einer hierarchischen Struktur basieren, während Namensverwaltungen vielfach flach organisiert sind. Eine hierarchische Struktur erlaubt es, ein Netzwerk entsprechend den organisatorischen Ebenen logisch zu strukturieren, wobei jede Abteilung ihren eigenen Verwalter hat. Bei einer hierarchischen Struktur muß der Abteilungsverwalter sich nur um einen bestimmten Zweig des Verzeichnisbaums kümmern. Dabei ist leicht zu erkennen, für welche Netzwerkressourcen der Administrator verantwortlich ist. In einem flachen Verzeichnis gibt es keine Möglichkeit die Verwaltung zu dezentralisieren, außer der Pflege separater Verzeichnisse für jede administrative Gruppe. Obwohl dies eine gangbare Lösung darstellt, ist es damit nur sehr schwer möglich, Anwendern einen transparenten Zugriff über Bereichsgrenzen hinaus zur Verfügung zu stellen.

Schließlich existiert für Verzeichnisdienste der internationale Standard X.500 [CCITT/ISO, 88]. Dieser macht sie in heterogenen Umgebungen nutzbar, wie sie gewöhnlich in heutigen Netzwerken vorgefunden werden. Für Namensverwaltungen gibt es keinen derartigen Standard, weshalb es praktisch unmöglich ist, sie in heterogenen Netzwerken einzusetzen.

Anhang B .5.4.2 Der hierarchische Verzeichnisbaum von NDS

Ähnlich einem Telefonbuch oder einem Adreßbuch, hilft NDS dem Anwender, Informationen schnell und effizient aufzufinden. NDS leistet jedoch mehr, als nur Ressourcen im Netzwerk aufzulisten. Es organisiert Ressourcen, hier als Objekte bezeichnet, in einer hierarchischen Baumstruktur, die als Verzeichnisbaum (directory tree) bezeichnet wird (vgl. Abbildung Anhang B .28).

Abbildung Anhang B .28: Die Auswahl eines Novell Netware Directory-Baums

Mit NDS kann eine Organisation Objekte im Verzeichnisbaum so anordnen, wie Benutzer die Ressourcen zugreifen und verwenden. Das macht es nicht nur einfach, auf Ressourcen zuzugreifen, sondern ermöglicht auch eine regelbasierte Administration. Diese erlaubt Administratoren den Zugriff auf ganze Zweige des Verzeichnisbaums. Das macht es einfach, die Sicherheit für eine ganze Organisation zu gewährleisten, wobei die Notwendigkeit, einzelne Gruppen separat zu administrieren, minimiert wird.

Der hierarchische Verzeichnisbaum ist das Hauptunterscheidungsmerkmal zwischen NDS und seinen Mitbewerbern. Obwohl andere, wie Microsoft mit Windows NT Server, für sich in Anspruch nehmen, einen Verzeichnisdienst zu besitzen, sind deren Systeme lediglich flache Namensverwaltungen. Diese besitzen keine Hierarchie, weshalb sie schwierig zu durchsuchen und zu verwalten sind. Namensverwaltungen sind tendentiell auch nur beschränkt einsetzbar, primär für E-Mail-Systeme und zur Benutzerauthentisierung, und sie sind serverspezifisch. NDS hingegen wurde entworfen, um die gesamte Netzwerkinfrastruktur zu verwalten.

Die hierarchische Verzeichnisstruktur von NDS reduziert den Netzwerkverkehr und ermöglicht eine schnelle und effiziente Bearbeitung von Anfragen und Operationen. Benutzer können die gewünschte Netzwerkressource finden, indem sie diese explizit suchen oder im Verzeichnisbaum mit einem Browser (vgl. Abbildung Anhang B .30) blättern.

Anhang B .5.4.3 Kompatibilität von NDS mit X.500

NDS ist ein vollwertiger Verzeichnisdienst, der auf dem internationalen Standard X.500 [CCITT/ISO, 88] basiert. Die International Standards Organization (ISO) und Consultative Committee for International Telegraphy and Telephony (CCITT) definierten X.500, um einen Standard für den Aufbau eines wirklich interoperablen, verteilten, globalen Verzeichnisdienstes zur Verfügung zu stellen.

Alle Eigenschaften und Funktionen, die im Standard X.500 beschrieben sind, wurden in NDS implementiert. Zusätzlich werden alle NDS-Operationen und -Protokolle direkt von der X.500-Spezifikation abgeleitet. NDS bietet jedoch über die X.500-Spezifikation hinaus bedeutende zusätzliche Funktionalität, die eine komplette Vernetzungsinfrastruktur realisiert und Benutzern den Zugang zu Netzwerkdiensten, Anwendungen und Daten ermöglicht.

Obgleich NDS sehr stark an X.500 angelehnt ist, gibt es einige Unterschiede. Diese Unterschiede liegen in den Protokollen von NDS, nicht in der Architektur. Novell beschloß, leichtgewichtigere Netware Protokolle über dem Schwergewicht X.500 der Open System Interconnection (OSI) einzuführen. Da lediglich Unterschiede in den Protokollen bestehen, ist es einfach, die volle Interoperabilität von NDS und X.500 zu gewährleisten.

Anhang B .5.4.4 Sicherheit in NDS

NDS ermöglicht es, die Zugriffsrechte für einen Zweig des NDS-Baumes zu definieren, wobei alle Objekte innerhalb und unterhalb eines speziellen Teilbaums diese Rechte erben. Diese regelbasierte Administration vereinfacht die Verwaltung von Sicherheitsfunktionen, so daß nur die Ausnahmen zu den Regeln besondere Aufmerksamkeit verlangen. Dieses Vorgehen steigert nicht nur die Sicherheit, sondern reduziert auch die Verwaltungskosten erheblich. Um Benutzern den Zugang zu Netzwerkdiensten zu gewähren, verwendet NDS einen Authentisierungsdienst, der auf der RSA public-key/private-key-Verschlüsselungstechnologie basiert. Dieser Authentisierungsmechanismus verwendet einen privaten Schlüssel und eine digitale Signatur, um die Identität des Benutzers zu prüfen.

Anstatt bei mehreren verschiedenen Servern, melden sich Benutzer und Administratoren in NDS einmal mit ihrem Paßwort beim Netzwerk an und erhalten somit nahtlosen Zugang zu allen Netzwerkressourcen, für die sie berechtigt sind. Die Authentisierung ist sitzungsorientiert und die Signatur des Benutzers ist für die Dauer der aktuellen Sitzung gültig. Nach dem einmaligen Anmelden wird der Zugang zu Ressourcen automatisch im Hintergrund gewährt. Die Authentisierung erfolgt für Netzwerkbenutzer transparent und findet jedesmal dann statt, wenn Benutzer Dienste in Anspruch nehmen. Der Benutzer wird während der Sitzung niemals mehr um sein Paßwort gebeten und merkt nicht, daß bei jedem Zugriff eine Authentisierung erfolgt. Lediglich zum Zeitpunkt der Anmeldung ist sich der Benutzer der Authentisierung bewußt.

Mit NDS können sich Benutzer überall anmelden, unabhängig davon wo sie sich gerade im Netzwerk befinden. Dabei bietet sich ihnen überall dieselbe konsistente Sicht des Netzwerks, egal an welchem Arbeitsplatz sie sich anmelden.

Anhang B .5.4.5 Einfache und flexible Administration von NDS

Eine kürzlich veröffentlichte Studie der Gartner Group zeigte, daß 73% der Unterhaltskosten für ein Netzwerk allein die notwendige Administration ausmacht. NDS bietet eine ausgeklügelte und einfache Administration, die die Verwaltungskosten eines Netzwerks reduziert und die zentrale Verwaltung des Netzwerks mittels eines graphischen Werkzeugs ermöglicht.

Ohne einen Verzeichnisdienst sind Administratoren häufig gezwungen, dieselbe Operation mehrmals durchzuführen, entweder für jeden Benutzer oder für jeden Server. NDS vermeidet überflüssigen Verwaltungsaufwand, indem es die zentrale Administration einer ganzen Organisation erlaubt. Jede Netzwerkressource besitzt eine global eindeutige Identifikation, wodurch sie nur einmal für das gesamte Netzwerk erzeugt werden muß. Beispielsweise ist nur eine einzige Benutzeridentifikation notwendig, auch wenn der Benutzer auf mehrere Server im Netzwerk Zugriff besitzt.

NDS bietet ebenfalls eine große Freiheit in der Netzwerkverwaltung. In vielen Organisationen ist es wünschenswert, Verwaltungs- und Administrationsdienste abteilungsübergreifend zu zentralisieren. Andererseits kann die Administration an Abteilungen oder Arbeitsgruppen delegiert werden. NDS unterstützt beides, zentralisierte und verteilte Administration, so daß Organisationen die für sie passende Methode wählen können.

Da Organisationen sich fortwährend im Umbruch befinden, wurde NDS flexibel entworfen, so daß es möglich ist, den Verzeichnisbaum einer Firma anzupassen, sobald sich die Organisationsstruktur ändert. Einzelne Objekte, ganze Gruppen von Objekten oder gesamte Zweige des Verzeichnisbaums können auf unterschiedliche Positionen im Baum mit drag and drop verschoben werden. Das Bewegen von Objekten mit Namensdiensten wie Netware 3 bindery oder Windows NT Server Domain Name Service verlangt vom Administrator, das Objekt vollständig zu löschen und in der neuen Position neu zu erstellen.

NDS erlaubt auch das Vereinigen zweier verschiedener Verzeichnisbäume zu einen. Dies macht es möglich, zwei unterschiedliche Netware 4 Netzwerke auf einfache Weise zu einem unternehmensweiten Netz zu verbinden. Zusätzlich gibt das Vereinigen der Verzeichnisse Organisationen die Möglichkeit, zunächst unterschiedliche NDS-Bäume für Abteilungen oder geographische Standorte einzuführen und diese dann zu einem späteren Zeitpunkt zu kombinieren.

Anhang B .5.4.6 Verteilung und Replikation in NDS

NDS ist eine verteilte Datenbank, die zur Steigerung der Ausfallsicherheit vollständig repliziert ist. Fehlertoleranz wird erreicht, indem die NDS-Datenbank partitioniert wird und die Partitionen im Netzwerk verteilt werden. NDS-Daten können nahe beim Benutzer plaziert werden, der sie verwendet, wodurch eine kurze Zugriffszeit auf Netzwerkressourcen gewährleistet wird.

NDS-Partitionen werden so oft wie notwendig über das gesamte Netzwerk repliziert. Wenn eine Primärpartition ausgefallen ist, stellt sich NDS sofort um und verwendet eine Sicherungskopie. Das steigert die Zuverlässigkeit des Netzes und erlaubt den Aufbau eines Systems, in dem der Ausfall oder die Wartung eines Servers oder der temporäre Verlust einer Kommunikationsverbindung den Betrieb kaum beeinflußt.

Anhang B .5.4.7 Erweiterbarkeit und Skalierbarkeit von NDS

Die Struktur eines NDS-Verzeichnisbaums wird durch das Verzeichnisschema bestimmt. Das Schema ist ein Regelwerk, das festlegt, wie der NDS-Verzeichnisbaums strukturiert wird. Das Schema legt fest, welche Objekte definiert werden, welche Attribute mit Objekten verbunden sind, welche Eigenschaften Objekte erben, und welche Positionen Objekte im Verzeichnisbaum besetzen.

Das NDS-Grundschema ist erweiterbar, wodurch es Kunden möglich wird, dieses zu ändern und benutzerspezifisch an die jeweiligen Bedürfnisse anzupassen. Beispielsweise kann ein Benutzerobjekt erweitert werden, um eine Versicherungsnummer oder den Namen und die Telefonnummer einer Kontaktperson im Notfall aufzunehmen. Kunden können neue Dienste in das Netzwerk integrieren, indem sie das NDS-Schema erweitern und neue Objekte hinzufügen. Z.B. kann ein Kunde eine Telefaxserverfunktionalität im Netzwerk offerieren, indem er dem NDS-Baum ein Telefaxserverobjekt hinzufügt.

NDS kann an jede Art und Größe von Netzwerk benutzerspezifisch angepaßt werden. Selbst wenn Organisationen mit anderen Firmen fusionieren und zunehmend wachsen, paßt sich das NDS-Design leicht diesem Wachstum an. Neue Ressourcen können im Verzeichnisbaum mit einem einfachen Mausklick hinzugefügt werden.

Anhang B .5.4.8 Integration von Geräten, Diensten und Anwendungen in NDS

NDS integriert eine große Vielfalt von Geräten und bietet eine einfache Darstellung einer komplizierten physischen Infrastruktur (vgl. Abbildung Anhang B .30). Durch die Novell Embedded Systems Technology (NEST) umfaßt diese Integration praktisch jedes denkbare Gerät mit einem Mikroprozessor, wie z.B. Kopierer, Telefaxmaschinen, Klimaanlagen, Sicherheitssysteme und Haushaltsgeräte. NDS bildet auch die Grundlage, um Netzwerkdienste und Anwendungen unabhängig von der verwendeten Plattform in ein System zu integrieren.

Abbildung Anhang B .30: Der Novell Netware Directory Browser zeigt vorhandene Geräte, Dienste und Applikationen

NDS integriert verteilte Dienstleistungen und Anwendungen in ein einheitliches Informationssystem. Novell liefert eine Vielzahl verteilter Netware-Dienste, die auf NDS beruhen, einschließlich des File-Services, des Druckdienstes, des Sicherheitsdienstes und vieler weiterer.

NDS bietet ein API an, das Softwareentwicklern die Möglichkeit gibt, ihre Anwendungen und Dienste in NDS zu integrieren. Anwendungen und Dienste können die Informationen der NDS-Datenbank verwenden, um Benutzer mit Netzwerkdiensten und Ressourcen zu verbinden. Beispielsweise kann ein E-Mail-Server oder ein Telefax-Server die NDS-Datenbank nutzen, anstatt eine eigene Benutzerdatenbank zu verwalten. Administratoren haben dann nur eine einzige, zentrale anstelle von mehreren Datenbanken zu pflegen. Dieses verringert einerseits die Zeit und die Kosten für die Wartung von Firmendatenbanken erheblich, andererseits müssen sich Benutzer nur einmal bei NDS anmelden und werden transparent für jeden Dienst autorisiert, der die NDS-Datenbank nutzt.

Zusätzlich zu den Informationen, die bereits in NDS gespeichert sind, können Anwendungen oder Dienste kundenspezifische Informationen in der Datenbank ablegen. Z.B. können ein Datenbankserver, ein Print-Server von einem Drittanbieter oder andere Diensteanbieter ein Objekt in NDS erstellen, das diesen bestimmten Dienst repräsentiert. Indem sie sich bei NDS registrieren, müssen Anwendungen und Dienste ihre Dienstleistungen nicht länger über das Service Advertising Protocol (SAFT) bekanntmachen. Dadurch verringert sich der Netzverkehr erheblich.

Anhang B .5.5 Microsoft Active Directory Service Interfaces (ADSI)

Die Microsoft^® Active Directory Service Interfaces (ADSI) [Microsoft, 97a] definieren klientenseitig eine Programmierschnittstelle für einen Verzeichnisdienst, die auf dem Component Object Model (COM) [Rogerson, 97] basiert. Die ADSI sind Teil der Windows^® Open System Architecture (WOSA) Open Directory Service Interfaces (ODSI) und ermöglichen Anwendungsprogrammen nicht nur den Zugang zum Windows NT Directory Service und zu Netware 3.x-Namensräumen, sondern auch zu LDAP- und NDS(Novell Directory Service)-kompatiblen X.500-Verzeichnisdiensten. Beispiele für Syntaxkonventionen von Namen, die von Provider Components des Active Directory Service unterstützt werden, zeigt Tabelle Anhang B .5.

Syntaxkonvention	Beispiel
Windows NT	“//MyWorkstation/MyName”
LDAP	“//MyServer/C=US/O=MS/CN=MyName”
NDS	“//Planets/O=Mars/OU=DEV”
NetWare 3.x	“//Docs/MyNw3xPrinter”

Tabelle Anhang B .5: Beispiele für vom Active Directory Service unterstützte Namenskonventionen

Anwendungsprogramme können die Active Directory Service Interfaces API verwenden, um auf Verzeichnisdienste zuzugreifen, die ADSI unterstützen. Da ADSI eine Component Object Model (COM)-Schnittstelle anbietet, die jedem Verzeichniselement eine allgemeine Menge von Eigenschaften zuordnet, kann der Klient eine einheitliche Benutzeroberfläche verwenden, um auf Verzeichniselemente verschiedener Verzeichnisdienste zuzugreifen. Da hierzu die ADSI-Schnittstellen und ihre Methoden verwendet werden, sind die Anwendungsprogramme von jeglichen direkten, betriebssystemabhängigen Aufrufen eines Verzeichnisdienstes entbunden. Die gesamte Kommunikation mit dem Namensraum geschieht durch ADSI. Abbildung Anhang B .32 zeigt einen Browser in einem Anwendungsprogramm, der die angebotenen Dienstkomponenten nutzt, um mit verschiedenen Verzeichnissystemen zu kommunizieren.

Abbildung Anhang B .32: Übersicht über die Active Directory Service Interfaces

Jede ADSI Provider Component implementiert die Active Directory Service Interfaces, ihre Methoden und ihre Eigenschaften. Ein Provider kann zusätzliche Schnittstellen, Methoden und Eigenschaften unterstützen, damit ADSI-Klientenanwendungen alle Fähigkeiten eines bestimmten Verzeichnisdienstes nutzen können.

ADSI bietet Schnittstellen für allgemeine Verzeichnisdienstelemente, wie Benutzer, Rechner, Dienstleistungen und verschiedene organisatorische Bezeichnungen an. Diese Active Directory Service Interface-Definitionen werden aus Gründen der Bequemlichkeit und der Benutzerfreundlichkeit definiert und sind so erweiterbar, daß sie die Besonderheiten eines jeden Namensraums berücksichtigen können.

Die Active Directory Service Interfaces bieten auch Schnittstellen, um eine Online-Referenz über einen Verzeichnisdienst definieren zu können. Durch die ADSI-Schemamanagementschnittstellen können die Autoren von Provider Components zusätzliche Eigenschaften und neue Schnittstellen anbieten. Die Klientenanwendungen benutzen die Schemamanagementschnittstellen, um Informationen über den Verzeichnisdienst abzufragen.

Eine ADSI-Klientenanwendung kommuniziert mit einem Verzeichnisdienst, der eine ADSI Provider Component besitzt, über die ADSI Router and Support Component (vgl. Abbildung Anhang B .32). Die Kommunikation kann so direkt verlaufen, wie wenn ein Verzeichnisname an einen ADSI-API-Funktionsaufruf, wie ADsGetObject, übergeben wird und ein Zeiger zu einem Active Directory Service Interface auf das COM-Objekt empfangen wird, das dieses Verzeichniselement repräsentiert.

Abbildung Anhang B .34: Interaktion der ADSI-Komponenten

Die ADSI Router and Support Component verwendet die Registry, um festzustellen, welche Provider Component die Klientenanwendung benötigt, um ihre Aufgabe zu erfüllen, und leitet die Bindungsinformationen an die passende ADSI Provider Component weiter. Sobald der Bindevorgang abgeschlossen ist, kommuniziert die Klientenanwendung direkt mit der Provider Component durch die angeforderte Schnittstelle.

Abbildung Anhang B .35: Ansicht des ADSI Example Provider Directory

Ein Beispiel für eine ADSI-Klientenanwendung ist der Visual Basic Active Directory Object Browser, der im ADSI-SDK enthalten ist. Abbildung Anhang B .35 zeigt diesen Browser mit den ADSI Providern, die in Abbildung Anhang B .32 dargestellt sind. Der Beispiel-Provider stellt sein eigenes fiktives Verzeichnis zur Verfügung, das in Abbildung Anhang B .35 expandiert ist.

Alle Elemente eines Verzeichnisdienstes werden durch Active Directory Objekte (ADs objects) dargestellt. Diese sind COM-Objekte, die eine oder mehrere Active Directory Diensteschnittstellen unterstützen. In Abbildung Anhang B .35 ist jedes Verzeichniselement in der Baumansicht des Browsers von "ADs:" durch ein Active Directory Objekt dargestellt. Objekte, die keine anderen Objekte enthalten, sind einfache Active Directory Objekte (zum Beispiel, die Benutzer "AnneA" bis "ElizabethE"). Objekte, die andere Objekte enthalten (zum Beispiel "Seattle" und "Redmond") sind Active Directory Container Objekte.

Eine Klientenanwendung kann direkt auf ein spezifisches Verzeichniselement verweisen (zum Beispiel "WinNT:\\MyDomain\JohnSmith"), oder sie kann, wie der Browser, auf alle Namensräume der ADSI-Provider zugreifen (zum Beispiel, alle Knoten unter "ADs:"). Ähnlich kann ein Verzeichniselement, wie ein spezieller Rechner oder der Benutzer-Account, nach dem Namen angezeigt werden (zum Beispiel "Sample:\\Seattle\Redmond") oder es kann gefunden werden, wenn der Inhalt eines Verzeichnisknotens aufgelistet wird (zum Beispiel alle Knoten unter "LDAP:").

Anhang B .5.5.1 Active Directory-Objekte

Im der ADSI-Umgebung wird jedes Element eines Verzeichnisdienstes durch ein Active Directory-Objekt repräsentiert, das ein Component Object Model (COM)-Objekt ist und die Standard-COM IUnknown-Schnittstelle sowie IDispatch und IADs unterstützt. IADs übernimmt die grundlegenden Verwaltungsfunktionen für Active Directory-Objekte.

Abbildung Anhang B .36: Das Active Directory Objekt und das Active Directory Container Objekt

Ein Active Directory-Objekt manipuliert Daten vom Datenspeicher des zugrundeliegenden Verzeichnisdienstes durch die Active Directory Service Interfaces, die es unterstützt. Diese Daten werden als die Eigenschaften des Objekts bezeichnet und die Funktionen, die diese Eigenschaften abfragen und setzen, werden als Eigenschaftsmethoden bezeichnet. Nurlese-Eigenschaften haben eine Eigenschaftsmethode, die den Wert der Eigenschaft setzt. Lese-Schreib-Eigenschaften haben zwei Methoden, eine, die den Wert liest, und eine, die den Wert setzt.

Zusätzlich interagiert ein Active Directory-Objekt mit anderen Active Directory-Objekten und direkt mit dem Namensraum über Methoden. Die Eigenschaften, die Eigenschaftsmethoden und diese Methoden werden alle durch Standard-COM-Schnittstellen erreicht. Ein Active Directory-Objekt wird durch seinen ADs-Pfad eindeutig gekennzeichnet. Ein Beispiel für einen ADs-Pfad im LDAP-Namensraum ist “LDAP://MyServer/OU=Seattle”.

Die Implementierung der IADs-Schnittstelle unterstützt einen Eigenschafts-Cache. Änderungen, die durch eine Klientenanwendung am Wert einer Eigenschaft durch eine Eigenschaftsmethode vorgenommen werden, werden nur innerhalb des lokalen Speichers geändert, der als Cache bezeichnet wird. Die Methode IADs::SetInfo bewirkt, daß die Werte im Eigenschafts-Cache beim zugrundeliegenden Verzeichnisdienst gespeichert werden. IADs::GetInfo erneuert den Inhalt des Eigenschafts-Caches mit Hilfe des zugrundeliegenden Verzeichnisdienstes und überschreibt den aktuellen Inhalt des Caches.

Abbildung Anhang B .37: Der Active Directory Object Property Cache

Abbildung Anhang B .37 zeigt, daß der Aufruf der IADs::Get- oder der IADs::GetEx-Methode nur Werte vom Eigenschafts-Cache liest. Ähnlich schreiben die Methoden IADs::Put und IADs::PutEx in den Eigenschafts-Cache. Eine Anwendung muß die Methode IADs::SetInfo rufen, um die vorgehaltenen Werte im persistenten Speicher zu sichern. Um Werte vom zugrundeliegenden Datenspeicher in den Eigenschafts-Cache zu lesen, muß eine Anwendung entweder die Methode IADs::GetInfo oder IADs::GetInfoEx rufen.

Jedes Active Directory-Objekt, das andere Active Directory-Objekte enthält (ein Active Directory Container-Objekt), unterstützt auch die IADsContainer-Schnittstelle. Diese bietet Methoden und Eigenschaften, die das Erzeugen, das Löschen und das Auflisten von Active Directory-Objekten übernehmen, die in diesem Objekt enthalten sind. Ein Active Directory Container-Objekt wird in Abbildung Anhang B .37 gezeigt. Fast alle Active Directory-Objekte sind wiederum in anderen Objekten enthalten. Das einzige Active Directory-Objekt ohne übergeordnetes Container-Objekt ist das top-level Active Directory-Objekt des Namensraums ("ADS:"), das die ADSI Routing and Support Component zur Verfügung stellt.

Die Methode IADs::SetInfo angewandt auf ein Container-Objekt sichert die vorgehaltenen Eigenschaften des Active Directory Container-Objekt s im persistenten Speicher zusammen mit allen enthaltenen Objekten, die mit der Methode IADsContainer::Create erstellt worden sind. IADsContainer::Delete beeinflußt den Eigenschafts-Cache nicht, löscht jedoch sofort das zugrundeliegende Namensverzeichniselement, das durch dieses Objekt repräsentiert wird.

Anhang B .5.5.2 Die ADSI-Schemamanagementschnittstellen

Die Active Directory Service Interfaces enthalten eine Reihe von Schemamanagementschnittstellen, die es dem ADSI Provider erlauben, Schemadefinitionen zu erstellen und zu verwalten, um seinen eigenen Verzeichnisdienst zu repräsentieren.

Ein Schema ist ein Menge von Definitionen, die eine Menge von Elementen und die Beziehungen dieser Elemente untereinander beschreiben. Das Schema umfaßt auch Richtlinien, die definieren, wie die Elemente miteinander interagieren können. Schemata werden vor allem in Datenbanken verwendet, um zu garantieren, daß jedes neue Element, das der Datenbank hinzugefügt wird, wohlgeformt ist. Dieses erleichtert die Verwaltung der Tabellen mit Daten, da es die notwendige Fehlerbehandlung vereinfacht.

In der speziellen Implementierung von Schemamanagementobjekten, die hier beschrieben werden, enthält das Active Directory Schema Container-Objekt folgende Komponenten:

· Active Directory Schema-Klassenobjekte, die die IADsClass-Schnittstelle unterstützen.

· Active Directory Property-Objekte, die die IADsProperty-Schnittstelle unterstützen.

· Active Directory Syntax-Objekte, die die IADsSyntax-Schnittstelle unterstützen.

Die IADsClass-Schnittstelle unterstützt verschiedene Eigenschaftsmethoden, die die Schemaklasseneigenschaften ausgeben, die mit einer bestimmten Schemaklasse verbunden sind. Die IADsProperty-Schnittstelle unterstützt eine Eigenschaftsmethode, die das Objekt benennt, das die IADsSyntax-Schnittstelle unterstützt, die benötigt wird, um seine Daten zu interpretieren.

Anhand dieser einfachen Verbindungen kann eine ADSI-Klientenanwendung die Eigenschaften eines jeden Objekts zugreifen und feststellen, wie die Daten der Objekte zu interpretieren sind, ohne irgendein vorheriges Wissen über seine Eigenschaften haben zu müssen.

Abbildung Anhang B .38: ADSI Schema Class-Objekt, ADSI Property-Objekt und ADSI Syntax-Objekt

Active Directory-Objekte, die die IADs-Schnittstelle unterstützen, tragen den ADsPath ihres definierenden Schemas in der Schemaeigenschaft. Im der Example Provider Component enthält die IADs::Schema-Eigenschaft für das Active Directory-Objekt "Sample:\\Seattle\Redmond" das Schema "Sample:\\Seattle\Schema\OrganizationalUnit". Die Active Directory Objekt-Repräsentationen für die Eigenschaft, Syntax und die Schemaklassenobjekte werden in Abbildung Anhang B .38 dargestellt.

Klientenanwendungen können die Active Directory-Schemaschnittstellen nutzen, um eine Laufzeitdefinition zu erstellen, die angibt, was ein Active Directory-Objekt darstellt und wie es mit anderen Active Directory-Objekten interagiert. Klienten können das Schema eines ADSI-Providers durchblättern, um festzustellen, welche Eigenschaften und Schemakategorien existieren. Die Provider Components können zur Laufzeit aktualisiert werden, ohne die Klientenanwendung ändern zu müssen. Wegen dieser Entkopplung von Übersetzungszeitabhängigkeiten zwischen ADSI-Klientenanwendungen und den ADSI Provider Components, können Änderungen an den Active Directory-Objekt-Definitionen vorgenommen werden, ohne Binärdateien zu modifizieren.

Anhang B .5.5.3 Darstellung von Directory Service-Elementen mit Active Directory Objekten

Typische Verzeichnisdienstelemente, die benötigt werden, um einen Verzeichnisdienst darzustellen, sind:

· Verzeichnisbäume (Blattknoten und Behälterknoten).

· Benutzer-Accounts und -gruppen.

· Einstiegspunkte, um Verzeichnisbäume auf Rechnern zuzugreifen.

· Organisatorische Gruppierungen von Servern, Rechnern und Benutzern zu Administrationszwecken.

· Elemente, eindeutig zu einem spezifischen Namensraum.

· Dienste, einschließlich des Druck- und Datei-Service.

Ein Beispiel, wie man Active Directory-Objekte benutzt, um Verzeichnisdienstelemente darzustellen, kann der ADSI Example Provider Component entnommen werden. Die ADSI Example Provider Component gibt ein Schema an und bildet eine einfache Verzeichnishierarchie, die einen Benutzer-Account umfaßt. Eine Verzeichniswurzel namens "Seattle" enthält einen Eintrag "Redmond", der das Benutzerkonto "AnneA" enthält. Der ADs-Pfad für dieses Verzeichniselement im URL-Format ist: Sample://Seattle/Redmond/AnneA". "Seattle" und "Redmond" sind mittels einer ADSI-Schemaklasse, genannt "Organizational Unit", und "AnneA" ist mittels einer ADSI-Klasse "User" modelliert. Abbildung Anhang B .39 zeigt drei vereinfachte Darstellungen dieses Benutzer-Accounts.

Abbildung Anhang B .39: Konzeptuelle ADSI-Representationen: Browser, Containment, Schema

In Abbildung Anhang B .39 ist die Browser-Darstellung auf der linken Seite zu finden. Hier wurde das Verzeichnis einer Example Provider Component einer ADSI-Klientenanwendung expandiert. In der Spalte daneben wurde die Repräsentation der Verschachtelung der ADSI-Objekte dargestellt. Sie repräsentiert die hierarchische Ansicht, in der eine Anwendung, die einen Verzeichnisbaum zeigt, jedes Active Directory-Objekt und Container-Objekt darstellt. Jedes Active Directory-Objekt enthält eine Referenz auf das ADs Schema Class-Objekt, das die Eigenschaften und die Syntax für diese Art von Objekt in IADs::Schema definiert. Die ADSI-Schemadefinition ist in der rechten Spalte von Abbildung Anhang B .39 dargestellt. Sie zeigt, wie die Schemainformationen als Schemaklasse, Eigenschaft und Syntaxobjekte dargestellt werden.

Anhang B .5.5.4 Die ADSI-Softwareschichten

Eine ADSI-Klientenanwendung, die ADSI verwendet, kann als die oberste Schicht mehrerer Softwareschichten dargestellt werden (vgl. Abbildung Anhang B .41). Die Klientenanwendung ruft nur die ADSI-Schnittstellenmethoden, die Eigenschaftsmethoden und Funktionen. ADSI umfaßt alle kundenspezifischen Schnittstellen oder Eigenschaftsmethoden, die durch eine Provider Component angeboten werden. Sobald die Bindeoperation vollzogen ist, kommuniziert die Klientenanwendung direkt mit den Provider Components. Die Klientenanwendung hat keine Notwendigkeit, betriebssystemspezifische Aufrufe zu verwenden, da die Provider Component diese Aufgabe übernimmt.

Abbildung Anhang B .41: Die ADSI-Softwareschichten

Die zweite Schicht in Abbildung Anhang B .41 ist die ADSI Routing Support Component. Dieser Teil des ADSI-SDK enthält den Code zur Initialisierung von ADSI, den ADSI API Support, den Query Support, Software, die die Kontrolle an den passenden Provider übergibt, und Fehlerbehandlungsmechanismen, einschließlich der erweiterten Fehlerbehandlung, damit die Provider ihre eigenen Fehlermeldungen einbinden können. Die dritte Schicht in Abbildung Anhang B .41 ist die Provider DLL, die Aufrufe durch ihre Implementierung der Active Directory Service Interfaces und der Active Directory-Objekte erhält. Diese Schicht übernimmt alle notwendigen betriebssystemspezifischen Verzeichnisdienstaufrufe.

Anhang B .5.6 Abschließender Vergleich globaler Verzeichnisdienste

Der bedeutendste globale Verzeichnisdienst ist zweifelsohne X.500. GDS und NDS sind lediglich erweiterte Implementierungen von X.500. ADSI hingegen ist eine Schnittstelle für einen generischen Verzeichnisdienst, der verschiedene Namensverwaltungen (z.B. DNS, WINS oder Netware Bindary) und Verzeichnisdienste (z.B. NDS, X.500) integriert.

Alle vorgestellten Verzeichnisdienste, außer Univers und Profile, basieren auf hierarchischen Namensräumen mit einer variablen Anzahl von Hierarchiestufen. Die Verwalter der X.500-Derivate werden organisatorisch gruppiert und bilden ein hierarchisches Verwalternetz. Verwaltet werden i.d.R. Informationen über Rechner, Benutzer und Dateien. NDS und ADSI bieten die Möglichkeit, Verzeichniseinträge für beliebige Objekte zu definieren und zu verwalten. Alle hier vorgestellten Verzeichnisdienste unterstützen Synonyme und Gruppennamen. Attribut-basierte Namensanfragen sind ein wesentliches Merkmal von Verzeichnisdiensten und in allen Systemen realisiert. Um die Anzahl der Netzwerknachrichten einzudämmen und die Belastung der Verwalter zu reduzieren, sind generische Anfragen in den vorgestellten Systemen erst ab einer bestimmten Hierarchiestufe des Verzeichnisbaums erlaubt.

Die Auflösung eines Namens erfolgt für den Anwender transparent mit automatischer Identifikation des geeigneten Verwalters. Hierzu werden iterative oder rekursive Verfahren über Punkt-zu-Punkt-Verbindungen eingesetzt. Transitive Verfahren finden in Profile und Prospero Verwendung. In Profile kann ein Klient durch Angabe eines Suchpfades explizit Einfluß auf diesen Vorgang nehmen. X.500 hingegen unterstützt Namen relativ zum Kontext des Klienten.

Alle vorgestellten Verzeichnisdienste replizieren ihre Verzeichniseinträge, um die Fehlertoleranz zu erhöhen. Die Konsistenz der replizierten Verzeichnisse wird dabei durch zeitstempel-basierte Verfahren sichergestellt. Die Zugriffsgeschwindigkeit wird jeweils durch klientenseitiges Vorhalten von Verzeichniseinträgen erhöht.

	X.500	GDS	NDS	ADSI	Profile	Prospero
Art der benannten Objekte	Rechner, Benutzer	Rechner, Benutzer	beliebig	beliebig	Rechner, Benutzer	Dateien
Art des Namensraums	beliebig, hierarchisch	beliebig, hierarchisch	beliebig, hierarchisch	beliebig, hierarchisch	routing	beliebig, hierarchisch
Synonyme	Alias	Alias	Ja	Ja	Ja	Ja
Art der Namensauflösung	iterativ, rekursiv	iterativ, rekursiv	iterativ, rekursiv	iterativ, rekursiv	transitiv	transitiv
Kommunikation	Point to Point	Point to Point	Point to Point	Point to Point, Broadcast	Point to Point	Point to Point
Verteilung der Nameserver	organisatorisch	organisatorisch	organisatorisch	organisatorisch	beliebig	beliebig
Fehlertoleranz	nicht spezifiziert	Ja	Ja	Ja	Ja	Ja
Replikationskonsistenz	nicht spezifiziert	Zeitstempel	Zeitstempel	Zeitstempel	Zeitstempel	Zeitstempel
Art des Vorhaltens	nicht spezifiziert	klientenseitig	klientenseitig	klientenseitig	klientenseitig	anwendungs-abhängig
Rekonfiguration	Nein	Nein	Ja	Nein	Nein	Ja
Dynamische Verwaltung	Nein	Blatteinträge	Blatteinträge	Blatteinträge	Nein	Ja
Objektmigration	Nein	Nein	Ja	Ja	Ja	Ja
Authentisierung	Ja	Ja	Ja	Ja	Nein	Ja

Tabelle Anhang B .7: Gegenüberstellung der Eigenschaften globaler Verzeichnisdienste

Mit Ausnahme von Profile bieten alle Systeme Mechanismen zur Authentisierung und Zugriffskontrolle an, die meist auf bekannten Standardtechniken (z.B. Kerberos) beruhen. Insbesondere NDS ermöglicht eine einzige, globale Sicht aller Netzwerkdienste. Benutzern wird mit einer einzigen Anmeldung unabhängig vom Aufenthaltsort des Benutzers oder der Ressource der Zugang ermöglicht.

Die meisten Verzeichnisdienste bieten die Möglichkeit zur dynamischen Registrierung und Freigabe von Verzeichniseinträgen an den Blättern des Verzeichnisbaums. Somit wird auch die Migration von verzeichneten Objekten ohne Eingreifen eines Administrators unterstützt. Insbesondere NDS bietet ein grafisches Werkzeug zur zentralen Verwaltung des Verzeichnisses, das die Reorganisation des Verzeichnisbaums durch drag-and-drop erlaubt. Sowohl NDS als auch ADSI offerieren grafische Browser, so daß Klienten Objekte nicht nur durch gezielte Suchanfragen, sondern auch durch das Blättern im Verzeichnis auswählen können.

Verzeichnisdienste bieten gegenüber globalen Namensverwaltungen eine weitaus höhere Flexibilität bei der Verwaltung von Informationen über Objekte. Allerdings skalieren nicht alle in Verzeichnisdiensten verwendeten Verfahren global.

Anhang B .6 Namen in globalen Informationssystemen

Globale Namensverwaltungen werden häufig zusammen mit globalen Informationssystemen verwendet. Sofern Namensverwaltungen attributierte Namenseinträge und Verzeichnisse von Netzwerk-Ressourcen verwalten, verwischt sich für den Anwender gelegentlich sogar der Unterschied. Um die Differenzen und Zusammenhänge zu verdeutlichen, beschäftigt sich der folgende Abschnitt mit Namen in globalen Informationsdiensten. Anschließend werden Katalog- und Verzeichnissysteme im Internet sowie Suchmaschinen in globalen Informationssystemen vorgestellt und die Unterschiede zu globalen Namensverwaltungen verdeutlicht.

Anhang B .6.1 Namen in globalen Informationssystemen

Während über Jahre hinweg als Anwendungen im DARPA Internet Terminalsitzungen, Electronic Mail und Filetransfer vorherrschten, sind in jüngster Zeit Dienste entwickelt worden, die dem Anwender die Navigation durch die im Netzwerk verfügbaren Informationen erheblich vereinfachen. Bereits der Erfolg der USENET News dokumentierte den Bedarf der Anwender nach einem aktuellen globalen Informationssystem. Einen neuen Weg zur Bereitstellung von Informationen beschritten Internet-Dienste wie Gopher und das World-Wide Web. Informationen werden in lokalen Dateien abgelegt, auf die Referenzen in anderen Dateien verweisen. Diese Verweise bestehen aus Rechner- und Dateinamen und können somit rechnerübergreifend angelegt werden,wodurch eine weltweite Struktur aus verketteten Dokumenten entsteht.

Gopher [Martin, 93] oder exakter „der Internet Gopher“ entstand an der University of Minesota und ermöglicht das Blättern in Netzwerk-Ressourcen anhand von Menüs. Wird ein Eintrag von Interesse gefunden, so kann er zugegriffen werden, ohne daß man sich Gedanken über Domain-Namen und IP-Adressen machen muß. Der eigentliche Vorteil jedoch liegt darin, daß der Anwender durch die Internet-Ressourcen blättern kann, unabhängig davon, welchen Typ und welche Lokation die Ressource besitzt. Gopher verwendet das passende Protokoll, je nachdem, ob der Dienst über Telnet, FTP etc. erreichbar ist.

Die Schwierigkeit, die gewünschten Informationen zu lokalisieren, bleibt jedoch auch mit Gopher weiterhin bestehen. Gopher integriert zwar Dienste wie WAIS [Kahle, 91], X.500 und Archie [Emtage, 92], jedoch halten diese nur jeweils einen partiellen Index der verfügbaren Ressourcen im Internet. Ein allgemeiner Verzeichnisdienst zur Verwaltung aller über Gopher verfügbaren Ressourcen existiert nicht. Die in Gopher enthaltenen Informationen und Dienste werden von Institutionen bereitgestellt, die einen eigenen Gopher-Server unterhalten. Der Zugriff erfolgt über Verweise, die in Gopher-Verzeichnissen enthalten sind. Administrative Restrukturierungen der Verzeichnisse eines Gopher-Servers implizieren eine Anpassung der zugehörigen Verweise in referenzierenden Verzeichnissen. Mechanismen sind hierfür in Gopher jedoch nicht vorgesehen, so daß lediglich ein manueller Abgleich der Verweise die Gültigkeit wiederherstellen kann.

Das World-Wide Web (WWW) stellt den neuesten und mächtigsten Informationsdienst im Internet dar. WWW realisiert die seit langem bekannte Hypertext-Technik^[2] im Internet. Ein Großteil der Entwicklungsarbeit zu WWW wurde am CERN, dem Europäischen Zentrum für Teilchenphysik verrichtet [Berners-Lee, 92]. World-Wide Web ist die wohl flexibelste und am weitesten fortgeschrittene Methode im Internet zu „blättern“. Klientenprogramme sind für nahezu alle gängigen Betriebssysteme verfügbar und erlauben die bequeme Navigation mit der Maus.

WWW ist der Versuch, alle im Internet verfügbaren Informationen in Form von Hypertext-Dokumenten zu organisieren. Geblättert wird im Netzwerk, indem man sich über Verweise (links) von einem Dokument zum nächsten bewegt, wobei das nachfolgende Dokument wiederum Verweise enthalten kann. Die WWW-Dokumente eines Rechners sind dabei im Dateisystem meist hierarchisch organisiert. Durch die in WWW-Dokumenten enthaltenen Verweise, die eine Art Menü realisieren, und zusätzliche Querverweise bildet die logische Verkettung einen Graphen (vgl. Abbildung Anhang B .43).

WWW-Dokumente werden im HTML-Format (hypertext markup language) erstellt, und können verschiedene Hervorhebungen und Schriftarten beinhalten. Grafiken sind in WWW-Dokumente durch Referenzen auf GIF- oder JPEG-Dateien eingebunden. Verweise auf andere WWW-Dokumente werden in HTML-Dokumenten bei der Darstellung besonders gekennzeichnet, sind jedoch für den Anwender nicht direkt sichtbar.

In WWW-Dokumenten werden als Verweise Uniform Resource Locator (URL) verwendet. Wie obiges Beispiel zeigt, gibt es einem syntaktischen Bruch innerhalb der URLs. Während der erste Teil den gewünschten Dienst bezeichnet, gibt der zweite Teil (fett hervorgehoben) offensichtlich den Namen des Rechners an, auf dem sich das Dokument befindet. Der dritte Teil der URL ist der Pfadname in UNIX-Syntax der Datei auf dem Rechner. Verweise in WWW verbinden somit unterschiedliche Namensräume. Der Domain-Name des Rechners wird beim Zugriff durch das DNS aufgelöst, während den Pfadnamen das Dateisystem des betreffenden Rechners interpretiert. WWW implementiert also keinen eigenen, einheitlichen Namensraum für WWW-Dokumente, sondern stützt sich auf vorhandene globale und lokale Namensdienste.

Abbildung Anhang B .43: URL Verweise zwischen WWW-Dokumenten auf verschiedenen Rechnern

Referenzen auf ein WWW-Dokument können weltweit verstreut in einer Vielzahl unterschiedlicher WWW-Dokumente auftreten (vgl. Abbildung Anhang B .43). Der Ersteller eines WWW-Dokuments hat hierüber keine Kontrolle. Die Folge sind Konsistenzprobleme, die immer dann auftreten, wenn WWW-Dokumente umbenannt oder gelöscht werden. Da sich die Verweise nicht in einem Verzeichnis oder einer Datenbank, sondern in einer „normalen“ Textdatei befinden, besteht keine Möglichkeit, geänderte Referenzen selbständig anzupassen. Gleiches gilt für Verweise auf im Internet gefundene Dokumente von besonderem Interesse. Diese können lokal vermerkt werden, wobei WWW jedoch keine Mechanismen vorsieht, Klienten über Änderungen an diesen Verweisen in Kenntnis zu setzen. Zur Zeit befinden sich weltweit viele WWW-Server im Aufbau. Offensichtlich werden die beschriebenen Konsistenzprobleme erst dann werden, wenn nach einer anfänglichen Betriebsphase umfassende Änderungen der Informationsstruktur unumgänglich werden.

Anhang B .6.2 Such- und Verzeichnisdienste im Internet

Bei der Suche nach Informationen im Internet dominierte langezeit das „Blättern“ (Browsen, Surfen) in Verzeichnissen (Gohper, WWW). Mittlerweile existieren im Internet auch Dienste, die eine Suche nach Dokumentinhalten mit regulären Ausdrücken erlauben und so das Auffinden von Informationen im Netzwerk erleichtern. Diese Funktionalität ist prinzipiell mit der Lokalisierung von Objekten im Netzwerk durch attributierte globale Namensverwaltungen vergleichbar und liefert im allgemeinen ebenso mehrdeutige Ergebnisse. Suchdienste sind jedoch zentral organisiert und verwalten Indizes über Dokumentinhalte und keine Objekteigenschaften. Namen dienen hierbei nur als Verweise auf Dokumente und werden in keiner Weise aufgelöst oder interpretiert.

Der Wide Area Information Service (WAIS) [Kahle, 91] stellte als erstes ein allgemeines Protokoll zur Verfügung, um auf Volltext-Datenbanken über das Internet zuzugreifen. Das inhärente Problem liegt in der Suche der geeigneten WAIS-Datenbank, die die gewünschten Informationen enthält. Ein einheitlicher Index, der über den Inhalt aller Datenbanken Auskunft gibt, existiert nicht. Erst in jüngster Zeit wurden Vorschläge unterbreitet, die anhand von sog. content labels inhaltsgesteuert den Zugriff auf WAIS-Datenbanken ermöglichen [Duda, 94].

Das Problem des Auffindens von Dateien auf FTP-Servern anhand von Namensfragmenten versucht Archie [Emtage, 92] durch Indizierung von Dateinamen zu lösen. Hierzu werden die Inhalte von FTP-Servern über anonymes FTP periodisch an Archie-Server übermittelt. Der Archie-Server erstellt nach verschiedenen Kriterien einen Index über die übermittelten Dateiinformationen. Die Archie-Server gleichen ihrerseits (zumindest theoretisch) die Datenbestände untereinander ab. Zur Lokalisierung einer bestimmten Datei richtet der Klient eine Anfrage an den nächsten bekannten Archie-Server, der bei Erfolg die Knoten- und Pfadnamen der gesuchten Datei liefert.

Die Systeme WAIS und Archie erstellen einen Index über Informationen in einer Datenbank. In großen Systemen verhindert der Umfang der zu indizierenden Datenmenge, die Häufigkeit der Änderungen und die Überwindung administrativer Grenzen das Erstellen eines einheitlichen Index. Verteilte Indizierung [Danzig, 91] ist ein Ansatz für die Erstellung und Wartung mehrfacher Indizes. Jeder Index enthält Informationen über ein bestimmtes Gebiet, unabhängig von den zu indizierenden Daten. Der Einsatz von mehrfachen Indizes für die Organisation von Informationen in großen Systemen verlangt jedoch die Entwicklung von Mechanismen, um Anfragen zum geeigneten Index zu leiten.

Mittlerweile gibt es auch im World Wide Web (WWW) verschiedene Suchdienste und Themenkataloge, die zu bestimmten Schlüsselwörtern und Schlagworten Verweise auf WWW-Seiten (URLs) verwalten. Nach Angaben des Internet World Magazins umfaßte das Informationsangebot im WWW im Mai 1996 über 20 Millionen Seiten [Conte, 96] und wächst exponentiell weiter, wobei sich nach Schätzungen zur Zeit die Anzahl der Seiten alle vier Monate verdoppelt [Venditto, 96]. Hinzu kommt, daß es im WWW keinen bibliographischen Standard gibt, wie man ihn aus dem Verlagswesen kennt. Es gibt kein Äquivalent zur ISBN, um ein Dokument eindeutig zu identifizieren, kein Standardsystem zur Katalogisierung und Klassifizierung, ähnlich dem der Library of Congress, keinen zentralen Katalog, der den gesamten Inhalt des WWW enthält. In den meisten WWW-Dokumenten fehlen sogar das Erstellungsdatum und der Autor.

Das WWW entspricht der weltgrößten Bibliothek, wobei die Bücher und Journale (ohne Umschlag und Titel) in beliebiger Reihenfolge und ohne Bezug zu einem zentralen Katalog in den Regalen stehen. Anstelle eines zentralen Kataloges bietet das WWW eine Vielzahl von Suchmaschinen, jede mit ihrer eigenen Datenbank, Abfragesprache, Suchmöglichkeiten und Methoden, die Ergebnisse zu präsentieren. Es ist klar, daß sich der Anwender mit diesen Suchwerkzeugen auseinandersetzen und geeignete Suchstrategien entwickeln muß, wenn er Nutzen aus den Informationen im WWW ziehen will, ohne zuviel Zeit damit zu vergeuden, in irrelevanten Daten herumzustochern.

Die zwei grundlegenden Ansätze, um im WWW zu suchen, sind Suchmaschinen und Themenkataloge. Suchmaschinen erlauben dem Benutzer, Schlüsselwörter einzugeben und diese gegen eine Datenbank zu fahren. Basierend auf einer Kombination von Kriterien, die vom Benutzer und/oder der Suchmaschine vorgegeben werden, sucht die Suchmaschine nach WWW-Dokumenten mit den gewünschten Schlüsselwörtern. Die Inhalte der Datenbanken von Suchmaschinen werden häufig automatisch durch sog. „Spiders“ oder „Robots“ erstellt. Jedoch ist in vielen Fällen auch das manuelle Registrieren von Seiten unter Angabe von Schlüsselwörtern möglich.

Während alle Suchmaschinen dieselbe Aufgabe erfüllen sollen, geht jede dabei anders vor, was dazu führt, daß dieselbe Anfrage oftmals zu erstaunlich unterschiedlichen Ergebnissen führt. Faktoren, die die Ergebnisse beeinflussen, sind die Größe der Datenbank, die Häufigkeit ihrer Aktualisierung und die Suchmöglichkeiten. Die Suchmaschinen unterscheiden sich auch in der Suchgeschwindigkeit, dem Design der Suchschnittstelle, der Art, in der Ergebnisse präsentiert werden und der Hilfestellung, die sie für die Suche anbieten. Eine Liste bekannter Suchdienste enthält Tabelle Anhang B .8. Ein umfassender Vergleich von Suchdiensten findet sich im WWW z.B. auf der Seite „http://oksw01.okanagan.bc.ca/libr/connect96/search.htm“.

Suchmaschine	URL
Alta Vista	http://altavista.digital.com
Excite	http://www.excite.com
Infoseek	http://guide.infoseek.com
Lycos	http://www.lycos.com
Open Text	http://index.opentext.net

Tabelle Anhang B .8: Wichtige Suchmaschinen im WWW

Die Zunahme der Suchdienste hat dazu geführt, daß sog. Metasuchmaschinen entstanden, die oft auch als sog. „Multi-threaded Search Engines“ bezeichnet werden (vgl. Tabelle Anhang B .10). Diese Suchmaschinen ermöglichen es einem Anwender gleichzeitig mehrere Datenbanken zu konsultieren und dabei ein einheitliches Benutzerinterface zu verwenden.

Metasuchmaschine	URL
Metacrawler	http://metacrawler.cs.washington.edu:8080/index.html)
SavvySearch	http://guaraldi.cs.colostate.edu:2000/)

Tabelle Anhang B .10: Beispiele für Meta-Suchmaschinen im WWW

Themenkataloge sind im Gegensatz zu Suchmaschinen hierarchisch organisierte Indizes von Suchkategorien, die es erlauben, bei der Suche durch Listen von WWW-Seiten zu einem Thema zu blättern, um nach den relevanten Informationen zu suchen (vgl. Tabelle Anhang B .12). Diese Indizes werden von Menschen erstellt und gewartet. Viele Katalogsysteme enthalten zusätzlich eine Suchmaschine, um die eigene Datenbank zu durchsuchen.

Die Datenbanken von Themenkatalogen sind tendenziell kleiner als die von Suchmaschinen, was dazu führt, daß die Ergebnislisten in der Regel ebenfalls kürzer sind. Es gibt jedoch noch weitere Unterschiede zwischen Suchmaschinen und Themenkatalogen, die dazu führen können, daß letztere bessere Ergebnisse liefern. So indiziert zum Beispiel eine Suchmaschine jede WWW-Seite, während ein Themenkatalog wahrscheinlich nur einen Verweis auf die Home Page des WWW-Servers bereitstellt. Da an der Wartung von Themenkatalogen Menschen beteiligt sind, sinkt die Wahrscheinlichkeit, daß Ergebnisse geliefert werden, die nicht das gesuchte Thema betreffen.

Themenkatalog	URL
Internet Public Library Ready Reference Collection	(http://ipl.sils.umich.edu:80/ref/RR/)
Magellan	(http://www.mckinley.com)
Scott Yanoff's Internet Services List	(http://www.spectracom.com/islist/)
WWW Virtual Library	http://www.w3.org/hypertext/DataSources/bySubject/Overview.html)
Yahoo	(http://www.yahoo.com)
DINO	http://www.dino-online.de

Tabelle Anhang B .12: Einige Themenkataloge im WWW

Aufgrund des gewaltigen Umfangs des Informationsangebots im WWW und der stetigen Veränderungen ist es auf manueller Basis nahezu unmöglich, mit dem Informationsangebot für alle Themengebiete schrittzuhalten. Daher ist es sehr viel wahrscheinlicher, daß ein Katalog von wichtigen Informationsquellen, der von einem Spezialisten zu einem Thema erstellt wurde, die relevanten Informationen enthält, als ein allgemeiner Themenkatalog. Solche Kataloge existieren zu nahezu jedem Thema. Argus Clearinghouse (http://www.clearinghouse.net) ist ein exzellentes Verzeichnis mit vielen Verweisen auf derartige Spezialkataloge.

Unabhängig vom verwendeten Suchwerkzeug ist es wichtig, eine effiziente Suchstrategie zu entwickeln, wenn man befriedigende Suchergebnisse von einer derart großen und amorphen Datenquelle wie dem WWW erhalten will. Neben den Eigenschaften, die bereits diskutiert wurden, ist ein weiterer Faktor, der die Notwendigkeit effektiver Suchstrategien unterstreicht, die Tatsache, daß die meisten Suchmaschinen jedes Wort einer Seite indizieren. Dabei werden lediglich sog. Alltagswörter wie „der“, „und“, „auf“ usw. entfernt. Diese Art der Indizierung tendiert dazu, die Anzahl der Ergebnisse zu erhöhen, wobei die Relevanz der Daten in gleichem Maße sinkt, da die Wahrscheinlichkeit höher ist, daß Ergebnisse nicht im passenden Kontext liegen. Bei der Auswahl der Suchmaschine sollte man daher darauf achten, ob es möglich ist, anzugeben, welcher Teil eines Dokuments durchsucht werden soll (z.B. URL, Titel, erste Kopfzeile), oder ob die Suchmaschine immer das gesamte Dokument durchforstet.

Die logischen Operationen, mit deren Hilfe die Suchbegriffe in vielen Datenbanken verbunden werden, beruhen auf Boolscher Logik. Die elementaren Boolschen Operatoren werden durch die Wörter „AND“, „OR“ und „NOT“ repräsentiert. Variationen dieser Operatoren (Proximity Operators), die von manchen Suchmaschinen unterstützt werden, umfassen Operatoren wie „ADJACENT“, „NEAR“ und „FOLLOWED BY“.

Zusammenfassend läßt sich festhalten, daß es sich bei Suchmaschinen und Themenkatalogen um zentrale Dienste handelt, d.h. ihre Datenbank ist nicht verteilt organisiert. Während die Inhalte von Suchmaschinen durch das automatische Sammeln und Indizieren von Informationen erstellt werden, entstehen Themenkataloge durch mühsames manuelles Sammeln relevanter Informationen. Wünschenswert für künftige Erweiterungen wäre eine einheitliche Kategorisierung und Beschreibung aller verfügbaren Informationen und die verteilte Verwaltung durch einen adäquaten globalen Verzeichnisdienst.

Suchmaschinen und Themenkataloge für globale Informationsdienste ermöglichen das Auffinden von Informationen, indem sie zu Schlüssel- und Schlagwörtern globale Verweise auf Dokumente aus Rechner- und Dateinamen verwalten. Während die in Suchmaschinen enthaltenen Dokumentnamen zentral erfaßt und automatisch aktualisiert werden, müssen die Einträge verteilter Themenkataloge manuell erstellt und aktualisiert werden.

Anhang C Datenstrukturen der dynamischen globalen Namensverwaltung

Die strukturierten Namen der dynamischen globalen Namensverwaltung zerfallen in eine Folge flacher Namen und werden entsprechend als verkettete Namenseinträge verwaltet. Namenseinträge für Objekte und Kontexte werden gemeinsam in einer Datenstruktur abgelegt, die im wesentlichen der Darstellung in Abbildung Anhang C .1 entspricht.

NameEntryPtr = POINTER TO NameEntry;

NameEntry = OBJECT

Name: SimpleName;

OID: ObjectIdentifier ;

PID: ObjectIdentifier ;

Status: EntryStatus;

Type: EntryType;

END;

Abbildung Anhang C .1: Struktur eines lokalen Namenseintrags

Namenseinträge werden im Sinne der objekt-orientierten Programmierung intern als Objekte vom Typ NameEntry realisiert und enthalten einen einfachen Namen Name, den Bezeichner OID des gebundenen Objekts bzw. Kontexts, den Bezeichner des übergeordneten Kontexts PID sowie Status und Typ des Eintrags. Die einzelnen Namenseinträge werden zur Bildung strukturierter Namen über das Feld PID rückwärts verkettet. Die Felder Name und OID repräsentieren explizite Attribute[AL6] eines Namenseintrags und sind für den Anwender über Funktionen zugreifbar. Die übrigen Felder sind implizit und stehen nur der Namensverwaltung zur Verfügung.

Der Anwender übergibt hierarchische Namen an die dynamische globale Namensverwaltung als strukturierte Zeichenketten, deren einzelne Komponenten durch einen Punkt „.“ separiert sind (vgl. Kapitel 2). Ein hierarchischer Name wird intern vom der Namensverwaltung komponentenweise als Folge von Namenseinträgen NameEntry abgelegt. Der einfache Name Name in NameEntry kann sowohl Kontexte als auch Objekte bezeichnen und besteht lediglich aus einer unstrukturierten Zeichenkette. Flache Namen treten nicht an der Anwendungsschnittstelle auf (vgl. Abbildung 3.7).

Abbildung Anhang C .2: Struktur eines lokalen und globalen Namenseintrags

Zur Unterstützung der Namensverwaltung können Namenseinträge folgenden Status aufweisen:

local, zone, global, external, cached, replicated, invalid, deleted

Der Status local markiert einen lokalen Namenseintrag, der nur lokal bekannt und eindeutig ist und von außerhalb eines Namensverwalters nicht zugegriffen werden kann. Um ein Objekt über den Namen auch außerhalb eines Namensverwalters zugänglich zu machen, muß der Namenseintrag zonenweit oder global registriert werden, wobei er den Status zone oder global erhält. Wurde ein globaler Eintrag explizit bei einem Namensverwalter registriert, so erhält er dort den Status external, wurde er nach erfolgreicher Auflösung eines Namens vorgehalten, so erhält der Eintrag den Status cached. Aktiv replizierte Namenseinträge tragen den Status replicated (vgl. Kapitel 5). Externe oder vorgehaltene Einträge, die längere Zeit nicht verifiziert werden konnten, werden als invalid markiert, aber nicht sofort entfernt. Explizit gelöschte Namenseinträge werden mit deleted markiert, bevor sie endgültig aus der Namensbasis des Namensverwalters entfernt werden.

Zur Unterscheidung enthalten Namenseinträge außerdem den Typ des Eintrags:

Object, Context, Path, Attribute, Synonym

Das Feld Type gibt an, ob der Namenseintrag einen Namen für ein Objekt oder einen Kontext enthält. Der Wert Path bezeichnet einen Namenseintrag für einen Pfad zu einem einzelnen Namenseintrag. Die Werte Attribute und Synonym kennzeichnen Namenseinträge für attributierte Namen bzw. Synonyme.[AL7]

Externe, replizierte und vorgehaltene Einträge enthalten zusätzliche Informationen über den administrativen und den primären Namensverwalter. Hierzu wird der Namenseintrag um die entsprechenden Felder erweitert (vgl. Abbildung Anhang C .3).

GlobalNameEntry = OBJECT

(NameEntry);

PrimaryNameServer: Node;

AdministrativeNameServer: Node;

validated: DateTime;

END;

Abbildung Anhang C .3: Struktur eines globalen Namenseintrags

Wie bereits angedeutet, werden hierarchische Namen als verkettete Folge von Namenseinträgen repräsentiert. Die Verkettung wird über das Feld PID realisiert, das den Bezeichner eines übergeordneten Kontextes enthält. Dadurch ergibt sich eine hierarchische, rückwärtsverkettete Struktur von Namenseinträgen (vgl. Abbildung Anhang C .5).

Abbildung Anhang C .5: Verkettung von Namenseinträgen

Die Verkettung von Namenseinträgen zur Repräsentation hierarchischer Namen kann in Form einer Tabelle dargestellt werden. Tabelle Anhang C .1 beschreibt die Baumstruktur aus Abbildung 2.24[AL8] . Der Name „uni-ulm.info.vs“ wird beispielsweise durch die Tupel (uni-ulm, $1, $0), (info, $2, $1) und (vs, $3, $2) repräsentiert. Die Relation wird über das Feld PID (dem Objekt-Bezeichner des Namenseintrags) hergestellt. Synonyme für Objekte können durch mehrfache Einträge in dieser Struktur erzeugt werden. Außerdem sind auf diese Art sehr leicht Querverweise (Links) herzustellen (z.B. (info, $2, $0)).

Name	OID	PID
uni-ulm	$1	$0
info	$2	$1
vs	$3	$2
daimler	$4	$0
Mercedes	$5	$4
AEG	$6	$4
math	$7	$1
med	$8	$1
dbis	$9	$2
info	$2	$0

Tabelle Anhang C .1: Interne Repräsentation der hierarchischen Namensstruktur aus Abbildung 2.24[AL9]

Namenseinträge werden dynamisch auf dem Heap angelegt und über drei Suchbäume, die nach den jeweiligen Komponenten der Namenseinträge sortiert sind, zugegriffen (vgl. Abbildung Anhang C .7). Die Suchbäume gewährleisten eine flexible Speicherung der Namenseinträge und einen effizienten Zugriff der Namenseinträge nach verschiedenen Kriterien. Die Art des Zugriffs auf Namen wird somit durch den Algorithmus zum Durchlaufen der Namenseinträge und nicht durch die Datenstruktur zur Aufnahme der Namensinformationen selbst festgelegt.

Abbildung Anhang C .7: Suchbäume für den Zugriff auf Namenseinträge

Der Zugriff eines Namenseintrags über Suchbäume tangiert nur wenige Speicherseiten, was insbesondere in DSM-Systemen von Bedeutung ist (vgl. [Lupper, 94]). Durch die feine Granularität der Namenseinträge können durch das Speichermanagement mehrere Namenseinträge in physikalischen Speicherseiten gruppiert werden, die im gemeinsamen verteilten Speicher auf den Knoten wandern, der sie zugreift (vgl. [Traub, 94]). Somit ist zu erwarten, daß sich die externen Seitenzugriffe bei der Namensauflösung mit der Zeit vermindern. Eine weitere Beschleunigung des Zugriffs kann durch die Umordnung der Suchbäume unter Berücksichtigung der Zugriffshäufigkeit der Namenseinträge erreicht werden.

Die Rückwärtsverkettung von Namenseinträgen und der Zugriff über Suchbäume erlauben den Aufbau eines flexiblen Namensraums und einen effizienten Zugriff.

Anhang D Grundlegende lokale Namensoperationen

PROCEDURE RegisterSimpleName(NameEntry: NameEntryPtr): Result;

VAR I: SET OF NameEntryPtr;

BEGIN

RegisterSimpleName := ResolveSimpleName(NameEntry, I) ;

IF I= {} OR NameEntry^.Type= Attribute THEN

WITH NameEntry^ DO

RegisterSimpleName:= InsertNameIndex(SimpleName, NameEntry);

RegisterSimpleName:= InsertOIDIndex(OID, NameEntry);

RegisterSimpleName:= InsertPIDIndex(PID, NameEntry);

END

END

END RegisterSimpleName;

PROCEDURE ResolveSimpleName(VAR NameEntry: NameEntryPtr;

VAR NameEntries: Set of NameEntryPtr): Result;

BEGIN

ResolveSimpleName := empty; NameEntries := { };

WITH NameEntry^ DO

NameEntries := GetNameIndex(SimpleName);

NameEntries := NameEntries AND GetOIDIndex(OID);

NameEntries := NameEntries AND GetPIDIndex(PID);

END;

ResolveSimpleName := found;

END ResolveSimpleName;

PROCEDURE DeleteSimpleName(NameEntry: NameEntryPtr): Result;

VAR I: SET OF NameEntryPtr;

BEGIN

DeleteSimpleName := ResolveSimpleName(NameEntry, I);

WITH NameEntry^ DO

DeleteSimpleName := DeleteNameIndex(Name, I);

DeleteSimpleName := DeleteOIDIndex(OID, I);

DeleteSimpleName := DeletePIDIndex(PID, I);

END;

DeleteSimpleName := DeleteNameObject(I); { if there is no garbage collection! }

END DeleteSimpleName;

Anhang E: Verzeichnis der Abbildungen

Abbildung 1.1: Prognostizierte Entwicklung von Rechnern und Domain Namen im Internet................ 1

Abbildung 1.2: Adreßkomposition im ISO/OSI-Schichtenmodell................ 9

Abbildung 1.3: Abbildung von Namen auf Adressen der ISO/OSI-Schichten........... 10

Abbildung 1.4: Namen und Adressen in TCP/IP-Protokollen.... 11

Abbildung 2.1: Namen auf verschiedenen Ebenen eines verteilten Systems.............. 22

Abbildung 2.2: Ebenen eines verteilten Systems.............. 24

Abbildung 2.3: Arten von Benutzer-Namen 26

Abbildung 2.4: Arten von Namensräumen 27

Abbildung 2.5: Die hierarchische Strukturierung eines Namensraums mit disjunkten Kontexten......... 29

Abbildung 2.6: Darstellung eines hierarchischen Namensraums als Mengendiagramm.............. 30

Abbildung 2.7: Tabellendarstellung orthogonaler Attribute............ 33

Abbildung 2.8: Mengendarstellung orthogonaler Attribute............ 33

Abbildung 2.9: Inklusion von Namen 35

Abbildung 2.10: Kontextabhängigkeit eindeutiger hierarchischer Namen 36

Abbildung 2.11: Verwaltung von Namen als Betriebsmittel 37

Abbildung 2.12: Horizontales und vertikales Wachstum hierarchischer Namensräume.. 38

Abbildung 2.13: Methoden zum Vereinigen von Namensräumen 39

Abbildung 2.14: Lokale Namensräume als Blätter eines globalen Namensraums.. 40

Abbildung 2.15: Speicherung von Attributen im hierarchischen Namensraum.... 41

Abbildung 2.16: Partielle Darstellung der Informationen aus Tabelle 2.1 in einem Graphen.............. 43

Abbildung 2.17: Tabellarische Darstellung der Informationen aus Tabelle 2.1......... 43

Abbildung 2.18: Hierarchische und tabellarische Darstellung der Informationen aus Tabelle 2.1......... 44

Abbildung 2.19: Restrukturierung von Hierarchien mit Teilordnungen 44

Abbildung 2.20: Orthogonale Attribute aus Tabelle 2.1 in hierarchischen Namensräumen 45

Abbildung 2.21: Alternative Repräsentation von Attributwerten in hierarchischen Namensräumen 47

Abbildung 2.22: Repräsentation orthogonaler Attribute in separaten Hierarchien........ 48

Abbildung 2.23: Attribute in den Blättern eines hierarchischen Namensraums.. 48

Abbildung 2.24: Optionale Namensteile im zyklischen gerichteten Graphen.............. 49

Abbildung 2.25: Darstellung von Synonymen im azyklischen gerichteten Graphen und in Baumstukturen 50

Abbildung 2.26: Implizite Attributtypen. 51

Abbildung 2.27: Aufnahme von Attributtypen in den hierarchischen Namensraum.... 51

Abbildung 2.28: Repräsentation von expliziten Attributtypen in hierarchischen Namensräumen 52

Abbildung 2.29: Quantitative Beziehungen zwischen Namen und Objekten.............. 55

Abbildung 2.30: Einstufige Abbildung von Namen auf Adressen.............. 55

Abbildung 2.31: Die zweistufige Abbildung zwischen den Namensräumen in verteilten Systemen........... 56

Abbildung 2.32: Zustände der lokalen Auflösung hierarchischer Namen (resolve).............. 62

Abbildung 2.33: Zustände der lokalen Registrierung hierarchischer Namen 63

Abbildung 2.34: Zustände des lokalen Löschens hierarchischer Namen 63

Abbildung 2.35: Lokales Ermitteln des hierarchischen Namens eines Objekts.............. 64

Abbildung 3.1: Das Client-Server-Modell in der Namensverwaltung......... 66

Abbildung 3.2: Strukturelle Komponenten einer Namensverwaltung nach dem Client-Server-Prinzip 66

Abbildung 3.3: Architekturmodell der dynamischen globalen Namensverwaltung......... 68

Abbildung 3.4: Wechselwirkungen der Betriebssystemkomponenten beim Zugriff über Namen 69

Abbildung 3.5: Direkte und indirekte Interaktion der Applikation mit der Namensverwaltung......... 70

Abbildung 3.6: Funktionales Modell eines Namensverwalters nach Terry. 71

Abbildung 3.7: Funktionales Modell eines Namensverwalters der dynamischen globalen Namensverwaltung......... 73

Abbildung 3.8: Die Ebenen des DSM-Modells.............. 76

Abbildung 3.9: Broadcast-Bereiche und deren Verbindungen... 77

Abbildung 3.10: Drahtgebundene und drahtlose Wählverbindungen........... 79

Abbildung 3.11: Grad der Verteilung und der Replikation........ 80

Abbildung 3.12: Modell einer zentralisierten Namensverwaltung......... 81

Abbildung 3.13: Propagieren von Namen bei vollständiger Replikation der Namensverwalter............ 82

Abbildung 3.14: Modell einer dezentralisierten Namensverwaltung......... 83

Abbildung 3.15: Vollständig verteilte Verwaltung von Namen 85

Abbildung 3.16: Konfigurations- und Navigationsinformation hierarchisch organisierter Namensverwalter............ 85

Abbildung 3.17: Verwalterinformationen in hierarchisch organisierten Namensverwaltern......... 88

Abbildung 3.18: Hierarchische Verwalterorganisation mit fester Anzahl von Verwalterebenen.............. 90

Abbildung 3.19: Hierarchische Verwalterorganisation mit variabler Anzahl von Verwalterebenen.............. 91

Abbildung 3.20: Positionierung eines neuen Namensverwalters......... 93

Abbildung 3.21: Verteilung von Namensverwaltern über verschiedene Netzwerkbereiche............ 94

Abbildung 3.22: Aus der in Abbildung 5.24 generierte Hierarchie von Namensverwaltern......... 95

Abbildung 3.23: Die Phasen des Einfügens eines neuen Namensverwalters......... 96

Abbildung 3.24: Das Einfügen eines zu replizierenden Namensverwalters......... 98

Abbildung 3.25: Die Phasen des Deaktivieren eines nicht replizierten Namensverwalters......... 99

Abbildung 4.1: Erkundungsstrategien in Bäumen............ 102

Abbildung 4.2: Schrittweise Auflösung des Namens „/a.b.c.d“ durch Remote-Pathname-Expansion......... 104

Abbildung 4.3: Bindung des gesamten Namens und Bindung von Teilnamen......... 104

Abbildung 4.4: Rekursive Auflösung globaler Namen............ 105

Abbildung 4.5: Iterative Auflösung globaler Namen............ 106

Abbildung 4.6: Transitive Auflösung globaler Namen mit Rückgabe von Teilergebnissen 106

Abbildung 4.7: Zusammenspiel verschiedener Verfahren zur Auflösung von Namen............ 107

Abbildung 4.8: Problem der Verteilung hierarchischer Namensräume auf hierarchische Verwalternetze............ 109

Abbildung 4.9: Methoden zur Verteilung der Namensinformation im Verwalternetz............ 110

Abbildung 4.10: Nicht-deterministische Verteilung von Namenseinträgen mit Navigationsinformation............ 111

Abbildung 4.11: Aufsteigende Verteilung der Namenseinträge............ 113

Abbildung 4.12: Aufsteigende Verteilung mit Kontextbildung............ 114

Abbildung 4.13: Verteilung der Namensinformation durch Hashing............ 115

Abbildung 4.14: Horizontale und vertikale Partitionierung anhand von Attributen....... 116

Abbildung 4.15: Aufteilung eines hierarchischen Namensraums in Segmente.......... 117

Abbildung 4.16: Verteilungsquanten von Namenseinträgen auf Namensverwalter.......... 118

Abbildung 4.17: Verteilung eines Namensraums auf hierarchisch organisierte Namensverwalter.......... 120

Abbildung 4.18: Zustände der globalen Namensauflösung.......... 123

Abbildung 4.19: Globale Auflösung eines hierarchischen Namens durch Navigation...... 124

Abbildung 4.20: Orientierungs- und Plazierungsphase der syntaxgesteuerten Plazierung von Namen............ 125

Abbildung 4.21: Propagieren von Navigationsinformation auf dem Pfad zum primären Namensverwalter.......... 127

Abbildung 4.22: Substituieren von Namenseinträgen durch Einträge übergeordneter Kontexte.......... 129

Abbildung 4.23: Zustände und Übergänge bei der globalen Registrierung von Namen............ 131

Abbildung 4.24: Zustände beim Löschen globaler Namenseinträge............ 132

Abbildung 4.25: Beispiel für das Löschen globaler Namen............ 133

Abbildung 4.26: Zuordnung von Synonymen über gemeinsame Objekt-Bezeichner in der Namensdatenbank......... 134

Abbildung 4.27: Zustände der generischen lokalen Namensauflösung.......... 136

Abbildung 4.28: Aufbau der Kellerstruktur bei der Auflösung generischer Namen............ 137

Abbildung 4.29: Beispiel einer generischen globalen Namensauflösung.......... 138

Abbildung 4.30: Repräsentation expliziter und impliziter Attribute im Namensraum.. 141

Abbildung 5.1: Vorhalten von Namenseinträgen in den Namensbasen von Namensverwaltern....... 146

Abbildung 5.2: Namensauflösung mit Hilfe vorgehaltener Namenseinträge im initiierenden Namensverwalter.......... 146

Abbildung 5.3: Vorhalten von Namen-Objekt-Bindungen im initiierenden Namensverwalter.......... 147

Abbildung 5.4: Vorhalten von Kontexteinträgen auf initiierenden Namensverwaltern....... 148

Abbildung 5.5: Vorhalten von Namenseinträgen in übergeordneten Namensverwaltern....... 149

Abbildung 5.6: Ausfall von Speicherlokalitäten und Partitionierung des Systems............ 150

Abbildung 5.7: Replikation von Namenseinträgen auf den Pfad zu Wurzel............ 152

Abbildung 5.8: Beispiel für die Namensauflösung bei Replikation von Namensverwaltern....... 153

Abbildung 5.9: Rekonfigurieren des Verwalternetzes bei Ausfall eines Namensverwalters....... 154

Abbildung 5.10: Beispiel einer konfliktären Registrierung von Namen............ 158

Abbildung 5.11: Syntaxgesteuerte Plazierung bei der Migration von benannten Objekten............ 159

Abbildung 5.12: Vorhalten von Verweisen auf den administrativen und primären Namensverwalter.......... 160

Abbildung 5.13: Direkter und indirekter Objektzugriff über vorgehaltene Namenseinträge............ 161

Abbildung 5.14: Mögliche Verfahren zur Erhaltung der Konsistenz von Namenseinträgen............ 163

Abbildung 5.15: Änderung und Abgleich eines partitionierten Namensraums 165

Abbildung 6.1: Grafische Repräsentation ausgewählter Sichten des Namensraums 170

Abbildung B.1: Die Auswahl im Macintosh System............ 192

Abbildung B.2: Konfiguration eines WINS-Klienten............ 194

Abbildung B.3: Die WINS-Datenbank eines WINS-Servers............ 195

Abbildung B.4: Zugriffsstatistik eines WINS-Servers............ 196

Abbildung B.5: Konfigurierung der Parameter zur Wahrung der Konsistenz der WINS-Datenbank...... 197

Abbildung B.6: Beispiel einer Netzwerk-Konfiguration mit WINS-Servern............ 199

Abbildung B.7: Vereinigen der Namensräume durch eine zusätzliche Dimension......... 201

Abbildung B.8: Vereinigen der Namensräume durch eine super root. 202

Abbildung B.9: Montieren von Unterverzeichnissen in NFS............ 203

Abbildung B.10: Lokale und gemeinsame Namensräume in AFS.... 204

Abbildung B.11: Verteilung eines LOCUS-Verzeichnisses auf file groups............ 205

Abbildung B.12: Kollaboration des Traders mit der Namensverwaltung....... 208

Abbildung B.13: Die Verzeichnisstruktur von GNS.... 210

Abbildung B.14: Namenshierarchie im V-System............ 212

Abbildung B.15: Die Struktur des Domain Name System............ 214

Abbildung B.16: Domains und Zonen in DNS.... 216

Abbildung B.17: Iterative Auflösung des Namens my.mac.gov.au in DNS.... 217

Abbildung B.18: Die Verzeichnisstruktur von X.500.. 220

Abbildung B.19: Die Interaktionen von DUA und DSA............ 221

Abbildung B.20: Der DCE Directory Service als integraler Bestandteil der DCE-Architektur.... 222

Abbildung B.21: Die Auswahl eines Novell Netware Directory-Baums............ 225

Abbildung B.22: Der Novell Netware Directory Browser zeigt vorhandene Geräte, Dienste und Applikationen 228

Abbildung B.23: Übersicht über die Active Directory Service Interfaces........ 230

Abbildung B.24: Interaktion der ADSI-Komponenten. 231

Abbildung B.25: Ansicht des ADSI Example Provider Directory.......... 231

Abbildung B.26: Das Active Directory Objekt und das Active Directory Container Objekt............ 232

Abbildung B.27: Der Active Directory Object Property Cache 233

Abbildung B.28: ADSI Schema Class-Objekt, ADSI Property-Objekt und ADSI Syntax-Objekt 234

Abbildung B.29: Konzeptuelle ADSI-Representationen: Browser, Containment, Schema............ 236

Abbildung B.30: Die ADSI-Softwareschichten....... 237

Abbildung B.31: URL Verweise zwischen WWW-Dokumenten auf verschiedenen Rechnern......... 240

Abbildung C.1: Struktur eines lokalen Namenseintrags............ 245

Abbildung C.2: Struktur eines lokalen und globalen Namenseintrags............ 245

Abbildung C.3: Struktur eines globalen Namenseintrags............ 246

Abbildung C.4: Verkettung von Namenseinträgen............ 247

Abbildung C.5: Suchbäume für den Zugriff auf Namenseinträge............ 248

Anhang F Verzeichnis der Tabellen

Tabelle 1.1: Die fünfzig häufigsten Host Namen (ohne Namen wie pc01, mac5, etc.), Stand 6.96......................................... 3

Tabelle 1.2: Transparenzformen und ihre Anforderungen an die Namensverwaltung........................................................... 4

Tabelle 1.3: Dimensionen der Skalierung und damit verbundene Probleme............................................................................. 6

Tabelle 1.4: Gegenüberstellung der Eigenschaften verteilter Namensverwaltungen und Datenbanken............................. 8

Tabelle 1.5: Gegenüberstellung der Eigenschaften lokaler und globaler Namensverwaltungen......................................... 18

Tabelle 2.1: Natürlichsprachliche Beschreibung von Geräten anhand ihrer Eigenschaften................................................ 42

Tabelle 2.2: Zuordnung von Objekt zu Adressen....................................................................................................................... 53

Tabelle 2.3: Zuordnung von Objekt-Bezeichnern zu Objekten................................................................................................. 53

Tabelle 2.4: Zuordnung von Namen zu Objekt-Bezeichnern..................................................................................................... 54

Tabelle 3.1: Netzwerkeigenschaften und ihr Einfluß auf das Verwalternetz........................................................................... 75

Tabelle 3.2: Vergleichsrelationen zur Positionierung von Namensverwaltern....................................................................... 93

Tabelle 3.3: Namensverwalter und ihre Netzwerkpfade zum obersten Namensverwalter..................................................... 94

Tabelle 3.4: Eigenschaften des Netzwerks und der Namensverwalter und ihr Einfluß auf die Replikation....................... 97

Tabelle 4.1: Namensbasen der Namensverwalter aus Abbildung 4.17.................................................................................. 121

Tabelle B.1: Aktivitäten in Abhängigkeit vom Zustand des Namenseintrags in WINS..................................................... 198

Tabelle B.1: Gegenüberstellung der Eigenschaften verteilter Dateisysteme........................................................................ 206

Tabelle B.2: Verwendete Top Level Domain-Namen im Internet............................................................................................ 215

Tabelle B.3: Gegenüberstellung der Eigenschaften globaler Namensverwaltungen........................................................... 218

Tabelle B.4: Beispiele für vom Active Directory Service unterstützte Namenskonventionen........................................... 229

Tabelle B.5: Gegenüberstellung der Eigenschaften globaler Verzeichnisdienste................................................................ 238

Tabelle B.6: Wichtige Suchmaschinen im WWW.................................................................................................................... 242

Tabelle B.7: Beispiele für Meta-Suchmaschinen im WWW.................................................................................................... 242

Tabelle B.8: Einige Themenkataloge im WWW........................................................................................................................ 243

Tabelle C.1: Interne Repräsentation der hierarchischen Namensstruktur aus Abbildung 2.24......................................... 247

Anhang G Lebenslauf

Geboren wurde ich als erstes Kind der Eheleute Josef Lupper und Hedwig Lupper, geborene Kammerer, am 30.5.1964 in Rain am Lech, Bayern. Von 1970 bis 1974 besuchte ich die Grundschule in Holzheim. Im Herbst 1974 wechselte ich auf das mathematisch-naturwissenschaftliche und neusprachliche Paul-Klee-Gymnasium in Gersthofen, wo ich im Mai 1983 die Reifeprüfung ablegte.

Danach leistete ich meinen Grundwehrdienst vom Juli 1983 bis September 1984 beim Panzergrenadier Bataillon 562 in Neuburg an der Donau.

In Anschluß daran nahm ich das Studium der Mathematik mit Nebenfach Informatik an der Universität Augsburg auf. Im Herbst 1986 bestand ich das Vordiplom und im Herbst 1989 die Diplomprüfung.

Seit Februar 1990 arbeite ich als wissenschaftlicher Mitarbeiter in der Abteilung für verteilte Systeme der Fakultät für Informatik an der Universität Ulm. Hier zeichnete ich zunächst mitverantwortlich für den Aufbau der Rechnerinfrastruktur der Informatik. Anschließend befaßte ich mich mit Fragen der LAN-Integration über digitale Nebenstellenanlagen, verteilten Betriebssystemen und mit der Namensverwaltung in verteilten Systemen. Während meiner Tätigkeit in Ulm organisierte ich u.a. eine internationale Konferenz über modulare Programmiersprachen JMLC 94. Seit November 1995 leite ich das Workpackage 6 User Trials im Rahmen des europäischen ACTS Projekts Magic WAND.

---

^[1] Defence Advanced Research Projects Agency

^[2] Die ursprüngliche Idee eines weltweiten Hypertext-Systems geht zurück auf Ted Nelson.

---

[AL1] Zyklen im Namensraum müssen erkannt werden!

[AL2]Hier ist noch etwas zusammenzufassen und zu kürzen!

[AL3]Alias?

[AL4]Schief

[AL5] Vgl. Verteilte Datenbanken

[AL6]implizite Felder??

[AL7]Bedeutung von Pfaden?

[AL8]ref

[AL9]ref