ausgeführt am

unter der Anleitung von Univ. Doz. Dr. DI eva Kühn

durch

06.12.97

Namen sind in allen Bereichen notwendig, um Objekte eindeutig identifizieren zu können. Auch Computersysteme sind da keine Ausnahme. Dateien, Programme - alles wird über seinen Namen erkannt und angesprochen. Diese Namen müssen eindeutig sein, es darf also nicht zwei Objekte mit dem selben Namen geben.

Bisher hat man diesem Aspekt wenig Aufmerksamkeit geschenkt, da er bisher nicht wirklich ein Problem darstellte. Computer waren Einzelplatzsysteme, und die Anforderung, daß Namen eindeutig sein müssen, stellte kein größeres Problem dar. Man mußte nur darauf achten, daß auf dem "eigenen" Rechner keine Namenskonflikte auftraten.

Durch die Vernetzung von mindestens zwei Rechnern tritt bereits das Problem auf, daß zwei Objekte (beispielsweise Dateien) den selben Namen haben können, aber von allen verbundenen Rechnern eindeutig identifiziert werden müssen. Während man dieses Problem bei einigen wenigen Rechnern vielleicht noch relativ einfach lösen kann, wird durch die fortschreitende Vernetzung mit immer mehr Rechnern das Problem immer unüberschaubarer. Es ergibt sich die Notwendigkeit, Methoden zu finden, mit denen das Namensgebungsproblem systematisch gelöst werden kann.

Bei der Entwicklung verteilter Systeme wird heute das Namensgebungsproblem als ein wichtiges Teilproblem gesehen und es wurden mehrere Lösungsansätze erarbeitet. Die vorliegende Arbeit stellt einige Systeme wie beispielsweise CORBA [Omg] oder LINDA [CaGe89] vor, und legt dar, wie in diesen Systemen das Problem der globalen Namensgebung gelöst wurde.

Außerdem stellt die Arbeit ein System vor, welches am Institut für Computersprachen an der Technischen Universität Wien unter der Leitung von eva Kühn entwickelt worden ist: Der Koordinationskernel (CoKe). Es handelt sich dabei um ein plattform- und sprachunabhängiges System, welches zur Kommunikation von Softwaresystemen über gemeinsame Objekte dient. Es wird die Funktionsweise des CoKe erklärt und kurz auf die Art der Namensgebung von CoKe eingegangen.

Das mit Sicherheit größte Computernetzwerk der Welt ist das Internet. Es ist ein Netzwerk von Millionen von Rechnern. Die Zahl der im Internet verbundenen Rechner steigt derart schnell an, daß es sinnlos wäre, hier eine konkrete Zahl zu nennen. Natürlich muß auch im Internet jedes Objekt (HTML-Seiten, Bilder, Dateien…) eindeutig von jedem im Internet befindlichen Rechner angesprochen werden können. Es muß also einen Namen haben, welcher nicht nur in einem lokalen Netzwerk, sondern weltweit eindeutig ist.

Ein bedeutendes Problem bei der Namensgebung ist die Tatsache, daß Namen oft eng mit dem physischen Ort des benannten Objektes verknüpft sind (z. B. Pfad einer Datei in einem Dateisystem). Wenn sich der Ort, an dem sich das Objekt befindet, ändert, ändert sich auch der Name des Objektes. Das heißt also, der alte Name ist nicht mehr korrekt.

In kleineren Systemen ist die Wahrscheinlichkeit, daß ein Objekt von einem Ort an den anderen verschoben wird, eher gering. Je größer das System aber wird, umso eher entsteht die Notwendigkeit, Objekte von einem Teil des Netzes an einen anderen zu verschieben. (Etwa um das System neu zu strukturieren, oder Daten auf neue Ressourcen auszulagern, um ein überlastetes System zu entlasten.)

In einem System mit vielen Millionen Objekten wie dem Internet vergeht wohl kaum eine Minute, ohne daß ein Name (also eine Adresse) ungültig wird. Jeder, der schon einmal im WorldWideWeb "gesurft" hat, kennt die Fehlermeldung: "Error 404 - Not found". Bestenfalls findet man einen Hinweis, daß die Seite ihre Adresse geändert hat, sodaß man einen Link anklicken kann, um zu den gewünschten Daten zu gelangen.

Wenn also eine Site im Internet ihre Adresse wechselt, wird sie von denen, die sie unter dem alten Namen suchen, nicht gefunden und - noch schlimmer - jede Referenz auf dieses Objekt muß geändert werden. Da das WorldWideWeb als Hypertextsystem aufgebaut ist, gibt es oft sehr viele Referenzen, sogenannte "Links" auf ein Objekt.

Dieser Zustand ist heute - in der "Pionierzeit" des Internet - vielleicht noch tragbar, mittel- und langfristig wird man aber Wege finden müssen, Objekte im Internet besser zu benennen, als mit dem physikalischen Ort ihrer Speicherung und dem entsprechenden Dateinamen.

Hier versucht diese Arbeit einzuhaken und stellt einen Ansatz vor, wie Objekte im Internet mit Hilfe des CoKe einfacher und effizienter benannt und angesprochen werden können. Ziel dieser Überlegung ist es, daß der Benutzer nicht mehr wissen muß, wo sich ein Objekt befindet, er muß nur noch den Namen des Objektes kennen.

Die Vorteile eines solchen Systems liegen auf der Hand: Zum ersten braucht sich der Benutzer nicht darum kümmern, wo die Daten, die er sucht, gespeichert sind und zum zweiten können Objekte ohne Probleme von einem Ort zum anderen verschoben werden, ohne daß alle Referenzen auf dieses Objekt geändert werden müssen.

Zunächst geht Kapitel 1 auf das Problem globaler Namensgebung in verteilten Systemen allgemein ein und gibt verschiedene Begriffsdefinitionen. Es zeigt Probleme auf, die sich in diesem Zusammenhang stellen. Kapitel 2 stellt einige bekannte existierende Systeme vor und beleuchtet diese unter dem Aspekt der Namensgebung.

Kapitel 3 geht auf die aktuelle Situation im Internet ein und beschreibt, wie Objekte im Internet referenziert werden. Im Kapitel 4 wird versucht, mit Hilfe des CoKe ein System globaler Benennung von Objekten des Internet zu realisieren, das die aktuellen Probleme der Namensgebung im Internet löst.

Abschließend wird das erarbeitete Modell auf seine Realisierbarkeit in der Praxis hin untersucht und ein Ausblick auf mögliche Erweiterungen und Verbesserungen in der Zukunft gegeben.

In der Literatur existiert einige Verwirrung um die Begriffe "verteilte Systeme" und "Computernetzwerke". Nach [Tan96] ist in einem verteilten System die Existenz von mehreren, autonomen Rechnern für den Benutzer transparent. In einem Netzwerk müssen sich Benutzer explizit auf einer Maschine anmelden und Aufgaben explizit auf anderen Rechnern starten. In dieser Arbeit werden die Begriffe "verteiltes System" und "Netzwerk" allerdings gleichwertig verwendet, da sich das Beschriebene auf beides bezieht.

Verteilte Systeme gewinnen immer mehr an Bedeutung. Durch die ständige Verbesserung der verwendeten Hardware und Software dringen Computernetzwerke in immer neue Bereiche vor. Anwendungen werden auf mehrere Rechner verteilt, um verteiltes Arbeiten - "Workflow" - zu ermöglichen. Paralleles Programmieren wird eingesetzt, um Aufgaben gleichzeitig von mehreren Rechnern lösen zu lassen.

Eine signifikante Charakteristik eines verteilten Systems ist die Art, wie Objekte in diesem System benannt werden. [CoPe83] Um etwa einzelne Dateien voneinander unterscheiden zu können und um aus einer Menge von Dateien eine bestimmte herausfinden zu können, muß es eine Möglichkeit geben, jede einzelne eindeutig zu identifizieren. Um diese Identifikation durchführen zu können, muß jeder Datei ein Name zuweisen werden. Dieser Name muß eindeutig sein, das bedeutet, es darf im System keinen Namen geben, der mehr als eine Datei benennt.

Dies gilt natürlich nicht nur für Dateien, sondern allgemein für Objekte, die in einem System identifiziert werden müssen. Jedes Objekt hat einen eindeutigen Namen, der es im gesamten System identifiziert. Eine weitere Anforderung an die Namensgebung in einem System ist es, daß der Name eines Objektes allen bekannt sein muß, die es brauchen.

Das impliziert, daß eine Namensänderung sofort allen, die sich auf das Objekt referenzieren, bekannt sein muß. Erfährt ein Benutzer oder ein Programm nicht von der Namensänderung, greift er oder es "ins Leere", das Objekt wird nicht gefunden. Dies ist auf den ersten Blick kein größeres Problem, da sich der Name, der einem Objekt einmal gegeben wurde, doch nicht so bald ändern sollte. Schließlich bleibt es ja im Prinzip immer das selbe Objekt.

Ein Problem entsteht aber vor allem dann, wenn der physikalische Ort der Speicherung des Objektes Teil seines Namens ist. Eine Datei in einem herkömmlichen Betriebssystem wird beispielsweise über den Pfad ihrer Speicherung im Dateisystem und ihrem eigentlichen Dateinamen benannt. Der Dateiname für sich alleine ist nicht zur eindeutigen Identifizierung der Datei ausreichend, da dieser in einem Dateisystem (in verschiedenen Verzeichnissen) mehrmals vorkommen kann. Die Forderung nach Eindeutigkeit würde dadurch verletzt.

Wenn nun der Ort der Speicherung des Objektes ein Teil des Objektnamens ist, so ändert sich dieser Name natürlich jedesmal, wenn das Objekt an einen anderen Ort verschoben wird. Damit muß aber jede Referenz auf das Objekt, welche natürlich den alten Namen enthält, entsprechend geändert werden. Wenn beim Entwurf eines Systems geplant ist, den Ort des Objektes als einen Teil des Objektnamens zu verwenden, ist also dafür zu sorgen, daß das Problem der Migration von Objekten gelöst wird.

Da dieses Problem wesentlich schwieriger und komplexer zu lösen ist, als von Anfang an einen Entwurf zu erstellen, in dem Objekte unabhängig von ihrem Ort benannt werden, kann man bei der Verwendung von Orten als Namensteilen eigentlich schon fast von einem Entwurfsfehler sprechen.

In kleineren Systemen tritt das Problem vielleicht nicht allzu sehr in den Vordergrund, da die Verschiebung von Objekten eher seltener vorkommen wird und die Referenzen auf das entsprechende Objekt schnell anzupassen sind. Umso größer ein System aber wird, umso größer wird auch dieses Problem.

Das Internet als größtes Computernetzwerk der Welt leidet natürlich besonders unter der Tatsache, daß jedes Objekt über den Ort seiner Speicherung angesprochen wird. Immer wieder entsteht die Notwendigkeit, Daten auf andere Rechner zu transferieren, in andere Verzeichnisse zu verschieben, oder einfach umzubenennen.

Wie bereits erwähnt, muß in einem System mit "Ortsnamen" jeder, der ein Objekt referenziert, von einer Änderung des Ortes des Objektes unterrichtet sein. Dies ist im Internet aber nicht möglich. Das WorldWideWeb (WWW) - der heute bedeutendste Dienst im Internet - ist von seinen Erfindern, Wissenschaftlern des Schweizer CERN, von Anfang an als Hypertextsystem ausgelegt worden.

Hypertext unterscheidet sich von linearem Text dadurch, daß er nicht von Anfang bis zum Schluß Seite für Seite, Kapitel für Kapitel durchgelesen werden muß, sondern sich im Text Verweise zu anderen Textstellen befinden, welche über diese angesprungen werden können. Dadurch ist es möglich, kreuz und quer durch einen Text zu navigieren, oder auch aus einem Text heraus in andere Texte zu "springen".

Im WWW sieht das so aus, daß diese Verweise ("Links") als Referenz auf eine Stelle im aktuellen Text oder auf eine andere Datei im Internet bestehen. Diese Datei wird natürlich über den Ort ihrer Speicherung benannt. Und zwar in zweifacher Hinsicht. Erstens mit der Internetadresse des Rechners, auf dem sich die Datei befindet, und zweitens mit einem Pfad im Dateisystem dieses Rechners.

Wenn sich nun einer der drei Namensteile (Rechner, Pfad, Dateiname) ändert, müßten sich alle Verweise auf diese Datei entsprechend ändern. Da es aber unter Umständen einige tausend solcher Verweise geben kann und es obendrein praktisch unmöglich ist, alle diese Verweise im WWW ausfindig zu machen, kann der Anforderung, daß alle Referenzen bei der Namensänderung angepaßt werden, nicht nachgekommen werden.

Auch kleinere Systeme als das Internet haben dieses Problem, und so gibt es bereits einige Systeme, die als "Middleware" zwischen Applikation und Betriebssystem "eingeschoben" werden, um unter anderem Ort, Migration (Verschiebung von Objekten), Zugriff und Darstellung der Daten zu verwalten.

Beispiele für Middlewaresysteme sind etwa CORBA (Common Object Request Broker Architecture), DCE oder CoKe. Jedes dieser Systeme arbeitet nach einem anderen Prinzip und bietet mehr oder weniger Middlewaredienste an. Sie alle lösen aber das Problem des Zugriffs auf alle Dateien des darunterliegenden Systems.

Was ist eigentlich ein Name? Laut [Gord95] ist ein Name eine symbolische Repräsentation eines "Dinges". Dieses Ding kann ein Objekt jeder Art oder eine auszuführende Aktion sein. Ein Ding kann mehrere Namen haben. Ein Name hat nur innerhalb eines bestimmten Namens-Kontext Gültigkeit.

Ein Namensraum (name space) ist die Menge aller möglichen Namen innerhalb eines bestimmten Kontexts. Eine Bindung (binding) ist die Abbildung eines bestimmten Namens in ein bestimmtes Ding. Innerhalb eines Kontext hat ein Name maximal eine Bindung.

Die Namensresolution wandelt einen Namen in das Ding um, das er repräsentiert. Ein strukturierter Name ist ein Name, der durch Kombination des Namens eines Kontext mit dem Namen eines Dinges in diesem Kontext entsteht. Ein Beispiel für letzteres ist ein Dateiname, der aus Pfad und Dateiname besteht, oder der DNS-Name (Domain Name System) eines Internetrechners, der aus Domänenname und Rechnername zusammengesetzt ist.

Der "Name eines Kontext" kann natürlich wieder ein strukturierter Name sein, also wieder ein Kontextname mit einem Ding in diesem Kontext. Also beispielsweise der Name einer Domäne und der Name einer Subdomäne in dieser Domäne. Ein weiteres Beispiel für strukturierte Namen ist das UNIX-Kommando rcp (remote copy), welches Argumente in der Form: hostname:such/pfad/datei.name erwartet. Der Hostname ist der Name des Kontexts, in dem der Name der Datei gültig ist.

Der Vorteil, strukturierte Namen zu verwenden liegt auf der Hand: Dadurch, daß zuerst der Kontext des Namens gegeben ist, und dann der Name innerhalb dieses Kontexts, braucht man nur auf Namenskonflikte innerhalb des jeweiligen Kontexts zu achten. In verschiedenen Kontexten kann ein und der selbe Name mehrmals vorkommen.

Natürlich muß auf der anderen Seite darauf geachtet werden, daß bei den Kontextnamen keine Konflikte auftreten. Das gilt aber wieder nur innerhalb des unmittelbar übergeordneten Kontexts. So ergibt sich eine Art Baumstruktur, ähnlich der Verzeichnisstruktur in Dateisystemen. Genaugenommen ist ein Dateisystem, das mit Verzeichnissen und Unterverzeichnissen organisiert ist, ein Beispiel dieser Art der Namensgebung.

Durch strukturierte Namen können Namenskonflikte also "lokal" (d. h. innerhalb der jeweiligen Domäne) gelöst werden, dafür ergibt sich der Mehraufwand der Domänenverwaltung. Die Alternative dazu, unstrukturierte Namen, erfordern eine "zentrale" Lösung von Namenskonflikten. Das bedeutet, daß darauf geachtet werden muß, daß ein und der selbe Name im gesamten System nur ein einziges Mal vorkommt.

Dies ist klarerweise nur für sehr kleine Systeme machbar. Bei größeren Systemen ist es unmöglich, vor jeder Namensgebung zu überprüfen, ob der Name irgendwo im System schon einmal vorkommt. Im Internet wird, wie schon erwähnt, ausgiebig Gebrauch von strukturierten Namen gemacht. Grundsätzlich unterteilt sich der Name einer Datei in den Namen des Rechners, auf dem die Datei liegt, und in den Namen der Datei auf diesem Rechner.

Der Dateiname hält sich im Prinzip an die Konventionen der gängigsten Betriebssysteme wie UNIX oder DOS. Von einem Hauptverzeichnis an werden alle Verzeichnisse und Unterverzeichnisse angegeben, in der sich die Datei befindet (also der "Pfad" der Datei), schließlich noch der Name der Datei selbst.

Zu erwähnen ist auch noch, daß das Hauptverzeichnis nicht das Hauptverzeichnis des Dateisystems des betreffenden Rechners sein muß. Es kann sich um ein beliebiges Verzeichnis innerhalb des Dateisystems handeln. Dies ist für den Benutzer transparent.

Der Rechnername wiederum unterteilt sich in den Domänennamen und den eigentlichen Rechnernamen. Aufgrund der riesigen Anzahl von Rechnern im Internet reicht ein einfacher Domänenname nicht aus, sodaß der Domänenname zusätzlich in den Namen einer übergeordneten Domäne und den eigentlichen Domänennamen unterteilt ist.

Diese Unterteilung kann theoretisch beliebig lange fortgeführt werden. In der Praxis findet man oft Rechnernamen, die aus fünf oder sechs Teilen bestehen. Untenstehend ein Beispiel für einen Rechnernamen im Domain Name System des Internet.

Die Zusammensetzungsordnung (order of composition) [CABT] bei DNS-Namen ist von rechts nach links. Das bedeutet, daß die oberste Domäne ganz rechts steht, und die Subdomänen jeweils links angefügt werden. Ein Beispiel für eine Zusammensetzungsordnung von links nach rechts wäre das Dateisystem von UNIX oder DOS oder die Namen von Newsgruppen im USENET. Als "Separator" [CABT] zwischen den einzelnen Komponenten des DNS-Namens im Internet dient der Punkt.

Der zweite Teil des Namens einer Datei im Internet, der eigentliche Dateiname auf dem jeweiligen Rechner, wird einfach an die Adresse des Rechners angefügt. (Siehe untenstehendes Beispiel).

Wie bereits gesagt, darf ein Name immer nur ein einziges Objekt benennen, ein Objekt kann aber durchaus mehrere verschiedene Namen haben. Es wird trotzdem durch jeden einzelnen dieser Namen eindeutig identifiziert. Auch im Internet ist es durchaus üblich, einem Rechner mehrere DNS-Namen zuzuweisen.

Dies kann aus mehreren Gründen sinnvoll sein. Z. B. wenn ein Rechner für mehrere verschiedene Dienste im Internet herangezogen wird (Webserver und FTP-Server, Mailserver und Webserver…). Ein anderer Grund kann sein, daß beispielsweise ein Webserver von mehreren Benutzern verwendet wird, die den Server alle unter einem eigenen Namen benutzen wollen (z. B. Firmen, die ihre Webseiten unter einem eigenen Servernamen präsentieren wollen). Dies geschieht durch die Errichtung von mehreren "virtuellen Servern" auf einem physischen Server.

Genaugenommen wird ein Rechner, der mehrere DNS-Namen besitzt, nicht immer unter mehreren verschiedenen Namen angesprochen. Das Internet verwaltet die einzelnen Rechner nämlich nicht mit ihrem DNS-Namen, sondern mit einer 32 Bit großen Nummer. Nur bei Errichtung eines "virtuellen Servers" bekommt ein Rechner auch mehrere Nummern zugewiesen. Ansonsten werden die verschiedenen DNS-Namen auf ein und dieselbe Nummer abgebildet.

Das DNS (Domain Name System) ist eigentlich nur eine Schnittstelle zwischen dem Internetprotokoll und dem Benutzer, da man es den Benutzern nicht zumuten will, Destinationen im Internet mit 32-bit-Zahlen anzusprechen, und sich diese Zahlen vielleicht auch noch zu merken. Auf die Adressierung der Rechner mit ihren Nummern durch das IP (Internet-Protokoll) wird in Kapitel 3 noch näher eingegangen.

Wie bereit oben erwähnt, ist es meist üblich, daß der Pfad einer Datei auf einem Webserver, wie er in der Internetadresse angegeben wird, nicht exakt dem Pfad dieser Datei im Dateisystem des Servers entspricht. Bei der Konfiguration des Webservers wird festgelegt, welches Verzeichnis innerhalb des Dateisystems jenes Verzeichnis ist, welches von außen als Hauptverzeichnis gesehen werden soll. Dies kann durchaus ein Verzeichnis sein, das "sehr weit entfernt" vom Hauptverzeichnis des Server-Dateisystems ist.

Der Pfad einer Internetdatei, der von außen angegeben wird, ist dann relativ von diesem Verzeichnis aus zu sehen. Man spricht deshalb von "relativer Benennung". Diese Art der Benennung ist schon lange in Betriebssystemen üblich. In der Kommandozeile des jeweiligen Befehlsinterpreters angegebene Dateinamen werden relativ zum momentan "aktiven" Verzeichnis gesehen.

Auch bei den Hypertext-Verweisen innerhalb einer HTML-Datei oder diversen Quellenangaben in diesen Dateien (Bilder etc.) kann eine relative Benennung verwendet werden. Das Ziel des Verweises oder die angegebene Quelle werden relativ vom Standort der betreffenden Datei gesucht.

Das Gegenteil von relativer Benennung ist absolute Benennung. Das bedeutet, daß alle benannten Objekte mit ihrem absoluten Pfad von einem bestimmten Hauptverzeichnis an gesehen angesprochen werden müssen. Dies hat den Nachteil mangelnder Flexibilität - z. B. bei Migration des gesamten Subsystems. Der Vorteil ist, daß Mißverständnisse und Zweideutigkeiten ausgeschlossen werden.

Beim Entwurf eines Systems sollte daher darauf geachtet werden, ob relative oder absolute Benennung verwendet wird, da eine Fehlentscheidung unter Umständen große Kosten nach sich ziehen könnte. Man stelle sich nur ein System vor, das absolute Benennung verwendet, in dem öfters ganze Subsysteme von einem Ort zum anderen verschoben werden müssen.

Seit man begonnen hat, Applikationen nicht nur auf Einzelplatzsystemen zu betreiben, sondern sie auf mehrere Rechner aufzuteilen, d. h. verteilte Systeme zu errichten, stellt sich das Problem der globalen Namensgebung in diesen Systemen. In vielen Systemen sind zum Problem der Namensgebung verschiedene Lösungen entwickelt und eingesetzt worden.

Dieses Kapitel soll einige dieser Systeme kurz vorstellen und näher darauf eingehen, wie das Problem globaler Namensgebung in diesen Systemen gelöst wird. Einige der vorgestellten Systeme sind Middleware-Systeme, also Softwaresysteme, die zwischen Anwendung und Betriebssystem liegen.

Im Jahre 1989 wurde von den Firmen 3Com Corporation, American Airlines, Canon Inc, Data General, Hewlett-Packard Company, Sun Microsystems und Unisys Corporation die Object Management Group (OMG) ins Leben gerufen. Ziel dieses Konsortiums war, eine Referenzarchitektur für verteilte, objektorientierte Systeme zu finden, dessen Schwerpunkte in der Interoperabilität, Wiederverwendbarkeit und Portabilität von Software-Komponenten liegen. [Boe96]

Mit der Veröffentlichung der Object Management Architecture (OMA) legten sie die Grundlage dieser Architektur, zu dessen Besonderheiten gehört, daß Objekte in Anwendungen eingebunden werden können, ohne über deren Aufenthaltsort im Netzwerk oder deren Realisierung - wie z. B. die Programmiersprache - Kenntnis zu haben.

Kernstück dieser Architektur ist der Object Request Broker (ORB), der als Vermittlungszentrale zwischen den Objekten dient. Er nimmt die Anfragen an Objekte entgegen, lokalisiert das Objekt und übermittelt die Anfrage sowie das Ergebnis der Operation.

Der ORB ist standardisiert worden unter dem Namen Common Object Request Broker Architecture (CORBA). Mit der zuletzt vorgestellten Spezifikation CORBA 2.0 wurde ein Standard für die Kommunikation zwischen Systemen verschiedener Hersteller auf heterogenen Plattformen definiert. Damit ist es möglich, daß Anwendungen auf Server-Dienste fremder Software-Hersteller zugreifen, die unter unterschiedlichen Betriebssystemen arbeiten.

CORBA stellt also eine Infrastruktur zur Verfügung, die es Objekten erlaubt, zu kommunizieren, unabhängig von der spezifischen Plattform und von Implementationstechniken der Objekte. Die Erfüllung des Object Request Broker-Standards garantiert die Portabilität und Interoperabilität von Objekten über ein Netzwerk heterogener Systeme. [Cha96]

Um die Portabilität über System- und Sprachgrenzen hinweg zu gewährleisten, wurde eine eigene Definitionssprache - die "Interface Definition Language" (IDL) eingeführt. IDL ist eine deskriptive Sprache, die syntaktisch auf C++ aufbaut. Die Syntax von IDL ist eine Untermenge der C++ - Syntax. Sie unterstützt Deklarationen von Konstanten, Typen und Operationen. IDL enthält aber keine prozeduralen Strukturen oder Variablen.

Mit den Object Services sind Komponenten zur Steuerung der Lebenszyklen von Objekten standardisiert. Dazu gehören Schnittstellen zum Erzeugen, Kopieren, Verschieben und Zerstören von Objekten sowie zur Zugriffskontrolle. Ebenso sind ein Persistenzdienst, der das Speichern von Objekten auf externen Speichermedien beschreibt, sowie ein Ereignismeldungsservice für die asynchrone Meldung von Ereignissen definiert.

Ein weiterer Service ist der Namensgebungsdienst (Naming Service). Der Naming Service wird gebraucht, um bequemen Zugriff auf existierende Objekte zu gewähren, die im gesamten Netzwerk verteilt sein können. Nachdem ein Objekt erstellt wurde, kann es in einem Kontext innerhalb des Naming Service registriert ("gebunden") werden, sodaß Clients diese Objekte lokalisieren können, indem sie einfache Zeichenketten verwenden. Dies sind nur einige Beispiele für CORBA-Object Services.

CORBA löst das Problem des Ortes und der Migration von Objekten. Der physikalische Ort, an dem sich ein Objekt befindet, wird vom Benutzer abgeschirmt, d. h. er ist für ihn transparent. Bei Migration eines Objektes, also der Änderung dieses physikalischen Ortes, entsteht nicht die Notwendigkeit einer Namensänderung, da durch die Abschirmung des Ortes des Objektes dieser nicht Teil des Objektnamens ist.

Ebenfalls abgeschirmt wird die Art des Zugriffs auf ein Objekt. Es gibt in der Art des Zugriffs keinen Unterschied zwischen lokalen und entfernten Objekten. Weiters schirmt CORBA die Darstellung der Daten in den unterschiedlichen Systemen ab. All diese Dienste sind wichtige Anforderungen, die an Middlewaresysteme gestellt werden.

Die Architektur von CORBA gliedert sich in vier fundamentale Bereiche ("boundaries"). Dem ganzen System zugrunde liegt ein globaler Bus, der Object Request Broker (ORB) genannt wird. Dieser Bus läßt Objekte transparent mit anderen Objekten Kontakt aufnehmen, egal ob lokal oder über ein Netzwerk.

Auf diesen Bus setzen die "CORBA Object Services" auf, welche Sammlungen von Systemdiensten sind, die dem System als Komponenten zur Verfügung stehen. Den nächsten Bereich bilden die "Common Facilities". Diese definieren Richtlinien, die den "Business Objects" - dem vierten Bereich - die effektive Zusammenarbeit ermöglichen.

Ein CORBA 2.0 - Object Request Broker (ORB) ist jene Middleware, die Client/Server Beziehungen zwischen Objekten herstellt. Unter Verwendung eines ORB, kann ein Client-Objekt transparent eine Methode auf einem Server-Objekt aufrufen, egal ob es sich auf der selben Maschine oder irgendwo im Netzwerk befindet. [COR95]

CORBA-ORBs stellen für ihre Dienste sowohl statische als auch dynamische Schnittstellen zur Verfügung. Statische Schnittstellen sind schneller und einfacher zu programmieren als dynamische, während man mit dynamischen Schnittstellen den Vorteil wesentlich größerer Flexibilität hat. Diese beiden Ansätze trafen ursprünglich als konkurrierende Lösungsansätze bei der OMG ein. Da man die Vorteile beider Ansätze erkannt hat, hat man bei der OMG beide zum Standard erhoben.

Objekte werden innerhalb eines ORB-Systems mittels einer Referenz eindeutig spezifiziert. Diese Referenz ist ein eindeutiger Name oder eine eindeutige Bezeichnung. Da die Implementation von Objektreferenzen in der CORBA-Spezifikation nicht definiert ist, ist sie implementationsspezifisch. Dies ist natürlich ein Hindernis für die Inter-ORB-Kommunikation, also die Kommunikation zwischen mehreren ORBs von verschiedenen Herstellern.

In der Version 2.0 definiert CORBA daher "Interoperable Object References" (IOR), die Hersteller benutzen müssen, um Objektreferenzen über heterogene ORBs zu schicken. Dies passiert durch Verwendung von "Language Bindings". Alle ORBs stellen das selbe language-binding für eine bestimmte Programmiersprache zur Verfügung. Objektreferenzen können als Text verschickt oder ausgetauscht werden. Zur Konvertierung einer Referenz in einen Text und umgekehrt stellt der ORB die Funktionen object_to_string bzw. string_to_object zur Verfügung.

CORBA 2.0 unterstützt aber auch darüber hinausgehend die Interoperabilität (heterogener) ORBs. Dafür wurden drei verschiedene Protokolle definiert:

Das "General Inter-ORB Protocol" (GIOP) stellt Nachrichtenformate und Datenstrukturen zur Kommunikation zwischen ORBs zur Verfügung. GIOP arbeitet direkt auf jedem verbindungsorientierten Transportprotokoll. Dieses Protokoll ist speziell für Verbindungen zwischen ORBs erstellt und nimmt dem Benutzer auch Aufgaben wie Byte-Anordnung oder Speicherausrichtung (memory alignment) ab.

Das "Internet Inter-ORB Protocol" (IIOP) bietet die Möglichkeit, Inter-ORB-Verbindungen über das TCP/IP Protokoll des Internets abzuwickeln. Dadurch kann das gesamte Internet als Backbone für Inter-ORB-Verbindungen verwendet werden. IIOP spezifiziert, wie GIOP-Nachrichten über ein TCP/IP-Netzwerk übertragen werden sollen.

Die "Environment-Specific Inter-ORB Protocols" (ESIOPs), also umgebungsspezifische Inter-ORB Protokolle, ermöglichen die Interoperation von ORBs über spezifische Netzwerke. Ein Beispiel eines ESIOPs ist DCE/ESIOP, also ein auf DCE basierendes Protokoll.

Der Object Request Broker besitzt die wichtigsten Mechanismen, die zur Kommunikation von Objekten benötigt werden, allerdings fehlen einige wichtige Dienste, die eine sinnvolle und flexible Kommunikation ermöglichen. Deshalb setzen die "Object Services" auf den ORB auf, um dessen Funktionalität zu erhöhen.

Einige der wichtigsten Object-Services sind:

• Life Cycle - Operationen zum Erstellen, Kopieren, Verschieben und Löschen von Objekten
• Persistence - persistentes Speichern von Objekten in Datenbanken oder Dateien
• Naming - Namensgebung (siehe weiter unten)
• Event - Objekte, die nichts voneinander wissen, können über Event-channels miteinander kommunizieren
• Transaction - Transaktionen mit Zwei-Phasen Kommit
• Concurrency - stellt einen Lock-Manager zur Verfügung

Es existieren noch etwa zehn weitere Object-Services, auf die hier aber nicht näher eingegangen werden soll.

Die Object Services sind es, die CORBA erst zu einem Middlewaresystem machen, da sie jene Funktionalität zur Verfügung stellen, die von Middleware verlangt wird. Die Funktionen der Object Services können in eigene Objekte übernommen werden, indem auf die Technik der mehrfachen Vererbung (multiple inheritance) zurückgegriffen wird. Die eigenen Objekte werden dann einfach von all jenen Objekten abgeleitet, die die benötigten Dienste bieten.

Die Common Facilities bieten Komponenten, die Dienste zur Verfügung stellen, welche direkt von den Anwendungsobjekten benutzt werden können. Diese Komponenten sind in IDL - der Definitonssprache von CORBA - definiert. Die Common Facilities werden unterteilt in horizontale und vertikale Facilities.

Horizontale Facilities sind beispielsweise User-Interface, Informations-Management, System-Management oder Task-Management. Vertikale Facilities stellen in IDL definierte Schnittstellen für verschiedene Marktsegmente bzw. Branchen zur Verfügung.

Business Objects oder Application Objects (Anwendungsobjekte) sind Objekte, die spezifisch für die jeweilige Anwendung sind. Auch diese Objekte werden in IDL definiert. Business Objects bilden über den Common Facilities, den Object-Services und dem ORB die Spitze der CORBA-Architektur.

CORBA ist ein selbstbeschreibendes (self-descripting) System. Die Komponenten und die zur Verfügung stehenden Schnittstellen eines Serverobjektes werden für die potentiellen Clientobjekte beschrieben. Dazu wird eine eigene Beschreibungssprache verwendet: Die Interface Definition Language (IDL).

IDL wird auch zur allgemeinen Definition von Objekten verwendet. Diese IDL-Definition wird von einem Precompiler in sprachspezifische "skeletons" übersetzt, die vom Programmierer um den Programmcode erweitert werden müssen. Wie sieht nun diese Interface Definition Language aus?

Wie bereits erwähnt, ist IDL eine deskriptive Sprache, d. h. sie unterstützt keine prozeduralen Strukturen. Die Grammatik von IDL ist eine Untermenge der Grammatik von C++, die um zusätzliche Schlüsselwörter erweitert wurde, um verteilte Konzepte zu realisieren.

module Fuhrpark
{
interface Auto:Fahrzeug, Motor
{
attribute string Marke;
attribute integer Kilometerstand;
void starten();
void fahren(in string wohin);
void hupen(in integer wielange);
void stoppen();
}

interface Fahrrad:Fahrzeug
{
attribute string Marke;
void fahren(in string wohin);
void klingeln(in integer wieoft);
}
}

Diese IDL-Datei definiert ein Modul mit den zwei Klassen (Interfaces) Auto und Fahrrad. Dabei wird die Klasse Auto von den Klassen Fahrzeug und Motor abgeleitet (mehrfache Vererbung), die Klasse Fahrrad nur von Fahrzeug. Für jede Klasse werden zusätzlich Attribute und Methoden (bzw. Operationen) definiert.

CORBA identifiziert Objekte über eine Objektreferenz. Bei einer solchen Referenz kann aber sicher nicht von einem Namen gesprochen werden, obwohl es möglich ist, mittels Methoden des ORB Referenzen in Text-Strings umzuwandeln und vice versa. Um einem Objekt einen Namen zuzuweisen, bedient man sich des Naming-Services der CORBA Object Services.

Der Naming-Service setzt lesbare Namen in Objektreferenzen um. Eine Zuordung von Namen zu Objekten wird als name-binding bezeichnet. Der Naming-Service von CORBA unterstützt hierarchische Namens-Kontexte, in welchen Namen eindeutig sind. Mit Hilfe von Namenskontexten können verbundene Naming-Services (federated naming services) für Objekte erstellt werden. Dadurch können zusammengesetzte Namen erzeugt werden.

Der CORBA Naming Service bietet zwei Interfaces: NamingContext und BindingIterator. NamingContext stellt alle Methoden zur Verfügung, die notwendig sind, um eine Objektreferenz an einen Namen zu binden. Mit Hilfe der Methoden bind und unbind kann ein Objekt an einen "binding context" gebunden werden. Mit der resolve - Methode kann ein benanntes Objekt gefunden werden. Die list - Methode liefert ein BindingIterator-Objekt zurück, mit Hilfe dessen durch eine Liste von Namen iteriert werden kann.

Im obigen Java-Beispiel wird ein Naming-Kontext namens staff angelegt und in diesem Kontext wird ein Objekt namens john gebunden. Danach wird das Objekt wieder über den Naming Service geholt und ausgegeben.

Die Migration von Objekten wird mit Hilfe des Object Services "Life Cycle" durchgeführt. Dieses Service bietet die drei wichtigen Methoden copy, move und remove. Mit Hilfe dieser Methoden können neue Objekte generiert (copy), verschoben (move) oder wieder gelöscht (remove) werden.

CORBA ist ein System, das auf dem Prinzip des "Message Passing" (Nachrichten schicken) beruht. Sämtliche Kommunikation wird durch das Senden von Nachrichten ("messages") abgewickelt. Für jede Aktion sendet ein Prozeß einen Request an einen Partnerprozeß und dieser antwortet darauf mit einer Bestätigung.

Ein anderes Paradigma ist die Verwendung von gemeinsamen Objekten ("Shared Objects"). Der Informationsaustausch zwischen den einzelnen Prozessen des verteilten Systems wird dabei nicht über Nachrichten, die zwischen den Prozessen hin und her geschickt werden, abgewickelt, sondern über Kommunikationsobjekte, die in einem gemeinsamen Speicherbereich liegen.

Diese Art der Kommunikation ist verwandt mit dem "Shared Memory" (gemeinsamer Speicher), das oft zur Kommunikation zwischen Prozessen auf einer einzigen Maschine verwendet wird. Bei verteilten Systemen ist der gemeinsame Speicherbereich auf mehrere Rechner verteilt und es wird nicht auf Adressen, sondern auf Datenstrukturen - die Objekte - über ihre Namen zugegriffen.

Diese Art der Kommunikation eignet sich besonders für Multicast-Anwendungen, also Anwendungen, wo eine Information von einer Quelle zu mehreren Empfängern gehen soll, und in Systemen, in denen der (die) Empfänger der Information der Informationsquelle nicht bekannt sind. Eine Nachricht muß an einen genau spezifizierten Empfänger gehen, ein Objekt in einem gemeinsamen Speicherbereich nicht. Das nennt man auch anonyme Kommunikation.

Dadurch, daß der "Versender" einer Information die Empfänger der Information nicht kennen muß, lassen sich die einzelnen Komponenten eines verteilten Systems weitgehend unabhängig voneinander entwickeln. Es muß nur die Informationsschnittstelle spezifiziert werden, also die zur Kommunikation verwendeten Objekte.

Ein weiterer Vorteil der Kommunikation über gemeinsame Objekte ist die Persistenz der Kommunikationsdaten. Während die Daten bei geschickten Nachrichten transient sind und nach der Übermittlung nicht mehr erreichbar sind, bleiben die Daten in Kommunikationsobjekten, die in einem gemeinsamen Speicherbereich liegen, solange erhalten, bis sie dezidiert gelöscht werden oder nicht mehr benötigt und dann automatisch entfernt werden (Garbage Collection).

Hier wird nun ein System vorgestellt, das verteilte Objekte und RPC (remote procedure calls) verwendet und danach zwei Systeme, die die Kommunikation über gemeinsame Kommunikationsobjekte abwickeln: LINDA und CoKe. Alle Systeme werden kurz charakterisiert und auf den Aspekt der Namensgebung hin untersucht.

Arjuna ist ein objektorientiertes Programmiersystem, das an der Universität von Newcastle upon Tyne entwickelt worden ist [ARJ1]. Arjuna wurde entwickelt, um es dem Programmierer von verläßlichen, verteilten Anwendungen, zu ermöglichen, sich auf die Funktionalität seiner Anwendung zu konzentrieren, ohne sich mit den diversen Problemen, die sich aus der Verteilung der Anwendung ergeben, herumschlagen zu müssen.

Arjuna stellt zu diesem Zweck eine Anzahl an Werkzeugen zur Verfügung, die auf diese wohlbekannten Probleme Rücksicht nehmen (z. B. Unterschiede in den Maschinenarchitekturen, Sicherstellung von Konsistenz trotz Maschinenausfalls). Arjuna unterstützt die Persistenz, Wiederherstellbarkeit (recoverability) und concurrency control von Objekten. Außerdem existieren Systemkomponenten, die Transaktionen (die "atomic actions" genannt werden), Clustering, Replikation und Distribution ermöglichen.

Arjuna ist komplett in C++ implementiert. Das System stellt dem Programmierer von fehlertoleranten, verteilten Anwendungen seine Dienste in Form von C++ - Objekten zur Verfügung, deren Funktionalität er durch den Mechanismus der Vererbung (inheritance) in seine eigenen Objekte übernehmen kann. Diese Tatsache impliziert natürlich, daß ausschließlich Programme, die ihrerseits in C++ geschrieben sind, mit Arjuna zusammenarbeiten können.

Arjuna realisiert verteilte Anwendungen, indem es Mechanismen zur Verfügung stellt, die es Objekten erlauben, mittels RPC (remote procedure calls) miteinander zu kommunizieren. Dadurch wird das klassische Client/Server - Modell realisiert. Ein Objekt (Client) sendet einen Request an ein entferntes Objekt (Server) und ruft damit eine Methode dieses Objektes auf. Mit dem Request werden auch die Parameter für den Methodenaufruf gesendet. Die Methode wird daraufhin ausgeführt und die Resultate werden schließlich an den Client zurückgeschickt.

Persistente Arjuna-Objekte besitzen entweder einen aktiven oder passiven Status. Im aktiven Status befinden sich die Objekte im Hauptspeicher des Rechners und können dort manipuliert werden. Ein Objekt bleibt im aktiven Status, bis es passiv gemacht wird. Dann befindet es sich in einem nicht flüchtigen Speicher, dem sogenannten Objektspeicher (object store). Passive Objekte können wieder aktiviert werden, wodurch das Objekt wieder in den Hauptspeicher geladen wird. Arjuna stellt zu diesen Zwecken die Funktionen save_state und restore_state zur Verfügung.

Um persistente Objekte zu erzeugen, muß der Programmierer seine Objekte von der Arjuna-Klasse ObjectState ableiten. Durch den Vererbungsmechanismus von C++ stehen den neuen Objekten damit alle Methoden dieses Objektes zur Verfügung. save_state und restore_state sind beispielsweise zwei dieser Methoden.

Um den Programmierer bei der Abwicklung der RPC-Aufrufe zu unterstützen, generiert Arjuna sogenannte "Stubs". Diese Stubs stellen eine Schnittstelle für den Programmierer dar, die er in seinem Code benutzen kann. Dadurch kann ein entfernter Funktionsaufruf wie ein lokaler Funktionsaufruf durchgeführt werden. Die Tatsache, daß die Funktion nicht lokal aufgerufen wird, wird dadurch für den Programmierer transparent.

Um diese Stubs zu generieren, müssen die Objekte einen "stub-generator" durchlaufen. Dieser Generator liest die Objekte ein und generiert den Stub-Code, der für die Verwendung dieser Objekte in einem verteilten System notwendig ist. Der Generator speichert den geänderten Code in eigenen Dateien, die dann zum Übersetzen des Programmes verwendet werden.

Transaktionen ("atomic actions") werden in Arjuna von einer Klasse namens AtomicAction zur Verfügung gestellt. Um eine Transaktion zu starten, wird eine Instanz von AtomicAction erzeugt. Diese stellt die drei Methoden Begin(), End() und Abort() zur Verfügung. Mit Begin() wird eine neue Transaktion gestartet. Danach werden die Befehle innerhalb der Transaktion durchgeführt. Mit End() wird die Transaktion korrekt beendet (Commitment). Abort() bricht die Transaktion ab, und alle Änderungen seit dem Aufruf von Begin() werden rückgängig gemacht (Rollback).

Arjuna unterstützt geschachtelte Transaktionen. Das bedeutet, daß innerhalb einer Transaktion weitere Transaktionen gestartet werden können. Dies erlaubt den modularen Aufbau von Programmen und erhöht die Flexibilität bei der Implementierung von fehlertoleranten Applikationen.

Um Concurrency Control zu unterstützen, gibt es in Arjuna die Klasse LockManager. LockManager stellt die Methoden setlock und releaselock zur Verfügung. Mit Hilfe dieser Methoden kann der Zugriff auf kritische Ressourcen (z. B. der Schreibzugriff auf ein Objekt) dahingehend kontrolliert werden, daß immer nur ein Prozeß auf diese Ressourcen zugreifen kann. Da LockManager von StateManager abgeleitet ist, können Klassen, die von dieser Klasse abgeleitet werden, auch auf alle Methoden von StateManager zugreifen.

Mit dem Aufruf von setlock wird der Zugriff anderer Prozesse auf das entsprechende Objekt verweigert. Erst wenn diese Blockierung mit releaselock wieder aufgehoben wird, haben andere wieder Zugriff auf das Objekt. Beim Aufruf von setlock muß angegeben werden, ob es sich um die Blockierung des Schreib- oder des Lesezugriffes handelt.

Beispiel:
Persistente Arjuna-Klasse, die Transaktionen und Concurrency Control verwendet

class IntContainer : public LockManager
{
public:
IntContainer(int value);
~IntContainer();

void set(int value);
void get(int& value);

virtual Boolean save_state(ObjectState&, ObjectType);
virtual Boolean restore_state(ObjectState&, ObjectType);

private:
int wert;
}

IntContainer::IntContainer(int value) : LockManager()
{ wert = value; }

IntContainer::~IntContainer() : ~LockManager() {}

IntContainer::set(int value)
{
AtomicAction act;

act.Begin();
if (setlock(new Lock(WRITE), 0) == GRANTED)
{
wert = value;
act.End();
}
else act.Abort();
}

IntContainer::get(int& value) { value = wert; }

Boolean IntContainer::save_state(ObjectState& os, ObjectType)
{ return os.pack(wert); }

Boolean IntContainer::restore_state(ObjectState& os,
ObjectType)
{ return os.unpack(value); }

Dieses Beispiel zeigt eine sehr einfache C++ - Klasse, die einfach nur einen Integer-Wert speichert. Sie stellt zwei Methoden zur Verfügung, mit denen dieser Wert verändert und ausgelesen werden kann. Außerdem sind ein Konstruktor und ein Destruktor definiert. Mit Hilfe des Parameters setzt der Konstruktor einen initialen Wert.

Weiters sind noch die Methoden save_state und restore_state definiert. Diese beiden virtuellen Methoden aus der Mutter-Klasse StateManager werden hier überschrieben. Sie definieren, wie der Status eines Objektes dieser Klasse auf den persistenten Objektspeicher geschrieben wird. Die verwendeten Methoden pack und unpack sind von StateManager ererbt.

Die Methode set zur Änderung des Integer-Wertes verwendet eine Transaktion (atomic action) und einen Lock, um sicherzustellen, daß es immer nur einen Schreiber geben kann. Im Parameter, der der Methode setlock übergeben wird, wird festgelegt, daß das Schreiben blockiert wird. Lesezugriff besteht damit weiterhin für alle. Wurde der Lock korrekt gesetzt, terminiert die Transaktion korrekt, ansonsten wird sie mit Abort abgebrochen.

Arjuna verwaltet die Objekte intern mit Hilfe von sogenannten "unique identifiers" (Uid). Eine Uid besteht aus vier 32-bit Zahlen, welche aus der Internetadresse jenes Rechners, auf dem das Objekt erstellt wurde, dem Erstellungszeitpunkt und dem Prozeß, der das Objekt erstellt hat, besteht. Die Uid wird in hexadezimaler Form angegeben.

Für diese Identifizierung stellt Arjuna die Klasse Uid zur Verfügung. Wenn ein existierendes Objekt vom Objektspeicher geladen werden soll, kann es über Angabe seiner Uid identifiziert werden. Instanzen der Klasse Uid können im Status eines persistenten Objektes gespeichert werden, indem von den Methoden pack und unpack dieser Klasse Gebrauch gemacht wird.

Beispiel:
Wiederherstellung eines persistenten Objektes mit Hilfe seiner Uid

...

public:
IntContainer(const Uid& u);
IntContainer(int wert);

...

IntContainer::IntContainer(const Uid& u) : LockManager(u)
{
StateManager::activate();
}

IntContainer::IntContainer(int value) : LockManager(ANDPERSISTENT)
{
wert = value;
}

In diesem Beispiel wird die Klasse IntContainer aus dem vorigen Beispiel um Persistenz erweitert. Es wird ein zusätzlicher Konstruktor definiert, dem die Uid des wiederherzustellenden Objektes übergeben wird. Dieser Konstruktor ruft den Konstruktor der Klasse LockManager auf aktiviert das entsprechende Objekt.

Der Konstruktor, der ein neues Objekt erzeugen soll, ruft den Konstruktor der Klasse LockManager mit dem Parameter ANDPERSISTENT auf, um anzuzeigen, daß es sich dabei um ein persistentes Objekt handelt. Nun ist es aber sicher nicht die benutzerfreundlichste Art, Objekte zu benennen, ihnen eine ID-Nummer zu geben. Damit Benutzer Objekte einfach ansprechen können, müssen andere Lösungen gefunden werden.

In Arjuna gibt es für diesen Zweck die Klasse ArjunaName. Diese Klasse bietet ein abstraktes Namensschema für persistente Arjuna-Klassen. ArjunaName stellt eine Schnittstelle zu einem Nameserver zur Verfügung, der es erlaubt, Namen von persistenten Arjuna-Objekten zu registrieren und nach diesen Namen zu suchen. Mit Hilfe dieser Klasse können Objekte mit einfachen String-Namen benannt werden.

In diesem Beispiel wird der Namensgebungsmechanismus von Arjuna verwendet. Die Konstruktoren sind entsprechend angepaßt, um Objekten bei der Erstellung Namen zu geben und sie bei der Reaktivierung über diesen Namen zu identifizieren. Dem Konstruktor für ein neues Objekt wird ein char* übergeben, der den Namen des neuen Objektes enthält. Im Konstruktor selbst wird eine Instanz der Klasse ArjunaName erzeugt, und dann die Register Methode dieser Instanz aufgerufen. Als Argumente werden der Methode der Name für das neue Objekt und ein Zeiger auf das Objekt (this) übergeben.

Dem Konstruktor für die Reaktivierung eines Objektes aus dem Objektspeicher wird das betreffende ArjunaName-Objekt übergeben und es wird der Konstruktor der Klasse LockManager aufgerufen. Diesem wird das Objekt übergeben, das mit der Methode GetRefObjUid von ArjunaName identifiziert wird. Am Ende wird noch gezeigt, wie eine Instanz dieser neuen Klasse erzeugt wird.

Arjuna verwendet Objekte nur bei der Programmierung, nicht zur Kommunikation. Für Kommunikationszwecke wird RPC (remote procedure call) verwendet. Im folgenden sollen nun zwei Systeme vorgestellt werden, die über gemeinsame Objekte kommunizieren: Linda und CoKe.

LINDA [CaGe89] ist ausgelegt als maschinenunabhängige Umgebung zur Implementierung von parallelen Codes [Bro96]. Zur Kommunikation zwischen parallelen Prozessen verwendet LINDA Datenelemente ("Tupel" genannt), die in einem Tupelraum (tuple space) genannten Bereich gespeichert werden.

LINDA stellt einige Operationen zur Verfügung, die in gängige Programmiersprachen wie C, Prolog oder FORTRAN eingebettet werden können. Diese Operationen dienen der Erstellung von Datenelementen (Tupeln) und Prozessen (live tuple). Mit LINDA kreierte Prozesse werden als sogenannte "Live Tupel" (aktive Tupel) in den Tupelraum gestellt und evaluieren dort nach der Abarbeitung zu (passiven) Datentupeln.

Kommunikation und Prozeßkreation sind also zwei Facetten der selben Operation. Um Prozesse zu kreieren werden "Live Tupel" generiert, die in Datentupel umgewandelt werden und um zu kommunizieren werden direkt Datentupel oder auch Live Tupel erzeugt. Jedes Tupel existiert unabhängig von dem Prozeß, der es erzeugt hat. Das heißt, jeder Prozeß, der Zugriff auf den Tupelraum hat, kann auf alle Tupel in diesem Tupelraum zugreifen, da sich die Tupel in einem "virtuellen gemeinsamen Speicher" befinden und mit keinem Prozeß assoziiert sind.

Dies hat den Vorteil großer Flexibilität, aber auch einige Nachteile wie die fehlende Möglichkeit, "fremden" Prozessen den Zugriff auf die Tupel zu verwehren, oder das Problem der Garbage Collection. Ein weiterer Vorteil von Linda ist die Sprachunabhängigkeit der Kommunikationsdatenstrukturen. So können beispielsweise Tupel, die in einem in C geschriebenen Programm erzeugt wurden, von einem in FORTRAN geschriebenen LINDA-Programm gelesen werden und vice versa.

Wie sehen nun diese LINDA-Tupel aus? Ein Tupel besteht aus einer Reihe von typisierten Feldern, die mit Beistrichen getrennt sind. Das untenstehende Beispiel zeigt ein LINDA-Tupel mit drei Elementen von verschiedenen Datentypen.

LINDA stellt die wichtigsten Operationen auf diesen Tupeln zur Verfügung. Die Erstellung von Datentupeln erfolgt mit der Anweisung out.

Wie bereits erwähnt, sind Prozesse in LINDA ebenfalls Tupel - sogenannte "Live-Tupel". Wenn ein Live-Tupel seine Arbeit getan hat, wird es in ein passives Datentupel umgewandelt, mit dessen Hilfe das Ergebnis der Operation verwertet werden kann. Der Befehl zur Erstellung eines Live-Tupels lautet eval.

In diesem Beispiel wird ein Live-Tupel in den Tupelraum gestellt und es werden Prozesse gestartet, die die Funktionen pow und arccos ausführen. Nachdem diese Funktionen terminiert haben, wird das Live-Tupel in ein Datentupel umgewandelt, das die Ergebnisse der Operationen an der entsprechenden Stelle beinhaltet. Dieses Beispiel hat die selben Auswirkungen wie das vorige Beispiel, bei dem die Werte direkt in ein Datentupel geschrieben werden, ohne vorher berechnet zu werden.

Um Tupel aus dem Tupelraum zu lesen, werden sogenannte "Templates" verwendet. In den Leseanweisungen werden Werte mitgegeben, die mit den korrespondierenden Werten im passenden Tupel exakt übereinstimmen müssen. Formale Parameter müssen im Typ mit dem entsprechenden Wert des Tupels übereinstimmen.

Die Operationen zum Lesen von Tupeln sind rd und in. rd liest das betreffende Tupel und läßt es im Tupelraum stehen, während in das Tupel nach dem Lesen aus dem Tupelraum entfernt.

Beispiel:
Lesen eines Tupels

rd("pretty Linda", ? zweihochzehn, ? pi)bzw.
in("pretty Linda", ? zweihochzehn, ? pi)

Diese Anweisungen suchen im Tupelraum nach einem Tupel, das aus drei Elementen besteht, an der ersten Stelle den String "pretty Linda" hat, an der zweiten Stelle eine Integerzahl und an der dritten Stelle eine Fließkommazahl hat und weisen der Variable zweihochzehn den Wert 1024, und der Variable pi den Wert 3,1415 zu. Dabei müssen zweihochzehn bzw. pi Integer- bzw. Fließkommavariablen sein. Durch die zweite Anweisung wird das Tupel aus dem Tupelraum entfernt. Existieren mehrere Tupel, auf die die Suchkriterien zutreffen, wird zufällig eines davon zurückgeliefert.

Identifiziert wird das Tupel in obigem Beispiel durch den String "pretty Linda", der in der in-Anweisung exakt mit dem String im oben erzeugten Tupel übereinstimmt. Das Tupel besteht also aus einem Namenselement und zwei Wertelementen. Ein Tupel hat in LINDA keinen expliziten Namen und keine (nach außen sichtbare) Adresse.

Die Tupel liegen im jeweiligen Tupelraum mehr oder weniger unsortiert herum und werden nur durch ihren Inhalt identifiziert und voneinander unterschieden. Der "Name" eines Tupels ist also sozusagen Teil seines Inhalts. Da alle Tupel im Tupelraum im selben Namenskontext stehen, kann sich sehr bald das Problem der Mehrdeutigkeit ergeben. Jeder Prozeß, der Zugriff auf den Tupelraum hat, hat Zugriff auf jedes einzelne Tupel in diesem Raum.

Es können zwar zur Identifizierung eines Tupels mehrere Elemente herangezogen werden, in größeren Systemen ist es aber doch möglich, daß sich Namenskonflikte ergeben. LINDA erkennt Namenskonflikte nicht, da Tupel, die die gleichen Elemente zur Identifizierung verwenden, zufällig den gleichen Inhalt in diesen Elementen haben können. Das System weiß nicht, welche Elemente zur Identifizierung herangezogen werden. Außerdem sind bei LINDA-Tupeln auch Duplikate erlaubt, was die Erkennung eines Namenkonflikts zusätzlich erschwert.

Im obigen Beispiel wird die erste Leseoperation Probleme bereiten. Das Element, das zur Identifikation des gesuchten Tupels verwendet wird, wird auch von einem zweiten Tupel an der selben Stelle verwendet. LINDA wählt bei mehreren Treffern nichtdeterministisch eines der passenden Tupeln aus. Das kann in obigem Beispiel das falsche sein.

Die zweite Leseoperation ist problemlos, da ein anderes Feld zur Identifikation herangezogen wird. Man sieht also, daß durch die unstrukturierte Benennung der Objekte alle Objekte im gleichen Namenskontext stehen, was mit steigender Systemgröße immer problematischer wird.

Die Leseoperationen rd und in arbeiten blockierend. Das heißt, daß die Leseoperation solange blockiert wird, bis ein Tupel gefunden wird, das auf die angegebenen Suchkriterien paßt. Oft ist es aber sinnvoll, wenn die Leseoperation abgebrochen wird und im Code fortgefahren wird, wenn kein passendes Tupel gefunden wird.

LINDA stellt zu diesem Zweck die Operationen rdp und inp zur Verfügung. Diese beiden Operationen warten nicht, bis sich ein passendes Tupel im Tupelraum befindet, sondern brechen ab, wenn kein Tupel gefunden werden kann, das den Suchkriterien entspricht und melden dies dem Programm.

Ein Nachteil von LINDA ist die fehlende Garbage Collection. Tupel, die einmal in den Tupelraum gestellt wurden, bleiben dort, bis sie mit in gelesen und entfernt werden. Wenn es aber mehrere Leser geben kann, müssen die Tupel im Tupelraum stehengelassen werden, um anderen Prozessen den Zugriff auf die Daten zu ermöglichen.

Dadurch bleibt das Tupel aber bestehen, ohne daß es jemals entfernt wird. Es gibt keine Möglichkeit, automatisch festzustellen, ob ein Tupel im Tupelraum noch gebraucht wird, oder ob es nutzlos geworden ist und gelöscht werden könnte. Da unter Umständen niemand weiß, welche Prozesse ein Tupel verwenden, kann es immer noch einen Prozeß geben, der auf das Tupel zugreifen könnte. Deshalb werden Tupel, die nicht mehr gebraucht werden, im Tupelraum für immer "liegen gelassen".

Vom "York Linda Team" wird in [Yor96] eine Methode der Garbage Collection in LINDA vorgestellt, die darauf beruht, daß mehrere Tupelräume verwendet werden. Dazu wird ein ausgezeichneter Tupelraum, der GTS genannt wird, benötigt. In diesem befinden sich passive Tupel, die persistente Tupelräume enthalten und aktive Tupel, die die Hauptprozesse enthalten. Tupelräume, die nicht mehr gebraucht werden, werden einfach samt ihrem Inhalt gelöscht.

Dies ist allerdings nur eine Hilfslösung, bei der nicht von echter Garbage Collection gesprochen werden kann. "Echte" Garbage Collection kümmert sich nämlich selbständig darum, welche Ressourcen noch gebraucht werden und welche wieder freigegeben werden können.

Bei diesem Ansatz der Garbage Collection muß aber erst das Problem gelöst werden, herauszufinden, welche Ressourcen noch gebraucht werden, bevor ein Tupelraum mitsamt seinem Inhalt gelöscht werden kann. Dies ist vor allem in verteilten Tupelräumen ein sehr schwieriges Problem.

Das York Linda Team stellt für dieses Problem einen Lösungsansatz vor, der mit einem Graphen arbeitet. Es wird ein Graph konstruiert, bei dem die Knoten Tupelräume sind und die Kanten angeben, ob ein Tupelraum von einem anderen erreichbar ist. Dabei ist ein Tupelraum t genau dann von einem Tupelraum s aus erreichbar, wenn

• t in einem Tupel von s vorkommt oder
• t von einem active tuple in s benutzt wird.

Mit Hilfe dieses Graphen kann festgestellt werden, ob es noch eine Referenz auf den Tupelraum gibt. Falls nicht, kann der Tupelraum bedenkenlos gelöscht werden. Allerdings ist das Problem, wann diese Garbage Collection durchgeführt werden soll, wann der Graph also erstellt werden soll, noch nicht gelöst. In diesem Punkt ist noch viel Forschungsarbeit notwendig.

In [Gel89] wird ein weiterer Ansatz zur Verwendung von mehreren (multiple) Tupelräumen vorgestellt. Das Hauptziel dieses Ansatzes ist aber nicht die Garbage Collection, sondern die Organisation von Tupeln in einer Hierarchie separater Tupelräume. Dies soll es ermöglichen, modulare Linda-Programme zu erstellen. Weiters wird es damit möglich, mittels der Operatoren zur Tupel-Manipulation Operationen nicht nur auf einzelnen Datenobjekten, sondern auf ganze Berechnungen anzuwenden.

Dieses System wird "Linda 3" bezeichnet. Ein Linda 3-System basiert auf einem Haupttupelraum (Default-Tupelraum), in den zusätzliche Tupelräume gestellt werden können. Dazu wird der neue Datentyp ts (tuple space) eingeführt. Ebenfalls neu ist die Operation tsc (tuple-space-create).

Um einen neuen Tupelraum namens Q zu erzeugen, verwendet man eval(tsc(Q)). Um nun Operationen auf diesen Tupelraum anzuwenden wird einfach Q.operation verwendet. Mit in kann ein Tupelraum wieder aus dem Default-Tupelraum entfernt werden.

ts baz; int plz, alter; string strasse, name;

eval("Adressen", tsc(A));
eval("Telefon", tsc(T));
eval("Haustiere, tsc(H));

A.out("Hans Meier", "Untergasse 4", 2314);
H.out("Hans Meier", "Flocki", 2);
T.out("Hans Meier", "max.mobil", 02221597);

A.rd("Hans Meier", ?strasse, ?plz);

in("Haustiere", ?baz);

H.in("Hans Meier", ?name, ?alter); /* blockiert */

In diesem Beispiel werden zuerst drei verschiedene Tupelräume erzeugt, die die Namen A, T und H bekommen. Dann wird in jeden der drei Räume ein Tupel eingefügt. Anschließend wird aus dem Tupelraum A mit rd ein Tupel gelesen. Würden alle drei Tupel in einem Tupelraum stehen, käme es zu einem Namenskonflikt, weil alle drei Tupel auf die Suchkriterien ("Hans Meier", ?stringvariable, ?integervariable) zutreffen.

In der nächsten Anweisung wird der Tupelraum H aus dem Default-Tupelraum gelöscht. Identifiziert wird der Tupelraum durch den String "Haustiere" im Tupel, in dem der Tupelraum im Default-Tupelraum steht. Eigentlich ist "gelöscht" nicht das richtige Wort, da der Raum nur "suspendiert" wird. Die letzte Anweisung versucht, ein Tupel aus dem Raum H zu lesen, bezieht sich aber auf einen nicht-existenten Tupelraum.

In diesem Fall wird das Programm an dieser Stelle solange blockiert, bis der Tupelraum H mit der Anweisung out("Haustiere", baz) wieder "reaktiviert" wird. Daraufhin wird die Abarbeitung des Programmes fortgesetzt. Auf diese Weise können ganze Programmteile oder Datenmengen "ausgeblendet" werden.

Neben der nur etwas "zusammengetricksten" Garbage-Collection hat LINDA aber noch andere Nachteile, die den Einsatz als Middlewaresystem erschweren. So kann nicht verläßlich ausgeschlossen werden, daß nicht autorisierte Prozesse auf die Daten zugreifen, es fehlt eine Transaktions-Verwaltung, Replikation und Ausfall werden nicht vom Benutzer abgeschirmt durchgeführt.

Am Institut für Computersprachen an der technischen Universität Wien wurde ein Middlewaresystem entwickelt, das ebenfalls auf dem Prinzip gemeinsamer Objekte basiert. Dieses System stellt Methoden und Datenstrukturen für verteilte Systeme zur Verfügung und versucht, die aufgezeigten Nachteile von CORBA und LINDA zu beseitigen.

Der CoKe stellt ein unabhängiges und generelles Koordinationsparadigma dar. Softwaresysteme und Programmiersprachen verschiedener Paradigmas können mit Hilfe des CoKe in einer verläßlichen Weise miteinander kommunizieren. Anwendungen interagieren mit dem CoKe über gemeinsame Datenobjekte. [Weh95]

Im folgenden wird kurz erklärt, auf welche Weise der CoKe Kommunikation und Synchronisation realisiert, wie Eigenschaften von Transaktionen verwaltet werden und wie die gemeinsamen Objekte benannt werden.

CoKe verwaltet verteilte, einmal oder mehrmals beschreibbare, persistente Objekte. CoKe stellt also zur Kommunikation - ähnlich wie LINDA - gemeinsame Objekte zur Verfügung. Das heißt, die Kommunikationsdaten werden von einem Kommunikationspartner in einen gemeinsamen Speicherbereich gestellt und von einem anderen dort gelesen. Es bestehen aber einige wesentliche Unterschiede zwischen diesen beiden Systemen.

Beim CoKe stehen die Objekte nicht in einem "öffentlichen" Raum, wie dem Tupelraum von LINDA, wo diese von allen Prozessen, die auf diesen Raum zugreifen, gelesen werden können. Ein Prozeß, der auf ein Objekt, das von einem anderen Prozeß erzeugt worden ist, zugreifen will, kann das nur, wenn er eine Referenz auf dieses Objekt besitzt. Auf diese Eigenschaft wird später noch genauer eingegangen.

CoKe-Objekte können entweder Konstanten oder Variablen sein. Bei Konstanten kann ein Objekt nur ein einziges Mal (bei der Erzeugung) beschrieben werden. Der Inhalt des Objektes bleibt die gesamte Lebensdauer des Objektes über gleich. Ein bestehendes Objekt kann nur gelesen, aber nicht manipuliert werden.

Die aktuelle Beta-Release von CoKe 2.0 beinhaltet bereits "updateable objects", also wiederbeschreibbare Objekte. Diese können nach ihrer Erzeugung beliebig oft wieder beschrieben werden. Das Prinzip ist vergleichbar mit dem von Variablen in höheren Programmiersprachen.

In der bisherigen Version gab es im CoKe nur konstante Objekte. Diese konnten nur einmal beschrieben werden. Dies hatte auch zur Folge, daß einmal geschriebene Werte nicht mehr zurückgenommen werden können. Wurde also ein Objekt geschrieben, dessen Inhalt an Aktualität verlor, mußte jedem beteiligten Kommunikationspartner mitgeteilt werden, daß das Objekt nicht mehr relevant war. Ein eventueller neuer Wert mußte in einem neuen Kommunikationsobjekt abgelegt werden.

Jedes CoKe-Objekt hat einen Typ. Dieser Typ wird von jenem System, das das Objekt beschreibt, festgelegt. Falls das Objekt an ein System verschiedenen Typs weitergegeben wird, so wird die Umwandlung des einen Typs in den anderen vom CoKe mittels hinzufügbarer Methoden automatisch durchgeführt. So kann erreicht werden, daß Kommunikationsdaten von allen Partnern verstanden werden.

CoKe unterstützt außerdem Transaktionen beim Zugriff auf die Kommunikationsobjekte. Transaktionen sind sicher durchgeführte Aktionen. Im Zuge einer Transaktion werden entweder alle Aktionen korrekt durchgeführt, oder es wird gar nichts verändert. Genau genommen werden keine "klassischen" Transaktionen unterstützt, sondern das sogenannte "Flex-Transaktionsmodell". Beim allgemeinen Transaktionsmodell wird gefordert, daß folgende vier Eigenschaften erfüllt werden:

• Atomizität
• Konsistenz
• Isoliertheit und
• Dauerhaftigkeit

Diese Eigenschaften werden in der Fachliteratur auch ACID-Eigenschaften genannt (atomicity, consistency, isolation, durability).

Beim "Flex-Transaktionsmodell", das an der Universität von Purdue entwickelt wurde [Elm92] wird auf die Eigenschaft der Isoliertheit verzichtet. Isoliertheit bedeutet, daß Zwischenergebnisse, also Teilresultate, die während der Transaktion erzielt werden, nach außen hin nicht sichtbar sind, solange die Transaktion nicht vollständig ausgeführt ist.

Teilresultate können also beim Flex-Transaktionsmodell während der Transaktion bereits nach außen sichtbar gemacht werden. Daraus ergeben sich wesentliche Vorteile für die verteilte Programmierung, da keine langfristigen Sperren in den autonomen, lokalen Systemen gehalten werden müssen. Dadurch entsteht aber auch der Nachteil, daß Teilergebnisse, die während einer Transaktion anfallen, trotz Fehlschlagens der gesamten Transaktion von anderen Teilsystemen bereits verwendet worden sein könnten.

Es ist ja, wie gesagt, gefordert, daß im Zuge der Transaktion entweder die gesamte Transaktion korrekt durchgeführt wird, oder daß überhaupt keine Änderung durchgeführt wird. Nun kann es beim Flex-Transaktionsmodell aber sein, daß die Transaktion nicht korrekt durchgeführt wird, aber ein Teilergebnis bereits dazu verwendet wurde, den Zustand des Systems zu verändern.

In diesem Falle ist es notwendig, die durchgeführten Veränderungen rückgängig zu machen, da ja sonst die Forderung nach Atomizität verletzt werden würde. CoKe bietet daher die Möglichkeit, solche Änderungen mittels Kompensationsroutinen semantisch rückgängig zu machen. Wird im Fehlerfall jede Änderung aufgrund eines Teilergebnisses kompensiert, kann auf die Eigenschaft der Isoliertheit ohne Probleme verzichtet werden.

Weitere Features des CoKe-Transaktionsmodells sind geschachtelte Transaktionen - d. h. im Zuge einer Transaktion können weitere Untertransaktionen gestartet werden - und die Möglichkeit der Funktionsreplikation. Dabei werden zwei oder mehrere Prozesse gestartet. Das System wartet, bis einer davon erfolgreich terminiert hat und schickt dann ein Cancel-Signal an die anderen Prozesse.

Wie bereits zuvor erwähnt, werden die Objekte von den Kommunikationspartnern nicht über einen Namen oder ihren Inhalt angesprochen, sondern über eine Referenz, die ein Prozeß auf das entsprechende Objekt haben muß, um darauf zugreifen zu können. Besitzt ein Prozeß keine Referenz auf ein Objekt, wird es ihm vom CoKe nicht ermöglicht, auf das Objekt zuzugreifen, auch wenn er weiß, wo sich das Objekt befindet.

Dies geht zwar zu Lasten der Flexibilität, hat aber unter anderem eine Erhöhung der Sicherheit zur Folge. Ein Prozeß, der ein Datenobjekt erzeugt, kann genau festlegen, wer das Recht hat, den Inhalt dieses Objektes zu lesen respektive zu schreiben. Er kann sich darauf verlassen, daß kein anderer Leser sich Zugriff auf das Objekt verschafft.

Ein weiterer Vorteil dieser Strategie ist, daß relativ problemlos Garbage Collection implementiert werden kann. Da alle Prozesse, die ein Objekt benutzen können, bekannt sind, kann festgestellt werden, wann kein potentieller Leser mehr existiert. Damit ist sichergestellt, daß das Objekt nicht mehr gebraucht wird, und es kann bedenkenlos vernichtet werden.

CoKe ist, wie erwähnt, keine Programmiersprache, sondern ein Middlewaresystem. Der CoKe stellt also nur Methoden und Funktionen zur Verfügung, die in existierende Programmiersprachen inkludiert werden können. Derzeit existieren CoKe-Erweiterungen für drei Programmiersprachen.

Die wichtigsten Spracherweiterungen stellen die Befehle zum Erstellen und Lesen von Objekten dar. Diese werden im folgenden als Beispiel kurz anhand der Erweiterung der Sprache C (etwas vereinfacht) vorgestellt.

Als erstes wird in diesem Beispiel eine Variable für die Identifikationsnummer des Objektes angelegt (auf die im Anschluß noch näher eingegangen wird). Danach wird das Objekt einmalig beschrieben. In diesem Falle enthält das Kommunikationsobjekt einfach nur einen Textstring.

Danach wird das Objekt wieder ausgelesen. CoKe bietet die Möglichkeit des blockierenden und des nichtblockierenden Lesens. In dem Beispiel sind beide Varianten angeführt. Beim blockierenden Lesen (letzte Anweisung) wird die Programmausführung so lange angehalten, bis die betreffende testoid definiert ist. Danach wird der Inhalt des Objektes in die Variable text übernommen.

Dieses Beispiel ist nur eine vereinfachte Darstellung eines CoKe-Programms. Zum Schreiben eines Objektes ist beispielsweise noch eine Transaktion zu beginnen und natürlich wieder abzuschließen. Weiters stellt CoKe noch Methoden zur Verfügung, um Arrays und Listen zu verwalten oder um Informationen über die Umgebung des laufenden Programmes abfragen zu können.

Eine durch CoKe erweiterte Sprache wird als "Sprache & Co" (Sprache plus Coordination) bezeichnet. Derzeit existieren Implementierungen von C & Co, Prolog & Co und C++ & Co. Es wird beabsichtigt, in Zukunft auch Java & Co zur Verfügung zu stellen.

Da CoKe als plattform- und sprachunabhängiges System konzipiert ist, ist es problemlos möglich, daß Prozesse miteinander über CoKe-Objekte kommunizieren, die in verschiedenen Programmiersprachen geschrieben worden sind. Es ist also etwa kein Problem, wenn ein C & Co-Programm Objekte schreibt, die von einem Prolog & Co-Programm gelesen werden sollen.

Auf jedem Rechner, auf dem ein CoKe-Programm läuft, läuft eine Instanz des Coordination Kernels, welche mit den CoKe-Instanzen auf den Rechnern der Kommunikationspartner die Objektverwaltung transparent für die Prozesse, die den CoKe benutzen, durchführt und verwaltet.

Die Kommunikationsobjekte von CoKe haben keinen Namen im eigentlichen Sinne. Sie werden durch eine eindeutige Identifikationsnummer (Object-ID, OID) identifiziert. Diese OID besteht aus drei 32-Bit Zahlen; die Internetadresse (IP-Adresse) jenes Rechners, auf dem das Objekt erstellt wurde, eine fortlaufende Nummer und die Uhrzeit des CoKe-Starts.

Dadurch ist sichergestellt, daß es weltweit garantiert keine zwei Objekte mit gleichen OIDs geben kann. Jeder Rechner hat sicher eine andere IP-Nummer und alle Objekte, die auf einem Rechner erstellt wurden, werden durch die laufende Nummer voneinander unterschieden. Sollte der CoKe abstürzen und nach dem Neustart bereits verwendete laufende Nummern noch einmal verwenden, wird das Objekt durch die geänderte CoKe-Startzeit eindeutig identifiziert.

Da einem CoKe-Objekt kein wirklicher Name zugewiesen wird, stellt sich auch das Problem der globalen Namensgebung nicht. Ein Objekt bekommt seine Identifikationsnummer vom System zugewiesen, und wird von allen, die auf dieses Objekt zugreifen über diese Nummer angesprochen, welche sie als Referenz übergeben bekommen haben. Vereinfacht gesagt gibt es so etwas wie einen einzigen globalen "Namensraum", in dem Objekte mit garantiert eindeutigen "Namen" stehen, welche vom CoKe vergeben wurden.

Der CoKe realisiert einige wesentliche Verbesserungen gegenüber den vorher vorgestellten Systemen. Er ist ein Middlewaresystem wie CORBA, verwendet aber das vorteilhaftere "Shared Objects"-Paradigma wie LINDA. Er vereint somit die wesentlichsten Vorteile der beiden Systeme und versucht, deren Nachteile zu umgehen.

CoKe bietet aber auch als Middlewaresystem eine größere Funktionalität als CORBA. Beispielsweise regelt der CoKe die Replikation, d. h. die Verwaltung von Kopien der Daten, automatisch. Auch die umfangreiche Transaktionsverwaltung ist in anderen Middlewaresystemen wie CORBA oder DCE nicht enthalten. Weiters verwaltet der CoKe auch Ausfall und Persistenz der Daten.

Zum Punkt der Replikation wäre vielleicht zu sagen, daß es vorteilhaft wäre, wenn der CoKe Informationen über die regionalen Besonderheiten des Speicherortes eines replizierten Objektes hätte (etwa die Geschwindigkeit der Verbindung des entsprechenden Rechners mit einem anderen Rechner oder der physikalischen Entfernung zwischen diesen Rechnern). So wäre es dem CoKe in Zukunft möglich, bei mehreren Kopien selektiv jene zu laden, die am schnellsten von ihrem Speicherort geholt werden könnte. Damit könnten überlastete Fernverbindungen entlastet werden.

Gegenüber anderen Systemen, die über gemeinsame Objekte kommunizieren, wie etwa LINDA hat der CoKe den Vorteil größerer Sicherheit, da nicht jeder, der auf den Objektraum zugreifen kann, auf jedes beliebige Objekt zugreifen darf. Nur Prozesse, die eine Referenz auf ein Objekt haben, dürfen den Inhalt des Objektes lesen. Außerdem ist im CoKe Garbage Collection realisiert.

Der Nachteil, den der Coordination Kernel bisher aufwies, war, daß alle Objekte Konstante waren. Es war nicht möglich, ein einmal erstelltes Objekt zu modifizieren. Wollte man den Inhalt eines Objektes verändern, mußte man es komplett löschen und ein neues Objekt anlegen. Natürlich mußten alle, die auf das Objekt Lesezugriff hatten, von dem neuen Objekt unterrichtet werden, um auf die neuen Daten zugreifen zu können. In der neuen Beta-Version von CoKe können solche Aufgaben nun von den "updateable objects" übernommen werden, die mehrmals beschrieben werden können.

Die Tatsache, daß auf Objekte nur zugegriffen werden kann, wenn eine Referenz auf dieses Objekt übergeben wurde, hat zugleich Vorteile und Nachteile. Einerseits erhöht dies die Sicherheit, da kontrolliert wird, wer auf ein Objekt Zugriff hat, andererseits wäre es einfacher, nur eine ID zu benötigen, um Zugriff auf das Objekt zu haben.

Ein Nachteil von CoKe ist auch die etwas kompliziertere Programmierung. Vor allem für Einsteiger ist die Verwaltung der Objekte über zu übergebende Referenzen gewöhnungsbedürftig, wogegen die Arbeit mit LINDA-Tupeln eine Lösung darstellt, die für den neuen Programmierer etwas einfacher und schneller zu verstehen ist.

Die Ziele Einfachheit und Flexibilität stehen aber grundsätzlich immer im Konflikt mit den Zielen Funktionalität und Sicherheit.

Schon sehr bald nach der Entwicklung halbwegs leistungsfähiger Computer hat man erkannt, daß es vorteilhaft ist, zwei oder mehrere Rechner miteinander zu verbinden. Dadurch konnte Datenaustausch betrieben werden, ohne die Daten umständlich auf - teure und langsame - Datenträger zwischenzuspeichern und von einem Rechner zum anderen zu tragen.

Auch konnten sich so mehrere Rechner eine Aufgabe teilen und sie gemeinsam schneller und effizienter lösen. Also hat man begonnen, Rechner zu vernetzten und ganze Netzwerke von Rechnern aufzubauen. Das waren anfangs natürlich nur lokale Netze von physisch nahe beieinander stehenden Rechnern (LANs - Local Area Networks).

Doch bald entstand der Bedarf, Rechner oder ganze Rechnernetzwerke, die weiter entfernt voneinander standen - in verschiedenen Gebäuden oder gar verschiedenen Ortschaften - miteinander zu vernetzen. So wurden weite Netzwerke (WANs - Wide Area Networks) entwickelt.

Die ersten größeren Rechner wurden in den USA für das Militär gebaut. Das Militär war überhaupt schon immer die treibende Kraft hinter der Computerentwicklung. Als mit der Zeit immer leistungsfähigere Rechner gebaut wurden und immer mehr Anwendungen für sie entwickelt wurden, wurden Rechner auch im militärischen Bereich immer unverzichtbarer.

Insbesondere die Kommunikation als einer der wichtigsten und sensibelsten Bereiche des Militärs wurde immer mehr auf Computernetzwerke umgestellt. Da das Funktionieren der Kommunikation von entscheidender Wichtigkeit für das Militär ist, wurde es notwendig, für das Militär ein Computernetzwerk quer über die USA zu legen, das selbst bei einem Ausfall des Großteils dieses Netzwerkes (etwa nach einem Atomschlag) noch funktionsfähig ist. Aus diesem Grunde wurde 1969 das ARPANET entwickelt, dessen zugrundeliegendes Protokoll diese Anforderungen erfüllt. [Sei97]

Das ARPANET (benannt nach der Advanced Research Projects Agency) arbeitete nicht mit direkten Verbindungen zwischen den einzelnen Rechnern, sondern paketorientiert. Die Daten wurden in einzelne Pakete aufgeteilt in das Netzwerk hineingeschickt, in dem sie sich ihren Weg zu ihrem Ziel suchen. Wie dieser Weg aussieht, ist nicht a priori festgelegt. [G]

Anfangs bestand das ARPANET aus nur vier Supercomputern. Der Begriff "Supercomputer" ist natürlich in den Dimensionen jener Zeit gemessen. Diese Spitzenrechner hatten beispielsweise ganze 12 Kilobyte RAM… [Zie95]. Zwei Jahre später zählte das ARPANET bereits 30 Teilnehmer. Mit der Zeit kamen aber immer mehr Maschinen aus den USA zum ARPANET hinzu, von denen auch einige von unterschiedlicher Architektur waren. Man war also von Anfang an bestrebt, dieses Netzwerk technisch so offen wie möglich zu gestalten.

Später wurde dieses Netzwerk auch amerikanischen Universitäten zum Zwecke der wissenschaftlichen Forschung zur Verfügung gestellt. Nach einiger Zeit wurden auch Universitäten außerhalb der Vereinigten Staaten an das Netzwerk angeschlossen, und schließlich kamen auch kommerzielle Firmen, Verwaltungseinheiten und private Teilnehmer dazu.

1983 wurde das Netzwerk in einen militärischen und einen zivilen Teil getrennt. Der militärische Teil wurde MILNET genannt, der zivile hieß weiterhin ARPANET. Im gleichen Jahr wurde TCP/IP (Transmission Control Protocol / Internet Protocol) als Standard für das Netz festgelegt.

In den Jahren danach kamen immer mehr kleine Netzwerke zu diesem Netz dazu, und es entstand das "Internet" - ein "Netz der Netze". Die Bandbreiten des Backbone-Netzes wurden sukzessive (von anfangs 56 Kilobit/s) erhöht. Die Zahl der im Internet befindlichen Rechner stieg sehr schnell an.

Einer der ältesten und immer noch wichtigsten Dienste im Internet ist "electronic mail" (e-Mail) - elektronische Post. Von Anfang an war es möglich, daß jeder Teilnehmer des Netzwerkes schriftliche Nachrichten an jeden beliebigen anderen Teilnehmer schickt. Dieser kann die Nachrichten, die er empfangen hat, aus seinem elektronischen Postfach ("mail box") abrufen.

Im Laufe der Zeit wurden noch andere Dienste für das Internet entwickelt. Über e-Mails sind oft rege Diskussionen gelaufen, meist über Mailinglisten (jedes Mitglied der Liste bekommt alle Nachrichten, die an die Liste geschickt werden als e-mail). 1986 wurde der USENET-News-Dienst auf TCP/IP umgestellt und damit ins Internet aufgenommen [His]. News ist ein Dienst, der Diskussionsforen zu den unterschiedlichsten Themen bietet. Die Nachrichten werden nicht über e-Mail an alle Interessierten übermittelt, sondern auf einem Server gespeichert, wo sie von jedem abgerufen werden können.

Mit Telnet wurde ein Dienst geschaffen, der die Möglichkeit bietet, als Benutzer in einen im Internet hängenden Rechner einzusteigen, ohne daß das Terminal "direkt" an diesem Rechner hängt. IRC "Internet Relay Chat" ermöglicht "tratschen" über das weltweite Netzwerk, wobei abgeschickte Eingaben sofort an alle Teilnehmer eines Chat-Kanals übermittelt werden.

Ein anderer, sehr wichtiger Dienst ist FTP (File Transfer Protocol), ein Dienst zur sicheren Übertragung von Dateien über das Internet. Autorisierte Benutzer können sich mit Hilfe dieses Dienstes an einem FTP-Server anmelden und mit diesem über das Netz Dateien beliebigen Formats austauschen.

Um Dateien, die irgendwo im Internet mittels FTP geladen werden können, finden zu können, wurde mit Archie ein Suchdienst entwickelt. Wenn man den Namen der gesuchten Datei weiß, bekommt man vom Archieserver die FTP-Adressen angezeigt, unter denen die Datei geladen werden kann.

Im Jahre 1991 wurde an der Universität von Minnesota der Dienst "Gopher" entwickelt [Smi95]. Gopher ist ein menüorientiertes System, mit dem Informationen über das Internet abgerufen werden können. Der Gopher-Benutzer hat eine Textseite auf seinem Bildschirm, die entweder ein Dokument oder ein Menü ist. Diese Menüs führen zu Dokumenten oder zu einem anderen Gophermenü. Der große Nachteil von Gopher ist, daß ausschließlich Textseiten angezeigt werden können. Es gibt keine Unterstreichungen, Fettschriften, größere Überschriften, auch keine Bilder oder sonstigen optischen Verbesserungen.

Bereits Jahre 1989 wurde am CERN (dem Schweizer Kernforschungsinstitut) [CER1] ein neuer Internetdienst entwickelt: Das WorldWideWeb (WWW) [CER2]. Das WWW enthält Hypertextdateien, welche graphische Verbesserungen wie Bilder und Textformate bieten, und mit speziellen Anzeigeprogrammen, den sogenannten Browsern, dargestellt werden können [W3C].

Die Dateien im WWW liegen in einer Seitenbeschreibungssprache, der sogenannten "HyperText Markup Language" (HTML) vor. Eine HTML-Datei ist eine Textdatei, in der sich besondere Formatbefehle, die sogenannten "Tags" befinden, welche angeben, wie der enthaltene Text vom Browser angezeigt werden soll.

Das WWW ist aber nicht nur ein komplett neuer Internetdienst, es vereint auch bereits bestehende Dienste in sich. So können zum Beispiel Dienste wie Gopher, FTP oder News mit einem Webbrowser unter einer Oberfläche genutzt werden. Auch ein e-Mail Programm darf natürlich bei keinem modernen Browser fehlen.

Mit der Erfindung des WWW wurde das Internet außerordentlich populär. Durch die einfache Hypertext-Bedienung und die besseren Gestaltungsmöglichkeiten ist das Internet heutzutage keine Sache von "eingeweihten Gurus" mehr, sondern wird von einer breiten Öffentlichkeit genutzt.

Mit steigender Verbreitung des WWW wurde natürlich auch das Interesse der Softwareindustrie geweckt. Neue Browser mit verbesserter Funktionalität, welche Formatierungen unterstützen, die gar nicht im HTML-Standard enthalten sind, kamen auf den Markt. Neue Firmen entstanden und entwickelten sich zum Teil sogar zu Marktführern in der Sparte Internetsoftware.

Wenn heute - vor allem in den Medien - vom "Internet" gesprochen wird, ist meist nur das WorldWideWeb damit gemeint. Dieser Dienst hat eine derartige Popularität erreicht, daß er von vielen schon mit dem Internet gleichgesetzt wird. Heute schätzt man, daß etwa 30 bis 40 Millionen Menschen das Internet benutzen. Derartige Zahlen sind aber wertlos, da sie sich monatlich ändern.

Wahrscheinlich wird ein Anschluß an das Internet irgendwann so selbstverständlich sein, wie heute ein Telefonanschluß. Die Möglichkeiten, die durch die immer fortschreitende Verbesserung von Hardware und Software eröffnet werden, sind heute noch gar nicht absehbar. Vielleicht ist ja auch das WWW in der heutigen Form schon bald überholt und nur noch Teil der Geschichte des Internets.

Dem Internet liegt das TCP/IP-Protokoll (Transfer Control Protocol/Internet Protocol) zugrunde. In diesem Protokoll hat jeder beteiligte Rechner eine eindeutige Identifikationsnummer - die IP-Nummer. Jede IP-Nummer besteht aus einer 32 Bit großen Zahl, die weltweit eindeutig ist. Zur besseren Lesbarkeit werden IP-Nummern meistens in vier einzelne Bytes aufgeteilt und diese, getrennt durch Punkte, dezimal angegeben. Also beispielsweise: 193.154.152.129

Diese IP-Nummern teilen sich in zwei Teile: Eine Netzwerkadresse und eine Hostadresse. Die Netzwerkadresse adressiert das Netzwerk, in dem sich der betreffende Rechner befindet. Die Hostadresse ist die Adresse dieses Rechners innerhalb des Netzwerkes. Um der Tatsache Rechnung zu tragen, daß es sehr große aber auch sehr kleine Netzwerke gibt, wurden verschiedene Klassen von IP-Adressen eingeführt, die sich in der unterschiedlichen Größe des Netzwerk- und des Hostanteiles an der Adresse unterscheiden.

Klasse A - Adressen sind die Adressen für die größten Netzwerke. Klasse A - Adressen werden durch eine 0 als erstes Bit identifiziert. Von den restlichen 31 Bit entfallen 7 auf die Netzwerkadresse und 24 auf die Hostadresse. Das bedeutet, daß mit Klasse A - Adressen maximal 126 Netzwerke (zwei Adressen sind reserviert) und innerhalb dieser mehr als 4 Millionen Rechner adressiert werden können.

Klasse B - Adressen werden durch die Bits 1 und 0 am Beginn erkannt, und stellen 14 Bits zur Adressierung des Netzwerkes zur Verfügung. Damit bleiben für die Hostadresse 16 Bit über. Damit ist es möglich, etwas mehr als 16.000 Netzwerke mit jeweils über 65.000 Rechnern zu adressieren. (Zwei Adressen sind auch hier reserviert)

Die nächste Klasse, die Klasse C wird durch die Bitfolge 110 identifiziert und verwendet 21 Bit zur Netzwerkadressierung. Womit 8 Bit für den Host übrigbleiben. Das ergibt eine maximale Zahl von etwa 2 Millionen Netzwerken mit 254 einzelnen Rechnern (zwei Adressen sind wieder reserviert).

Weiters gibt es noch zwei spezielle IP-Klassen, die Klassen D und E. Sie dienen nicht zur Adressierung von bestimmten, einzelnen Rechnern im Internet, sondern haben spezielle Aufgaben. Klasse D - Adressen beispielsweise werden für Multicasting-Zwecke verwendet. Damit ist es möglich, Datagramme an Gruppen von Hosts in mehreren Netzwerken zu senden. Klasse D - Adressen teilen sich nicht in einen Netzwerk und einen Hostanteil auf. Sie bestehen aus der Bitfolge 1110 und einer 28 Bit langen Mulitcastadresse.

Schließlich hat man noch Klasse E - Adressen für zukünftige Anwendungen reserviert. Sie werden durch die Bitfolge 11110 identifiziert und beinhalten noch 27 Bit zur freien Verwendung. [Tho95]

Die Einteilung in Netzwerkadresse und Hostadresse ist einerseits sehr praktisch, weil dies eine übersichtliche Strukturierung des gesamten Adressraumes ermöglicht. Andererseits ist diese Methode enorm ineffizient, da meist nicht die gesamte Zahl an möglichen Hosts innerhalb eines Netzwerkes vorhanden ist.

Das heißt, daß einige Hostnummern innerhalb eines Netzwerkes ungenutzt bleiben, was nichts anders bedeutet, als daß es dadurch IP-Nummern gibt, die keinem Rechner zugewiesen sind. Vor allem bei A und B - Adressen kann die Anzahl auf diese Art "verschwendeter" Adressen sehr groß werden.

Da die IP-Nummern im Internet langsam knapp werden wird das zum Problem. Von den etwa 4 Milliarden Adressen, die mit 32 Bit angesprochen werden könnten, würden enorm viele durch diese Aufteilung verloren gehen. Deshalb wurde eine Möglichkeit entwickelt, eine Netzwerkadresse für mehrere Netzwerke zu benutzen.

"Subnetting" oder die Verwendung von Subnetzadressen löst dieses Problem zum Teil. Beim Subnet Addressing wird eine einzige Netzwerkadresse für mehrere Netzwerke verwendet. Um das zu ermöglichen, werden einige Bits der Hostadresse ebenfalls für die Netzwerkadressierung verwendet. Das verringert zwar den Adreßraum für die Hosts, erweitert aber den Netzwerkadressraum.

Für jedes Netzwerk wird eine 32-bit Subnetzmaske (Subnet Mask) verwendet. Diese 32-bit-Zahl gibt an, welche Bits in der IP-Nummer als Teil der Netzwerkadresse betrachtet werden sollen. Im nachfolgenden Beispiel wird eine Klasse-B Adresse, bei der 4 Bits der Hostadresse als Netzwerkadresse verwendet werden, gezeigt. Jedes "1"-Bit in der Subnetzmaske gibt an, daß das korrespondierende Bit in der IP-Nummer Teil der Netzwerkadresse ist.

Obwohl beide IP-Nummern zum Klasse-B Netzwerk 193.154.x.x gehören, sind die beiden Rechner in verschiedenen Netzwerken, da diese Klasse-B Netzwerkadresse mit Hilfe der Bits 16 - 23 geteilt wird.

Aber auch durch Subnetting wird das Problem der zur Neige gehenden IP-Nummern nicht wirklich gelöst. Durch die noch immer bestehende Einteilung in Netzwerkadresse und Rechneradresse und durch die Tatsache, daß für einen Rechner mehrere IP-Nummern vergeben werden können, gehen viele Adressen verloren, sodaß der gesamte Adressraum von etwa 4 Milliarden Adressen nicht für ebenso viele Rechner genutzt werden kann.

Es wurde aus diesem Grund bereits ein neues System entwickelt, das für IP-Nummern nicht 32, sondern 128 Bit benutzt. Dieses System wird IPng (IP - next generation) genannt [Eng95]. Dieser Vorschlag sieht nicht nur eine Vergrößerung des Adressraumes vor, sondern soll auch noch andere Informationen enthalten, wie Sicherheit, Routinginformationen und die Unterstützung von Multicastadressen.

Die Wahrscheinlichkeit, daß bei 128 Bit-Adressen der Adressraum zu klein wird, ist relativ gering. Bei 128 Bit können für jeden Quadratmeter auf der Erdoberfläche 665.570,793.348,866.943,898.599 Adressen vergeben werden [Fal95]. Das sollte für die nächsten Jahre reichen.

Ein größeres Problem ist die Umstellung. Es müßten nämlich alle Internetrechner gleichzeitig umgestellt werden. Ein ähnliches Problem stellte sich 1982, als das Arpanet auf TCP/IP umgestellt wurde. Um die Benutzer damals zur Umstellung auf das neue Protokoll zu bewegen, wurden eines Tages keine Pakete im alten Protokoll mehr vom Netz akzeptiert, und am nächsten Tag wurde wieder auf Normalbetrieb umgestellt. Nachdem diese Übung später noch einmal wiederholt wurde, begriffen die Benutzer, daß man es ernst meinte. Anfang 1983 konnte komplett auf TCP/IP umgestellt werden [Mei96].

Dieses Beispiel läßt sich natürlich nur bedingt auf das aktuelle Problem übertragen, denn erstens war es damals möglich, beide Protokolle parallel ablaufen zu lassen und zweitens war das Internet Anfang der Achtziger Jahre deutlich kleiner als es heute ist.

Die dezimale (decimal dotted) Darstellung einer IP-Nummer ist zweifellos übersichtlicher und einfacher als die bitweise Darstellung, von einer einfachen Adressierung durch Angabe von vier Zahlen kann aber sicher nicht gesprochen werden. Wer merkt sich schon die Adresse 193.154.152.129 des WWW-Servers seiner Lieblingsseiten?

Um das Ansprechen eines Servers im Internet zu vereinfachen, hat man einen neuen Dienst geschaffen, das sogenannte "Domain Name System" (DNS). Das DNS bildet lesbare Namen in IP-Adressen ab. Man kann hier also von einer Namensgebung sprechen, bei der Objekten (IP-Adressen) von einem Nameserver Namen zugewiesen werden können.

Das Domain Name System ist, wie der Name schon andeutet, in Domänen - also hierarchisch - organisiert. Alle DNS-Namen werden in verschiedene Domänen unterteilt. Beispiele dafür sind Länderdomänen (wie etwa at für Österreich) oder generelle (generic) Domänen (wie etwa edu für "educational", mil für "military" oder com für "commercial").

Innerhalb dieser Domänen können Namen und weitere Unterdomänen autonom vergeben werden. Der "Besitzer" einer Domäne ist allein für die jeweils darunterliegende Domänenstruktur verantwortlich. Namen in unterschiedlichen Domänen können natürlich wieder gleich sein, wie das bei der hierarchischen Organisation des Namensraumes üblich ist.

Jeder Domänenbesitzer verwaltet einen eigenen DNS-Server, in dem er die Routing-Informationen für die ihm untergeordneten Domänen und Rechnernamen zur Verfügung stellt. Diese Information ist entweder die konkrete IP-Nummer des entsprechenden Rechners, oder die Adresse eines anderen DNS-Servers, in dem die Informationen über die Rechner der untergeordneten Domänen zu finden sind.

Der Rechner mit dem Namen mips.complang.tuwien.ac.at gehört beispielsweise der Domäne at an. Innerhalb dieser Domäne gehört er in die Domäne ac. Es wird also im DNS-Server des Domänenverwalters der ac-Domäne nach der IP-Nummer des Rechners gesucht. Danach wird weiter in den Domänen tuwien und complang gesucht, bis schließlich die Nummer des Rechners mips zurückgeliefert wird. Das DNS stellt damit eine verteilte Datenbank zur Verfügung, in der die DNS-Namen gespeichert sind.

Die größte vorhandene Informationsmenge nützt nichts, wenn es keine Möglichkeit gibt, aus der Fülle aller Informationen jene herauszufinden, die man benötigt. Bei kleinen Informationsmengen ist es noch möglich, händisch die relevanten von den unwichtigen Daten zu trennen. Wird die Datenmenge aber größer, wie in größeren Bibliotheken oder Datenbanken, so muß nach geeigneten Möglichkeiten gesucht werden, die jeweils gesuchten Informationen zu lokalisieren.

Das Internet ist mit Sicherheit die größte Sammlung an Informationen, die jemals existiert hat. Der Versuch, sich "händisch" bestimmte Informationen aus dem riesigen Angebot zusammenzusuchen, ist von vorn herein zum Scheitern verurteilt. Niemand kann auf Tausenden von Webservern nachschauen, ob dort eine relevante Information liegt.

Diese Problematik wurde sehr rasch erkannt und es wurden verschiedene Werkzeuge geschaffen, mit denen die Suche nach bestimmten Inhalten im Internet ermöglicht bzw. erleichtert wurde. Erst mit Hilfe dieser Programme wurde es möglich, gezielt bestimmte Informationen im Netz zu lokalisieren.

Im Jahre 1990 wurde ein Suchdienst namens Archie gestartet. Archie ist dazu da, Dateien auf FTP-Servern zu suchen. Ein Archie-Server holt sich die Inhaltsverzeichnisse von öffentlichen FTP-Servern und speichert diese. Benutzer, die eine bestimmte Datei suchen, verbinden sich mit dem Archie-Server und erhalten, nach Eingabe der gesuchten Datei, den (die) Server zurückgeliefert, auf dem (denen) sich die Datei befindet. Außerdem bekommt der Benutzer den genauen Pfad dieser Datei auf dem Server geliefert.

1993 wurde - inspiriert durch den Erfolg von Archie - an der Universität von Nevada ein Suchdienst für Gopher entwickelt: Veronica. Dieser Suchdienst hatte aber aus dem gleichen Grund wenig Erfolg, wie Gopher selbst: Das WWW trat zu dieser Zeit seinen Siegeszug an und verdrängte Gopher fast völlig.

Mit dem Erfolg des WorldWideWeb wurden auch für diesen Dienst bald diverse Suchmaschinen geschaffen. Das erste Suchprogramm für das Web war der "World Wide Web Wanderer". Ursprünglich zählte der Wanderer nur die Webserver. Später wurde ein Suchprogramm namens Wandex hinzugefügt. Der Wanderer lief von Juni 1993 bis Jänner 1996.

Ebenfalls 1993 gingen Aliweb, JumpStation, World Wide Web Worm und RBSE Spider in Betrieb. Aliweb war ein Archie-ähnlicher Suchdienst für das WWW. Damit ein Web-Server in Aliweb aufgenommen wurde, mußte dieser Server bei den Betreibern von Aliweb registriert werden. WWW Worm und JumpStation indizierten nur den Titel bzw. die Header von Webdokumenten.

1994 folgten WebCrawler und Lycos. Heute existieren etwa 150 verschiedene Suchmaschinen auf dem WWW. Viele dieser Maschinen sind auf bestimmte Einsatzgebiete spezialisiert. So gibt es etwa Suchmaschinen für USENET-News-Gruppen (z. B. DejaNews [DN]) oder solche, die auf das Auffinden von Bildern oder Links spezialisiert sind (z. B. Altavista [Alt]).

Wie funktionieren nun solche Suchmaschinen? Grundsätzlich arbeiten alle Suchmaschinen so, daß Informationen auf dem Web gesucht, in einer Datenbank gespeichert und bei Bedarf (d. h. bei einer Anfrage eines Benutzers) in der Datenbank gesucht und in entsprechender Form an den Benutzer geliefert werden.

Das hört sich einfacher an, als es ist. Schon der erste Punkt, die Suche der Information auf dem WWW, ist alles andere als trivial. Das WWW besteht aus vielen Millionen von Dateien, die auf mehreren tausend Webservern liegen. Ein Gesamtverzeichnis dieser Server existiert nicht und auf den Servern existiert auch kein Verzeichnis der darauf gespeicherten Dokumente.

Die meisten Suchmaschinen gehen bei der Informationsbeschaffung nach folgendem Algorithmus vor:

1. Erstellung einer Liste von Dokumenten, die bearbeitet werden sollen.
1. Auswahl eines Dokuments aus der Liste zur Bearbeitung.
1. Holen des Dokuments aus dem Internet und Suchen aller Verweise zu anderen Webseiten. Hinzufügen dieser Seiten zur Dokumentenliste sofern sie noch nicht in der Liste sind oder bereits bearbeitet sind.
1. Bearbeitung der aktuellen Seite. Herausfiltern von Titel, Schlüsselwörtern oder anderer Information. Diese Informationen werden in einer Datenbank gespeichert.
1. Gehe zu Punkt 2.

Sehr wichtig ist dabei die Strategie, in welcher Reihenfolge die Dokumente in Punkt 2 ausgewählt werden. Je nachdem, ob die ältesten oder die neuesten Einträge in der Liste hergenommen werden, ergibt sich eine Suche in die Breite (breadth-first) oder in die Tiefe (depht-first).

Die Wahl des Startpunktes der gesamten Suche ist weniger bedeutend, da das WWW ein System mit vielen Hyperlinks unter den einzelnen Seiten ist, so daß fast alle Seiten von einer Seite mit vielen Verweisen auf verschiedene Webserver erreichbar sind.

Eine sehr wichtige Entscheidung beim Entwurf einer Suchmaschine ist die Art der Speicherung der gesammelten Daten. Lycos [Lyc] verwendet beispielsweise eine "invertierte Dateiindizierung" (inverted file indexing). Das bedeutet, daß eine Liste aller vorkommenden Worte erstellt wird und zu jedem Wort in dieser Liste die Dokumente, in denen das Wort vorkommt, gespeichert werden. Außerdem wird die Position des Wortes im Dokument gespeichert, um feststellen zu können, ob mehrere Suchbegriffe nahe beieinander liegen.

Startet ein Benutzer nun einen Suchauftrag, so übergibt er dem Suchprogramm ein oder mehrere Schlüsselworte. Werden mehrere Suchbegriffe übergeben, so können diese meist mit logischen Operatoren wie Und bzw. Oder verknüpft werden. Manchmal auch mit dem logischen Operator Nicht, um bestimmt Inhalte von der Suche auszuschließen.

Diese Schlüsselworte werden im Index gesucht und die Dokumente, die diese Suchbegriffe enthalten, werden dem Benutzer zurückgeliefert. Da meist sehr viele Dokumente gefunden werden, ist es sinnvoll, wenn diese so sortiert werden, daß der Benutzer jene Dokumente als erstes geliefert bekommt, die seinem Suchauftrag am ehesten entsprechen.

Diese Sortierung kann nach mehreren Gesichtspunkten erfolgen, wie etwa die Zahl der Suchbegriffe, die im Dokument enthalten sind, oder ob diese im Titel vorkommen etc. Ein Suchprogramm ist ziemlich wertlos, wenn es eine Unzahl an gefundenen Dokumenten liefert, die relevantesten Dokumenten aber vom Benutzer erst "händisch" herausgesucht werden müssen.

WWW-Suchmaschinen stellen extreme Anforderungen an die Hardware, auf der die Suchmaschine läuft. Heutige Suchmaschinen indizieren bis zu 60 Millionen Webseiten. Diese Zahl wird in den nächsten Jahren sicherlich noch steigen. (Die ersten Suchmaschinen hatten gerade ein paar zehntausend Seiten im Index.) Sowohl Rechenleistung als auch Speicherkapazität dieser Rechner müssen im absoluten High-End Bereich liegen.

WWW-Suchmaschinen sind zwar sehr praktisch, haben aber einige große Nachteile. So ist der Aufwand der Informationsbeschaffung hoch. Jede einzelne Suchmaschine muß alle Dokumente, die sie indiziert, vom Netz laden und auswerten. Das bedeutet, daß eine Suchmaschine, die 60 Millionen Seiten indiziert hat, 60 Millionen mal ein Dokument aus dem Internet laden muß, um seinen Index zu erstellen. Außerdem muß der Index aktuell gehalten werden. Das heißt, daß die Dokumente regelmäßig neu geladen werden müssen, sofern sie sich geändert haben.

Die meisten Suchmaschinen indizieren nur Informationen eines bestimmten Typs (Webseiten, FTP-Dateien, Newsartikel etc.). Einige - wie Altavista - verwalten mehrere Typen, können aber nur alternativ nach einem Typ suchen. Ein weiterer Nachteil ist, daß die Suche in WWW-Suchmaschinen zentral organisiert ist. Der Index ist zentral auf einem Server gespeichert und alle Anfragen werden zentral an eine Maschine gerichtet. Das führt zu großer Netzwerkbelastung, wenn ein Suchdienst sehr viele Anfragen zu verwalten hat.

Harvest ist ein integriertes System von Werkzeugen zur Sammlung, Extrahierung, Organisation, und Suche von Informationen auf dem Internet. Ein Ziel beim Entwurf von Harvest war es, ein flexibles System zu schaffen, das viele Konfigurationsmöglichkeiten bietet, Indexe zu erstellen, Internetserver effizient zu benutzen und den Plattenplatz effizient zu nutzen.

Die beiden wichtigsten Komponenten von Harvest sind Gatherer und Broker. Ein Gatherer ist ein Programm, das - ähnlich wie bei den WWW-Suchmaschinen - Informationen im Internet sammelt und sie dem System zur Verfügung stellt. Genauer gesagt dem Broker. Dieser ist dafür zuständig, die vom Gatherer gesammelten Informationen zu indizieren und zu speichern.

Dabei wird auf größtmögliche Flexibilität und Effizienz geachtet. So kann ein Gatherer Daten für mehrere Broker sammeln. Dies verhindert, daß ein und die selben Daten mehrmals zusammengesucht werden müssen, wenn mehrere Broker die selben Informationen indizieren wollen.

Umgekehrt kann ein Broker Informationen von mehreren Gatherern erhalten. Damit kann ein effizientes System von Gatherern und Brokern erstellt werden, in dem mehrere Broker teilweise überschneidende Informationen speichern können, ohne daß das zu einer ineffizenten Netzwerkbelastung führt.

Es gibt mehrere Möglichkeiten, wie ein Gatherer Informationen sammeln kann. Eine davon ist die Verwendung von Standard-Internetprotokollen wie HTTP (HyperText Markup Language), FTP (File Transfer Protocol), Gopher oder NNTP (Network News Transfer Protocol). Damit können Systeme erfaßt werden, auf denen keine Harvest-Software läuft. Diese Art des Gathering hat natürlich etliche Nachteile.

So entsteht bei dabei - analog zu den WWW-Suchmaschinen - eine erhebliche Netzwerkbelastung. Auch wird der Rechner, auf dem der Gatherer läuft, stark belastet, da er sämtliche Daten selbst von den entsprechenden Servern holen muß. Außerdem müssen die für die Indizierung relevanten Daten aus der gesamten gesammelten Informationsfülle mühsam extrahiert werden.

Eine effizientere Möglichkeit ist, die Indexe lokal auf den Servern zu erstellen, auf denen die Daten gespeichert sind. Dies setzt natürlich voraus, daß der jeweilige Information-Provider entsprechende Software installiert hat, also mit Harvest "zusammenarbeitet". Am Hostrechner, auf dem die zu suchenden Daten gespeichert sind, läuft ein Gatherer, der nur die Informationen, die auf diesem Rechner gespeichert sind, sammelt.

Dies ist natürlich um einiges schneller und effizienter, als eine Suche über ein Netzwerk. Dies gilt umso mehr, umso langsamer das Netzwerk ist. Und das Internet ist langsam. Die Informationen werden lokal gesammelt und lokal abgespeichert. Dann werden diese gesammelten Informationen bei Bedarf an einen oder mehrere Broker geschickt.

Ein Broker speichert die Daten, die er von einem oder mehreren Gatherer(n) bekommt und stellt eine indizierte Abfrageschnittstelle zur Verfügung. Informationen werden aber nicht nur von den Gatherern bezogen. Es gibt auch die Möglichkeit, Informationen zwischen Brokern auszutauschen. Für diesen Zweck existiert ein spezielles "bulk transfer protocol". Der Broker erneuert seinen Index ständig mit neuen Daten, die er von den Gatherern und den anderen Broker bekommt.

Harvest bietet neben diesen Möglichkeiten noch weitere Funktionen wie einen Replikator, der es ermöglicht, Kopien der Broker-Datenbanken über das Internet zu verteilen, also diese Datenbanken zu replizieren. Weiters besteht die Möglichkeit, ein Objekt-Cache zu verwalten, in dem auf Daten über HTTP, FTP oder Gopher schnell und effizient zugegriffen werden kann. Außerdem können DNS-Lookups zwischengespeichert werden.

Alle Suchsysteme, egal ob Harvest oder eine WWW-Suchmaschine, haben aber einen entscheidenden Nachteil: Man kann nur nach exakten Suchbegriffen suchen. Andere Wörter mit ähnlicher oder gar gleicher Bedeutung werden nicht gefunden. Sucht man beispielsweise nach "Kühlschrank", so werden die Begriffe "Eisschrank", "Gefrierschrank" oder "Kühltruhe" nicht als Worte identifiziert, nach denen zu suchen ist. Wer auf dem Internet nach dem Wort "Kühlschrank" sucht, ist aber sicherlich auch an Seiten interessiert, auf denen das Wort "Eisschrank" vorkommt.

Man kann sich natürlich so helfen, daß man alle Variationen des Suchbegriffes eingibt und mittels logischer Oder-Verknüpfung nach allen diesen Begriffen sucht. Suchwerkzeuge sind aber vor allem dazu da, dem Benutzer die Suche zu vereinfachen und nicht zu erschweren. Wenn man vor jeder Suche überlegen muß, nach welchen Synonymen man noch suchen könnte, ist nicht unbedingt mehr von einer Erleichterung die Rede.

Es wäre daher sinnvoll, ein Werkzeug zu haben, das zu jedem Wort möglichst viele Synonyme findet. Diese Synonyme könnten dann automatisch vom Suchsystem hergenommen werden und in die Suche integriert werden. Werkzeuge die eben das leisten, sind bereits seit einiger Zeit unter dem Namen "Thesaurus" bekannt.

Was ist eigentlich ein Thesaurus? Laut der eher allgemeinen Definition nach DIN 1463 Teil 1 (Erstellung und Weiterentwicklung von Thesauri) ist "ein Thesaurus im Bereich der Information und Dokumentation eine geordnete Zusammenstellung von Begriffen und ihrer (vorwiegend natürlichsprachlichen) Bezeichnung, die in einem Dokumentationsgebiet zum Indexieren, Speichern und Wiederauffinden dient.''

Dabei gilt es zunächst, die Elemente, aus denen ein Thesaurus besteht, nämlich die Thesauruseinträge, genauer zu betrachten. Ein Thesauruseintrag ist ein Begriff, wie er in DIN 2330 festgelegt wurde, das heißt er besteht aus Intension, Extension und der Beziehung zu anderen Begriffen.

Als Intension wird in dieser Norm "die Gesamtheit der Merkmale, die eine gedankliche Zusammenfassung von individuellen Gegenständen und die gegenseitige Abgrenzung der Begriffe ermöglichen'' bezeichnet. Unter Extension versteht man wiederum nach DIN "die Gesamtheit aller individuellen Gegenstände, die sämtliche Merkmale dieses Begriffs haben''.

Thesauruseinträge stehen untereinander in Relationen. Grundsätzlich gibt es drei Arten von Thesaurusrelationen:

• Die Äquivalenzrelation ist die Beziehung zwischen gleichwertigen Bezeichnungen (Synonymie).
• Die Hierarchierelation gliedert sich wiederum in zwei verschiedene Unterarten:
• Die Abstraktionsrelation stellt die klassische Hierarchierelation in Thesauri dar, sie beschreibt die Relation zwischen Oberbegriff und Unterbegriff.
• Die Bestandsrelation beschreibt die Beziehung zwischen einem Ganzen und seinen Bestandteilen.
• Die Assoziationsrelation repräsentiert die Relation zwischen Begriffen, wenn diese weder eindeutig hierarchisch verbunden noch äquivalent sind.

Der Einsatz von Thesauri bietet sich überall an, wo es sinnvoll ist, Wörter mit gleicher bzw. ähnlicher Bedeutung zu finden. Das wohl bekannteste Einsatzgebiet von Thesauri sind Textverarbeitungen. Jedes moderne Textverarbeitungssystem hat heute einen eigenen Thesaurus integriert. Autoren, die für einen Begriff ein Synonym oder ein Wort mit ähnlicher, aber nicht exakt gleicher Bedeutung finden wollen, können die Dienste dieser Zusatzprogramme in Anspruch nehmen.

Thesauri wurden für viele Anwendungsgebiete entwickelt. Das sicherlich wichtigste Anwendungsgebiet sind aber Suchprogramme. Nur in seltenen Fällen wird ein Benutzer ausschließlich nach genau einem Suchbegriff suchen und Begriffe mit gleicher oder ähnlicher Bedeutung ignorieren wollen. Meist wird nach einem bestimmten Thema innerhalb irgendeines Gebietes gesucht und es soll alles gefunden werden, das dieses Thema tangiert.

Eine WWW-Suchmaschine, die einen Thesaurus verwendet, ist Excite [Exc]. Excite sucht nach Eingabe eines Suchbegriffes aber nicht selbständig auch nach Dokumenten mit Synonymen oder Wörtern mit ähnlicher Bedeutung, sondern bietet diese Begriffe dem Benutzer zur Auswahl an. Dieser kann eines oder mehrere der angebotenen Begriffe markieren und die Suche damit erweitern.

Außerdem bietet Excite an, zu jeder gefundenen Seite "ähnliche" Seiten zu suchen. So kann man sich bei der Suche quasi "semantisch" an die gesuchte Seite herantasten. Wer beispielsweise nach den Olympiasiegern im Dressurreiten aus dem Jahre 1980 sucht, wird bei einer herkömmlichen Suchmaschine mit dem Stichwort sport nicht viel Glück haben.

Findet man aber mit Excite damit eine Seite über Reiten, kann man mit der Suche nach "ähnlichen" Seiten verschiedene Informationen über das Reiten finden. Dort kann man vielleicht eine Seite über Wettbewerbe finden und so langsam zur gewünschten Information vorstoßen. Natürlich wäre es in diesem Beispiel einfacher, gleich nach "Olympia 1980" zu suchen. Aber es veranschaulicht gut das verwendete Prinzip.

Es ist anzunehmen, daß in Zukunft kein Suchdienst auf dem Internet "überleben" wird, der nicht einen Thesaurus in irgendeiner Form anbietet. Entweder wird automatisch nach Synonymen gesucht, oder dem Benutzer werden Synonyme optional angeboten. Langfristig werden sich sicherlich Thesauri etablieren, die mit natürlichsprachlichen Ausdrücken wie "Welches Automodell von Wartburg bietet die größte Beschleunigung?" umgehen können. Bis dahin ist aber noch ein langer Weg zurückzulegen…

Wenn heute über das Internet diskutiert wird, ist das am häufigsten angeschnittene Thema die Sicherheit. Die Protokolle und die Struktur des Internet sind nicht darauf ausgelegt, die übertragenen Daten zu schützen. Dies mag aufgrund der Tatsache, daß dieses Netz ursprünglich zu militärischen Zwecken entworfen wurde, etwas verwundern. Man ist aber beim Entwurf des ARPANET nicht davon ausgegangen, daß es Teilnehmer in diesem Netzwerk gibt, die nicht vertrauenswürdig sind.

Heute, wo jeder, der sich einen PC und ein Modem leisten kann, problemlos ins Internet gelangen kann, kann von der Voraussetzung, daß jeder Teilnehmer des Netzwerkes vertrauenswürdig ist, natürlich nicht mehr ausgegangen werden. Die Anzahl der "zwielichtigen Gestalten" im Internet nimmt in gleichem Maße zu, wie die Gesamtzahl der Teilnehmer.

Mögliche Angriffspunkte, an denen potentielle Angreifer Interesse zeigen könnten, gibt es in großer Zahl. Das Ausspähen von Kreditkartennummern, das Lesen von persönlichen Daten, das Belauschen von privater Kommunikation sind nur einige Beispiele dafür. All diese Dinge sind im heutigen Internet verhältnismäßig einfach zu realisieren.

Viele Internetbenutzer sind sich dieser Gefahr überhaupt nicht bewußt. Sehr vertrauliche Informationen werden oft über ganz normale e-Mail Protokolle wie SMTP im Klartext verschickt. Kreditkartennummer werden über HTTP bedenkenlos an einen Anbieter geschickt. Den meisten Benutzern genügt es, daß der Empfänger ihrer Kreditkartennummer vertrauenswürdig ist, aber an die unsichere Übertragung denkt kaum jemand.

Mit der immer stärkeren Verbreitung des Internet und der steigenden Kommerzialisierung dieses Netzwerkes werden diese Probleme immer kritischer, sodaß der Ruf nach einer Lösung dieser Probleme immer lauter wird. Viele Firmen sehen in der Möglichkeit, über das Internet ihre Produkte einer riesigen Zahl von möglichen Kunden anbieten zu können, zwar eine große Chance, aber wegen der großen Sicherheitsmängel scheitert meist die Realisierung derartiger Projekte.

Es müssen also Mittel und Wege gefunden werden, die Sicherheit im Netz zu erhöhen. Teilweise sind bereits sehr gut funktionierende Sicherheitsmaßnahmen realisiert, die bestimmte Teilbereiche der Sicherheitsfrage im Internet abdecken. So können die gängigsten Webbrowser wie etwa der Netscape Navigator die übertragenen Daten verschlüsseln.

Hier taucht aber das Problem auf, daß diese Browser in den USA geschrieben wurden und die darin verwendeten Verschlüsselungsalgorithmen den amerikanischen Ausfuhrbeschränkungen unterliegen. Deshalb können Browser mit der voll funktionsfähigen Verschlüsselung nur in den USA vertrieben werden.

Verschlüsselung von Daten ist überhaupt eine sehr gute Methode, um übertragene Daten vor neugierigen "Mithörern" zu schützen. Wenn man schon nicht verhindern kann, daß jemand die übertragenen Daten zu sehen bekommt, so kann man doch verhindern, daß derjenige mit diesen Daten etwas anfangen kann.

Die Verschlüsselung von Nachrichten geht bis in die Zeit der Antike zurück. Julius Cäsar wird zugeschrieben, eine Verschlüsselungsmethode erfunden zu haben, die auf dem Prinzip der Buchstabenersetzung beruht [BSSS90]. Jeder Buchstabe des Alphabets wird durch einen anderen ersetzt, sodaß die verschlüsselte Nachricht einen Kauderwelsch an scheinbar zufällig aneinandergereihten Buchstaben ergibt.

Natürlich ist das eine sehr primitive Methode, sie ist aber geeignet, um einem Angreifer die Informationsbeschaffung erheblich zu erschweren, bzw. es ihm unmöglich zu machen, schnell zwischen interessanter und nicht interessanter Information zu unterscheiden. Dies ist ebenfalls ein wichtiges Prinzip in der Kryptographie, wie die Wissenschaft der Verschlüsselung genannt wird: Wenn der Angreifer nicht weiß, welche (verschlüsselte) Information für ihn interessant ist, ist es erheblich schwerer für ihn, diese Information zu erhalten.

So wurden im Zweiten Weltkrieg etwa geheime Codewörter an Widerstandsgruppen über das Radio gemeinsam mit hunderten sinnlosen Wörtern verbreitet. Ein nicht eingeweihter Zuhörer konnte nicht zwischen den Codewörtern und den zusätzlich eingestreuten Wörtern unterscheiden. Dies machte eine Analyse der Codewörter nahezu unmöglich.

Hier sieht man aber gleich eine weitere Problematik, die sich bei der Kryptographie auftut: Wenn man jemandem eine verschlüsselte Nachricht zukommen lassen will, so muß man ihm auch den Schlüssel geben, mit dem er die Information entschlüsseln kann. Dieser Schlüssel muß auf sicherem Wege dem Empfänger überbracht werden. Wenn aber ein solcher sicherer Weg existiert, kann auf diesem auch gleich die geheime Information überbracht werden, sodaß Kryptographie unnötig wird.

Ideal wäre ein Verschlüsselungssystem, bei dem man dem Empfänger den Schlüssel zur Entschlüsselung der Information nicht zukommen lassen muß. Wenn es einen Schlüssel zur Verschlüsselung der Information und einen - anderen - Schlüssel zur Entschlüsselung der Information gibt (den nur der Empfänger hat), so kann eine Nachricht auf einem unsicheren Weg zum Empfänger geschickt werden, ohne daß zusätzlich ein sicherer Weg für den Austausch der Schlüssel gefunden werden muß.

Im Jahre 1978 wurde von Rivest, Shamir und Adleman eine Methode veröffentlicht, die Verschlüsselung - wie oben beschrieben - mit öffentlichen Schlüsseln ermöglicht (public key encryption). Das Verfahren wurde nach den Anfangsbuchstaben seiner Erfinder RSA-Verfahren genannt [RSA78].

Das Verfahren arbeitet nach einem komplizierten mathematischen Algorithmus, auf den hier nicht näher eingegangen werden soll. Das Prinzip von RSA beruht darauf, daß es relativ leicht ist, sehr große Primzahlen zu finden, es aber sehr schwer ist, sehr große Zahlen in ihre Primfaktoren zu zerlegen.

RSA arbeitet mit dem Produkt aus zwei großen Primzahlen, aus dem eine Zahl errechnet wird, die als öffentlicher Schlüssel verwendet wird. Gleichzeitig wird eine Zahl berechnet, die als privater Schlüssel verwendet wird. Nur wenn es einem Angreifer gelingt, dieses Produkt in seine Primfaktoren zu zerlegen, kann er den Code knacken.

RSA gilt als "sicherer" Code. Das bedeutet, es ist einem Angreifer (mit bester EDV-Ausstattung!) nicht in vernünftiger Zeit möglich, den Code zu knacken. Voraussetzung dafür ist natürlich, daß die verwendeten Schlüssel entsprechend groß sind. Um einen RSA-Code mit 1024 Bit zu knacken, müßte man mit heutigen Supercomputern einige Milliarden Jahre rechnen. Soviel Zeit hat kaum ein Angreifer…

Eine weitere sehr interessante Eigenschaft dieser Verschlüsselungsmethode ist, daß die Ver- und Entschlüsselung "in beide Richtungen" funktioniert. Das heißt, daß eine Information, die mit dem ersten Schlüssel verschlüsselt ist, mit dem zweiten entschlüsselt werden kann und eine Information, die mit dem zweiten Schlüssel verschlüsselt worden ist, wiederum mit dem ersten entschlüsselt werden kann.

Dadurch ist es möglich, sogenannte "digitale Unterschriften" zu realisieren. Wenn jemand eine Nachricht mit dem eigenen - privaten - Schlüssel verschlüsselt, kann jeder sie mit dem öffentlichen Schlüssel entschlüsseln. Gelingt dies, ist sichergestellt, daß die Nachricht wirklich von diesem Sender stammt. Denn nur er ist im Besitz seines privaten Schlüssels.

Die RSA-Verschlüsselung ist so gut, daß es in einigen Ländern verboten ist, diese Verschlüsselungsmethode anzuwenden. Während es in der Vergangenheit für Geheimdienste, Polizei etc. immer Möglichkeiten gab, Kommunikation abzuhören (Telefon anzapfen, Briefe öffnen…), existiert nun eine Möglichkeit, Informationen offen zu transportieren, ohne daß ein anderer, außer dem Empfänger, etwas damit anfangen kann.

Dies beängstigt einige Regierungen. So wurde in den USA beispielsweise versucht, für die Verschlüsselung von Daten einen bestimmten Algorithmus vorzuschreiben, mit dem die Entschlüsselung durch die staatlichen Behörden möglich geworden wäre. Diese Verschlüsselung sollte mit Hilfe eines bestimmen Chips realisiert werden. Dieser Chip hat unter dem Namen "Clipper-Chip" Berühmtheit erlangt. Diese Pläne wurden von der US-Regierung aber wieder fallen gelassen.

Anfang der 90er Jahre veröffentlichte Philip Zimmermann ein Programm namens Pretty Good Privacy (PGP). Dieses Programm verschlüsselte Daten mittels des RSA-Algorithmus. Dadurch war sichere Kommunikation nicht mehr ein Vorrecht für Geheimdienste und Kryptographieexperten, sondern wurde zum Allgemeingut. PGP leistete alles, was RSA zu leisten vermag, inklusive digitaler Unterschriften.

Wenn zuvor gesagt wurde, daß die digitale Unterschrift sicherstellt, daß eine Nachricht vom entsprechenden Empfänger stammt, so ist das nur bedingt richtig. Das einzige was wirklich sichergestellt ist, ist daß die Nachricht vom Besitzer dieses Schlüssels stammt. Wer dieser Besitzer nun wirklich ist, ist überhaupt nicht sicher.

Um diese Sicherheitslücke, die das ganze System ad absurdum führen würde, zu schließen, wurde ein besonderes System zur Zertifizierung von Schlüsseln erdacht. Wenn man einen Schlüssel direkt vom Besitzer bekommt, kann man sicher sein, den richtigen Schlüssel erhalten zu haben. Man kann diesen Schlüssel dann "signieren". Dies geschieht dadurch, daß man seine digitale Unterschrift unter diesen Schlüssel setzt.

Durch diese Vorgangsweise garantiert man dafür, daß der signierte Schlüssel "echt" ist. Wenn jemand einen Schlüssel findet, der von einer Person, der er vertraut, signiert wurde, kann er sicher sein, daß es sich um einen Schlüssel handelt, der tatsächlich der betreffenden Person gehört. Dadurch wird das Risiko, daß gefälschte Schlüssel verwendet werden, erheblich reduziert, wenn nicht gar ausgeschlossen.

Die neuesten Versionen von PGP (derzeit liegt die Version 5.0 vor) verwenden nicht mehr (oder nur mehr optional) RSA, sondern ein Verfahren, das DSS/Diffie-Hellman genannt wird. Dieses Verfahren bietet die gleichen Möglichkeiten wie RSA, ist aber bereits weiter entwickelt. Mit PGP 5.0 können etwa Schlüssel bis 4096 Bit Länge verwendet werden.

Viele namhafte Kryptologen der zivilen Welt haben in den letzten Jahren versucht, RSA bzw. PGP zu knacken. Bisher ist es nicht gelungen. Es ist natürlich nicht bekannt, ob irgendwelche Geheimdienste eine Möglichkeit gefunden haben, PGP zu knacken. Da aber in vielen Staaten überlegt wird, PGP zu verbieten und die US-Regierung selbst dem RSA-Algorithmus zur Verschlüsselung ihrer sensibelsten Daten vertraut, kann mit an Sicherheit grenzender Wahrscheinlichkeit davon ausgegangen werden, daß PGP von niemandem geknackt werden kann.

Im Jahre 1993 erhielt Philip Zimmermann, der Erfinder von PGP, übrigens eine Vorladung des Distriktgerichts von Nordkalifornien. Man warf ihm vor, gegen die Exportbeschränkungen für Kryptographie verstoßen zu haben. Das Verfahren wurde inzwischen aber wieder eingestellt.

Grundsätzlich kann über das Internet gesagt werden, daß es ein System ist, das für wesentlich kleinere Aufgaben konzipiert und eingeführt wurde, als derzeit über dieses Netz laufen. Niemand hatte in den Sechziger Jahren daran gedacht, daß jede Privatperson einmal seinen eigenen Rechner haben wird und daß jeder über das Internet multimediale Daten im Umfang von mehreren Megabytes laden können wird.

Zu viele Aspekte, die heute im Internet relevant sind, wurden bei der Konzeption des Netzwerkes berechtigterweise ignoriert. Deshalb ist es an der Zeit, das Internet an die Erfordernisse der heutigen Zeit anzupassen. Dies soll nun im folgenden Kapitel versucht werden.

Die Namensgebung, die Zugriffsstrategien und die Sicherheit im Internet lassen derzeit sehr zu wünschen übrig. Der Name eines Objektes im Internet (Webseite, Datei, Bild etc.) muß bekannt sein, um das Objekt abrufen zu können, dieser Name ist oft sehr kompliziert und wenn das Objekt den physikalischen Ort wechselt, ändert sich dieser Name.

Auch ist es oft so, daß sich Objekte - etwa Dateien auf FTP-Servern - mehrfach an verschiedenen Orten im Internet befinden. Oft wäre es möglich, eine solche Datei schneller und mit geringerer Belastung der Fernverbindungen von einem näher gelegenen Rechner zu holen, wenn man nur wüßte, wo sich alle Kopien dieser Dateien befinden.

Ein weiterer wichtiger Aspekt im Internet ist die Sicherheit. Früher, als das Internet fast ausschließlich zum Informationsaustausch zwischen universitären Einrichtungen zu Forschungszwecken diente, mußte dem Sicherheitsaspekt wenig Aufmerksamkeit geschenkt werden. Niemand war interessiert, diese Kommunikation "abzuhören", und es gab keine sensiblen Daten, die auf Internetrechnern gespeichert waren.

Heute, wo alle möglichen Arten von Informationen über das Internet ausgetauscht werden, werden auch sensible oder gar geheime Daten auf die Reise durch das Netz geschickt. Auch Daten, die eigentlich nicht in das Internet gelangen sollten, aber über lokale Netzwerke von im Internet befindlichen Rechnern erreicht werden können, sind ständig gefährdet, von "Hackern" ausspioniert zu werden.

Durch die immer weiter fortschreitende Kommerzialisierung des Internet taucht immer öfter die Forderung nach einer Möglichkeit der Bezahlung - also Geldüberweisung - über das Internet auf. Firmen, die ihre Produkte im Internet anbieten, wollen diese auch gleich über dieses Netzwerk verkaufen können. Solche Geldsendungen können natürlich nicht einfach durch eine simple Datenübertragung durchgeführt werden. Viel zu groß sind die Risiken von Mißbrauch und Übertragungsfehlern.

Daten müssen also entsprechend geschützt werden. Es muß ausgeschlossen werden, daß jemand, der Informationen nicht bekommen soll, diese abrufen kann. Das hört sich eigentlich recht einfach an, ist aber nicht leicht zu realisieren. Schließlich legen die Daten auf ihrer Reise durch das Internet im allgemeinen einen langen Weg über viele Zwischenstationen zurück. Jede Verbindung und jede Zwischenstation ist ein potentieller Angriffspunkt für einen "Lauschangriff".

Es ist also Zeit, sich Gedanken über die Lösung dieser anstehenden Probleme zu machen. Genau das soll in dieser Arbeit versucht werden. Es soll eine Möglichkeit gesucht werden, alle Informationen im Internet leicht zu adressieren, das Migrations- und Replikationsproblem zu lösen und dabei dem Sicherheitsaspekt Rechnung zu tragen.

Um dieses Ziel zu realisieren, wurde der CoordinationKernel ausgewählt, um als Basis für dieses neue System zu dienen. Wie bereits in Kapitel 2 erläutert, sind im CoKe bereits Lösungen für das Migrations- und das Replikationsproblem enthalten. Die noch offenen Probleme sind also das Problem der Namensgebung und das Sicherheitsproblem.

Im Anschluß werden einige Voraussetzungen erläutert, die erfüllt sein müßten, um ein derartiges System einführen zu können und danach wird ein System entworfen, das die erwähnen Probleme mit Hilfe des CoKe lösen kann.

Das Internet ist praktisch nicht strukturiert. Es existieren nur die zugrundeliegenden Protokolle und die Standards der einzelnen Internetdienste. Ansonsten gibt es fast keine Einschränkungen oder Strukturen in diesem Netzwerk. Jeder, der einen physikalischen Anschluß an das Internet hat, kann sich eine IP-Nummer besorgen, und einen Rechner ins Internet hängen.

Er muß sich nirgendwo anmelden, geschweige denn eine Genehmigung dafür einholen. Es gäbe auch gar nicht die Möglichkeit, eine solche Anmeldung durchzuführen, da es keine zentrale Stelle gibt, die für die "Verwaltung" des Internet zuständig wäre. Das Internet gehört niemandem und es wird von niemandem kontrolliert.

Viele bezeichnen daher das Internet als den "elektronischen Wilden Westen" oder eine "digitale Anarchie". Durch zwielichtige Inhalte wie Pornographie oder Homepages von radikalen Gruppen kam mehrmals die Forderung nach einer Reglementierung des Internet auf. Als darüber nachgedacht wurde, wie eine solche Reglementierung durchgeführt werden könnte und durch einige Versuche, Newsgruppen mit einschlägigem Inhalt zu sperren, ist man zur Einsicht gekommen, daß solche Reglementierungen eigentlich nicht durchzusetzen sind.

Wer eine Newsgruppe beispielsweise bei einem bestimmten Provider nicht bekommen kann, verbindet sich eben mit einem öffentlichen Newsserver im Internet und kommt so zur gewünschten Information. Das Unzugänglichmachen einer Information ist auch schon deshalb unmöglich, da niemand weiß, wo diese Information überall gespeichert ist. Im USENET befinden sich die Artikeln beispielsweise auf sehr vielen Servern auf der ganzen Erde.

Aber auch im WWW gibt es kein vollständiges Inhaltsverzeichnis, anhand dessen man feststellen könnte, welche Informationen sich im Web befinden und welche nicht. Es existieren zwar Suchmaschinen für das WWW die derzeit bis zu 60 Millionen Seiten indiziert haben, aber auch diese Suchmaschinen (etwa Lycos [Lyc] oder Alta Vista [Alt]) haben nur einen Teil des gesamten WorldWideWeb registriert.

Wenn man also ein System einführen will, mit dem der Zugriff auf Internetressourcen geregelt werden soll, muß man erst dafür sorgen, daß der Inhalt des Internet besser strukturiert ist. Dies wird natürlich niemals vollständig möglich sein, aber es sollte wenigstens eine Möglichkeit geben, festzustellen, ob neue Inhalte ins Internet gekommen sind. Wenn nämlich jeder, so wie derzeit, einfach Dateien kommentarlos ins Internet "hineinwerfen" kann, ist jeder Versuch, den Inhalt des Internet besser zu organisieren von vorn herein zum Scheitern verurteilt.

Wird in die Adressierung und den Zugriff auf die Informationen derart weitreichend eingegriffen, wie es die vorliegende Arbeit vorschlägt, müßte natürlich das gesamte Internet auf dieses System umgestellt werden. Dazu wäre ein breiter Konsens unter den Teilnehmern im Internet notwendig. Denn die einzige Institution, die es schaffen kann, der ganzen Welt neue Standards aufzuzwingen, ist eine große Softwarefirma in Redmond, USA.

Um Sicherheitsaspekten Rechnung tragen zu können, muß es eine Möglichkeit geben, einzelne Benutzer oder Benuztergruppen zu identifizieren. Dies ist kein einfaches Problem, da es etliche Millionen von Internetbenutzern gibt, die oft anonym an öffentlichen Terminals Zugang zum Internet haben. Diese Arbeit geht nicht darauf ein, wie die Benutzer des Internet erfaßt und registriert werden. Vor der Realisierung von Web&Co ist dieses Problem noch zu lösen.

Ein weiterer Vorteil, um Web&Co effizient realisieren zu können, wäre es, wenn der CoKe das selektive Laden von replizierten Objekten unterstützen würde. Damit könnte erreicht werden, daß jeweils jene Objekte geladen werden, die am schnellsten vom Netz geholt werden könnten.

Um die Probleme der Namensgebung, Migration, Replikation und Sicherheit im Internet zu lösen, soll hier ein Lösungsansatz entwickelt werden, dem der CoKe als zugrundeliegendes Middlewaresystem dient. Derzeit ist die Situation so, daß Dateien einfach auf Rechnern "herumliegen" und mittels bestimmter Protokolle einfach von dort gelesen und versendet werden.

Es gibt viele Dienste im Internet, aber jener, der die Entwicklung des Internet heute am stärksten prägt, ist das WorldWideWeb. Dieses vereint, wie bereits in Kapitel 3 erwähnt, auch viele andere Dienste des Internet in sich. Deshalb beschränkt sich die hier entworfene Lösung auf das WWW.

Jene Dienste, die vom WWW nicht erfaßt werden, wie etwa IRC (Internet Relay Chat) bleiben unberücksichtigt. Dabei handelt es sich aber durchwegs um Dienste, die einen sehr geringen Anteil am Datenverkehrsaufkommen im Internet haben und meist auch mit flüchtigen - also nicht dauerhaft gespeicherten - Daten arbeiten.

Web&Co liegt das Middlewaresystem CoKe zugrunde. Damit ein CoKe-System funktioniert, muß eine Instanz des CoKe auf jedem beteiligten Rechner laufen. Diese Instanzen regeln die Objektverwaltung dann untereinander. Alle Rechner, die an Web&Co beteiligt sind, haben also immer einen CoKe laufen. Am besten ist es, wenn der CoKe gleich beim Einschalten einer solchen Maschine automatisch gestartet wird.

An den physikalischen Verbindungen der Rechner untereinander muß nichts verändert werden. Ein Rechner, der am Internet hängt, kann von jedem anderen Internetrechner erreicht werden. Somit ist sichergestellt, daß die CoKe-Instanzen immer Kontakt zueinander haben können.

Die Inhalte von Web&Co sind als CoKe-Objekte organisiert. Jedes Element einer Webseite (Text, Bilder, Sound…) ist ein eigenes Objekt mit eigener OID. Alle diese Objekte werden durch ihre OID eindeutig im gesamten System identifiziert und können über diese OID abgerufen werden.

Auch Dateien eines FTP-Servers sind als solche Objekte ausgeführt. Sie können über die Browseroberfläche abgerufen werden, wie es auch jetzt schon möglich ist. Ebenso verhält es sich mit Gopherseiten und mit Newsartikeln.

Dadurch, daß alle Internetobjekte als CoKe-Objekte realisiert sind, löst sich automatisch das Migrations- und Replikationsproblem, da der CoKe als Middlewaresystem diese Aufgaben übernimmt. Da ein Objekt nicht über den Ort seiner Speicherung angesprochen wird, ändert ein Wechsel dieses Ortes nichts an seiner ID. Und dadurch, daß der CoKe den Ort der Speicherung vom Benutzer abschirmt, weiß dieser nicht einmal, wo sich das betreffende Objekt überhaupt befindet.

Auch Replikation ist ein Punkt, der vom CoKe übernommen wird. Transparent für den Benutzer werden mehrere Kopien eines Objektes im System gehalten. Wo sich diese Kopien befinden und welche der Kopien beim Abruf des Objektes zurückgeliefert wird, ist allein Sache des CoKe und für den Benutzer unsichtbar.

Damit sind bereits zwei Probleme gelöst, die dem Internet derzeit schwer zu schaffen machen. Daten, die ihren Speicherort wechseln, ändern dadurch nicht mehr ihren Namen. Daten, die mehrfach vorhanden sind, sind dem System alle bekannt und können selektiv abgerufen werden.

Da die Objekte über ihre OID referenziert werden, gibt es keine Links, die nirgendwohin zeigen. Das jeweilige Objekt wird vom CoKe immer gefunden und korrekt zurückgeliefert. Es kann also nicht mehr vorkommen, daß ein Verweis auf eine Internetseite seine Gültigkeit verliert.

Die Browser, die Web&Co benutzen, können im Prinzip genau so ausgeführt sein, wie die heutigen Webbrowser von Netscape oder Microsoft. Für den Endbenutzer (den "Surfer") wird sich also mit Umstellung auf dieses System nicht viel ändern. Geändert werden muß nur die Art des Browsers, die gewünschten Daten abzurufen. Anstatt Verbindung mit einem Server im Internet aufzunehmen und auf dieser die gewünschten Daten vom dortigen HTTP-Server entgegenzunehmen, muß er den Request an den lokalen CoKe übergeben und warten, bis dieser das gewünschte Objekt zurückliefert. Das kann der Browser dann wie gewohnt darstellen.

Wesentlich größere Änderungen stehen den Informationsanbietern bevor. Es reicht jetzt natürlich nicht mehr, einfach ein paar Dateien zu erzeugen und in einem bestimmten Verzeichnis abzuspeichern, um sie der Öffentlichkeit im WWW zugänglich zu machen. Die Dateien müssen in CoKe-Objekte umgewandelt werden und ihre OIDs als Referenz auf diese Objekte verwendet werden.

Dazu ist es notwendig, entsprechende Entwicklungswerkzeuge zur Verfügung zu stellen. Ein Web&Co-Compiler kann lokale Dateien in CoKe-Objekte umwandeln, und diese an die lokale CoKe-Instanz übergeben. Um den Umstieg auf das neue System so einfach wie möglich zu machen, sollte der Web&Co-Compiler mit herkömmlichen HTML-Dateien arbeiten können. So müssen bereits existierende Web-Seiten nur mehr mit dem Web&Co-Compiler "übersetzt" werden.

Eine Web&Co-Seite wird also erst im HTML-Format erzeugt, und dann compiliert. Dadurch können auch die reichlich auf dem Markt befindlichen HTML-Autoren-Werkzeuge bzw. -Editoren weiterhin eingesetzt werden. Der Web&Co-Compiler hat die Aufgabe, den HTML-Code in ein CoKe-Objekt zu "packen", für jede Ressource, die von der Seite verwendet wird (Bilder, Sounds, Java-Programme…) eigene CoKe-Objekte zu erzeugen, und einen Verweis auf diese Objekte in den HTML-Code einzubauen.

Außerdem muß der Web&Co-Compiler die Möglichkeit bieten, Objekte wieder zu löschen. Wird ein Web&Co-Objekt gelöscht, muß der Compiler auch die Option bieten, darin enthaltene Objekte (etwa Bilder) gleich mitzulöschen.

Es könnte auch Web&Co-Editoren geben, mit denen Webseiten wie mit heutigen HTML-Editoren erstellt werden können. Am Ende der Erstellung legt der Web&Co-Editor für jedes erstellte Objekt (HTML-Seite, Bild, Sound…) ein CoKe-Objekt an. Der Entwickler kann die Objekte verändern und wieder löschen. Im Prinzip ist so ein Editor nur eine Oberfläche für den Web&Co-Compiler, der entweder in diesen Editor integriert ist, oder von diesem nach Erstellung der HTML-Seiten aufgerufen wird.

Wenn der Web&Co-Editor geschickt programmiert ist, ist die Tatsache, daß die Objekte eigentlich über OIDs identifiziert werden für den Entwickler völlig transparent. Er tippt einen Namen für die Seite ein und der Editor compiliert die Seite und erstellt die notwendigen CoKe-Objekte.

Selbstverständlich muß in diesem Fall auf dem Entwicklungsrechner ebenfalls ein CoKe laufen, ansonsten können ja keine Objekte erstellt werden. Auf Rechnern, auf denen der CoKe nicht läuft, müssen die Dateien im HTML-Format erstellt werden und auf einem CoKe-Rechner mit dem Web&Co-Compiler in das endgültige Format konvertiert und der Allgemeinheit zur Verfügung gestellt werden.

So wie sich in einer heutigen HTML-Datei Verknüpfungen mit Graphikdateien, Sounds oder Java-Programmen befinden, die dann im Browser dargestellt werden, können sich in einer Web&Co-Datei Verknüpfungen mit anderen Objekten befinden. Dies kann sogar noch weiter gehen. Anstatt nur eingebettete Objekte (wie Bilder) kann man auch HTML-Fragmente wie Tabellen oder formatierten Text einbinden. Dadurch wird es möglich, Webseiten modular aufzubauen.

Derzeit muß eine HTML-Datei ja aus einer einzigen, kompletten Datei auf der Festplatte vorliegen. Wenn man einen Teil des Inhaltes ändern will, muß man die komplette Datei hernehmen, und den entsprechenden Teil des Inhaltes verändern und dann die komplette Datei wieder speichern. Das ist sehr problematisch, wenn z. B. mehrere Personen für verschiedene Teile der Seite verantwortlich sind, oder wenn die Datei vom einem Programm oder Skript automatisch generiert und verändert werden soll.

Wenn man in Web&Co beispielsweise eine Datei hat, die eine Preisliste und ein Telefonverzeichnis enthält, kann eine Rumpfdatei erstellt werden, in die dann Tabellen mit Preisen und Telefonnummern eingebunden werden. Diese liegen als separate CoKe-Objekte vor und werden erst beim Clientbrowser zusammengefügt. Dies erleichtert natürlich die Wartung der Daten, da nur das betreffende Objekt mit den betreffenden Daten verändert werden muß.

Da wirklich alle relevanten Daten als CoKe-Objekte vorliegen, braucht ein Informationsanbieter auch keinen HTTP-Server mehr. Die Objekte werden vom CoKe verwaltet und nicht mehr von einem bestimmten Rechner. Während es heute so funktioniert, daß ein Rechner die betreffende Datei verwaltet, also auf einen Request hin liest und zurückliefert, übernimmt der CoKe das in Web&Co mit seinen Middlewarediensten. Der CoKe findet die Objekte und liefert sie selbständig auf Anforderung zurück.

Auch die Wartung der Objekte wird dadurch flexibilisiert. Der "Webmaster" kann die Objekte auf allen Rechnern, auf denen der CoKe läuft, in einen Web&Co-Editor laden und manipulieren. Um zu gewährleisten, daß nur berechtigte Personen ein Objekt verändern oder löschen können, sind zu jedem Objekt die Informationen gespeichert, wer auf dieses Objekt Zugriffsrechte hat. Dies wird im Punkt "Sicherheit in Web&Co" noch genauer behandelt.

Um den Benutzern des Internet den Umstieg auf Web&Co zu erleichtern, bzw. um die Hemmschwelle für den Umstieg herabzusetzen, wird zur Namensgebung in Web&Co auf die Struktur des bestehenden "Domain Name System" (DNS) zurückgegriffen. Der Namensraum im DNS ist hierarchisch organisiert, was bei einer Zahl von einigen hundert Millionen Objekten unumgänglich ist. Weiters braucht sich niemand Gedanken über die neuerliche Aufteilung des Namensraumes zu machen, weil mit dem DNS bereits eine gute Lösung dafür vorhanden ist.

Für die Namensgebung in Web&Co gibt es zwei verschiedene Arten von Objekten: Domänenobjekte und Verzeichnisobjekte. Ein Domänenobjekt ist vergleichbar mit einem DNS-Server, der eine bestimmte Domäne verwaltet (etwa tuwien.ac.at). Domänenobjekte bilden eine Baumstruktur, in der jeder Knoten eine Domäne repräsentiert. (Siehe Abb. 2)

Jede Hierarchieebene wird dabei von einem Domänenobjekt repräsentiert. Jedes dieser Domänenobjekte enthält die Domänen-Namen der nächsten Hierarchieebene und jeweils einen Verweis auf das entsprechende nächste Domänenobjekt, welches die betreffende Domäne repräsentiert. Dadurch entsteht die oben beschriebene Baumstruktur, in der die Knoten Domänenobjekte und die Blätter Verzeichnisobjekte sind. Das oberste Domänenobjekt, welches die Verweise auf die "Top-Level"-Domänen enthält, heißt NameServer.

Die Verzeichnisobjekte wiederum enthalten ein Verzeichnis von Web&Co-Objekten mit dem Namen des Objektes und einem Verweis auf das entsprechende CoKe-Objekt. Natürlich kann auch ein solches Verzeichnis hierarchisch organisiert sein. Dies wird einfach dadurch realisiert, daß ins Verzeichnis ein Verweis auf ein weiteres Verzeichnisobjekt eingefügt wird. Dies ist vergleichbar mit den Verzeichnissen eines Dateisystems, das wiederum Verzeichnisse enthält.

Neben dem Namen eines Web&Co-Objektes werden auch noch andere wichtige Informationen in einem Verzeichnisobjekt gespeichert. Der Zeitpunkt der Erstellung und der letzten Änderung (jeweils im UTC-Format), Zugriffsinformationen (wer darf diesen Eintrag überhaupt sehen?) und natürlich die Information, wer der "Eigentümer" des Objektes ist. Dies wird in der Regel der Ersteller des Objektes sein.

Weiters ist noch die Möglichkeit für zukünftige Einträge in das Verzeichnis vorgesehen. Es könnte z. B. einmal einen Verweis auf ein Objekt mit gleichem Inhalt aber anderer Darstellung eingefügt werden, oder Informationen, daß die Inhalte im entsprechenden Objekt kostenpflichtig sind, und wieviel für das Laden dieses Objektes zu bezahlen ist. Im Prinzip ist die Menge der möglichen Erweiterungen unabschätzbar groß. In einigen Jahren könnte es bereits Features geben, an die heute noch gar niemand denkt.

Wie sehen nun diese Domänenobjekte und Verzeichnisobjekte aus? Ein Domänenobjekt enthält nichts anderes als die Namen der Subdomänen und die OID der CoKe-Objekte, die diese Subdomänen repräsentieren, bzw. die Namen und OIDs der Verzeichnisobjekte, die zu dieser Domäne gehören. Der Inhalt eines Domänenobjektes ist in Abb. 3 dargestellt.

Wird nun etwa ein Web&Co-Objekt in der Domäne Domainname2 gesucht, wird dieses Domänenobjekt geladen und die OID2 ausgelesen und zurückgeliefert. Daraufhin kann das Objekt mit der ID OID2 geladen und dort weitergesucht werden. Dieser Mechanismus ist ähnlich dem des DNS-Lookup im Internet.

Schließlich wird ein Verzeichnisobjekt gefunden, welches die Informationen enthält, unter welcher OID die einzelnen Web&Co-Seiten zu finden sind. Weiters stehen im Verzeichnisobjekt der Erstellungszeitpunkt und der Zeitpunkt der letzten Änderung, der "Eigentümer" des Objektes und Informationen, welche Benutzer bzw. Benutzergruppen Zugriff auf diesen Verzeichniseintrag haben. So können Verzeichniseinträge von Objekten, auf die ein unberechtigter Benutzer keinen Zugriff hat, gleich im Verzeichnis vor ihm verborgen werden. Er sieht also gar nicht, daß das Objekt existiert.

Abb. 4 zeigt den Aufbau eines Verzeichnisobjektes. Alle Informationen bestehen aus Attribut-Wert-Paaren (attribute-value-pairs). Das letzte Attribut ist das OID-Attribut, das die OID des betreffenden Objektes beinhaltet. Davor können beliebig viele andere Attribute verwendet werden. Dies ermöglicht größtmögliche Flexibilität für zukünftige Erweiterungen.

Obiges Beispiel zeigt einen Verzeichniseintrag in einem Verzeichnisobjekt. Die Darstellung der Benutzer-ID in diesem Beispiel ist frei erfunden, denn diese Arbeit beschäftigt sich wie erwähnt nicht mit der Art der Registrierung und Identifizierung der Benutzer des Internet. Es ist auch denkbar, daß die Benutzerbezeichnungen nicht in regionale Domänen eingeteilt sind, sondern nach irgendwelchen anderen Kriterien aufgebaut sind.

Wenn ein Verzeichnis ein untergeordnetes Verzeichnis enthält, wird einfach ein DIR-Eintrag mit dem Namen des Sub-Verzeichnisobjektes und der OID dieses Objektes eingefügt.

Wird so ein Eintrag gefunden, lädt das System einfach das Verzeichnisobjekt mit der OID oid2 und verfährt mit diesem wie gehabt.

Wie funktioniert nun die Namensresolution in Web&Co? Der Name eines Web&Co-Objektes besteht aus einigen Domänennamen, einem oder mehreren Verzeichnisnamen und dem Namen des Web&Co-Objektes selbst. Da die syntaktische Form der Namensgebung im Internet beibehalten wird, ergibt sich die etwas seltsame Situation, daß der Name eines Web&Co-Objektes sowohl eine Zusammensetzungsordnung von rechts nach links als auch eine Zusammensetzungsordnung von links nach rechts beinhaltet.

Der Domänenname verwendet eine Zusammensetzungsordnung von rechts nach links und der Verzeichnis- bzw. Objektname eine von links nach rechts. Dies sollte die Implementierung von Web&Co allerdings nicht erheblich erschweren, da die "Grenze" zwischen Domänenname und Verzeichnisname syntaktisch klar zu erkennen ist.

Wird nun also ein Objekt in Web&Co angefordert, sucht die Software (z. B. ein Web&Co-Browser) im NameServer-Objekt nach der OID des Domänenobjektes der obersten Domäne. Hat sie diese, so holt sie sich dieses Domänenobjekt und sucht darin nach der nächsten Domäne. Dies setzt sich fort, bis das letzte Domänenobjekt geholt wurde.

In diesem Objekt befinden sich nun keine Verweise auf Unterdomänen mehr, sondern auf Verzeichnisobjekte. Die Web&Co-Software sucht sich nun das richtige Verzeichnisobjekt heraus, und sucht darin nach einem Eintrag für das zu ladende Web&Co-Objekt (oder auf ein weiteres Verzeichnisobjekt). Nun wird das gefundene Objekt geladen und der Inhalt verarbeitet.

Im obigen Beispiel ist der Name eines Web&Co-Objektes zu sehen, der aus vier Domänenobjekten (at, ac, tuwien, complang), drei Verzeichnisobjekten (www, projekte, webundco) und dem Namen des Web&Co-Objektes (index) besteht. Etwas verwirrend für Benutzer des Internet ist vielleicht, daß www der Name eines Verzeichnisobjektes und nicht eines Domänenobjektes ist.

Da das Objekt www keine weiteren Unterdomänen enthält, sondern ein Verzeichnis von Objekten und weiteren Verzeichnisobjekten, wird nicht von einem Domänenobjekt gesprochen, obwohl der String "www" im DNS zum Domänennamen des entsprechenden Servers gehört. Diese Verwirrung ist allerdings kein besonderes Problem, da die Interna von Domänen- und Verzeichnisobjekten nur den Web&Co-Programmierer betreffen und für den Benutzer von Web&Co transparent sind.

Es besteht auch die Möglichkeit, weitere Nameserver einzuführen. Da die Internetobjekte ja völlig unabhängig von der Adressierung gespeichert werden, spricht nichts dagegen, daß die Objekte in verschiedenen Verzeichnisobjekten registriert werden. So könnte es neben dem Verzeichnis nach der DNS-Methode auch etwa ein Verzeichnis geben, daß eine Einteilung nach Themen oder nach anderen Kriterien erfolgen. Bis sich das System etabliert hat, sollte aber nur das DNS-System als Nameserver implementiert werden.

Durch die Mechanismen des CoKe können die einzelnen Nameserver wiederum verteilt sein. Da ein Nameserver aus CoKe-Objekten besteht, die einander referenzieren, ist es gleichgültig, wo sich diese Objekte letztendlich befinden.

Die folgende Graphik zeigt ein Internetobjekt, das in verschiedenen Nameservern eingetragen ist.

Da es relativ viel Aufwand bedeutet, einen Namen mit vielen Domänen- bzw. Verzeichnisebenen zu holen, sollte man sich für Web&Co verschiedene Caching-Methoden einfallen lassen. So könnten beispielsweise geladene Verzeichnisobjekte auf einem Web&Co-Rechner gespeichert werden, damit beim nächsten Aufruf eines Objektes in diesem Verzeichnis nicht wieder alle Domänenobjekte "durchlaufen" werden müssen.

Dies ist vor allem deshalb wichtig, weil sehr oft nachdem ein Objekt geladen wird, ein weiteres Objekt aus dem selben Verzeichnis geholt wird (etwa bei einem in einer Webseite integrierten Bild). Dieses Caching ist aber eine Frage der Implementierung und wird daher hier nicht weiter beschrieben. Ob und wie Verzeichnisobjekte in ein Cache geschrieben werden, entscheidet der Programmierer einer Web&Co-Applikation.

Weiters ist es denkbar, daß häufig benutzte Domänenobjekte von einem Cache-Objekt verwaltet werden. In einer späteren Version von Web&Co könnte es beispielsweise ein Objekt DomainCache geben, das direkte Verweise auf die "beliebtesten" Domänenobjekte enthält. Bevor ein Browser dann beginnt, im NameServer-Objekt nach der obersten Domäne zu suchen, schaut er in das DomainCache-Objekt, ob die gesuchte Domäne dort zu finden ist.

Da ein Web&Co-Objekt seinen Namen nicht implizit durch die Speicherung auf einem bestimmten Rechner in einem bestimmten Verzeichnis bekommt, sondern durch den Ersteller explizit benannt werden muß, ergibt sich das Problem Erstellung eines Verzeichniseintrages. Wird ein Web&Co-Objekt vom Web&Co-Compiler erstellt und ein CoKe-Objekt erzeugt, trägt er es auch gleich unter dem - vom Ersteller zu übergebenden - Namen in das jeweilige Verzeichnisobjekt ein. Wird ein Web&Co-Objekt gelöscht, so wird es vom Compiler auch gleich aus dem Verzeichnis entfernt.

Der Nameserver von Web&Co dient generell dazu, das Problem zu lösen, daß nicht benannte Objekte (wie CoKe-Objekte, die keinen expliziten Namen haben) in einer Welt des Benennens verwendet werden. In dieser Welt gibt es ein globales Namensgebungsproblem, das es etwa bei den CoKe-Objekten nicht gibt, da alle OIDs eindeutig sind.

Eines der größten Ärgernisse ist für Benutzer des Internet die Schwierigkeit, Informationen zu finden, von denen er nicht weiß, wo sie sich befinden und ob sie überhaupt im Internet zu finden sind. Sowohl die Suche nach einer ganz bestimmten Information als auch die Suche nach allgemeineren Informationen zu einem bestimmten Thema sind im heutigen Internet sehr schwierig.

Es existieren zwar verschiedene Suchmaschinen im Internet, die bereits in Kapitel 3 beschrieben wurden, diese verwalten aber nur einen Teil des Internet und bieten auch nur die Möglichkeit einer Volltextsuche nach bestimmten Stichworten. Es wäre also günstig, wenn es eine Möglichkeit gäbe, einen Index des gesamten Inhaltes von Web&Co zu erstellen. Aufgrund der enormen Größe des Internet ist es natürlich unrealistisch, diesen Index zentral zu verwalten.

Es muß also eine Lösung realisiert werden, bei der die Indexe dezentral erstellt und verwaltet werden, ähnlich wie in Harvest. Für die dezentrale Struktur der Indexe bietet sich natürlich wieder eine hierarchische Struktur an. Dies hat auch den Vorteil, daß die Suche sehr einfach auf einen Unterbaum des hierarchisch aufgebauten Index-Baum beschränkt werden kann.

Um diese Beschränkung sinnvoll gestalten zu können, muß man sich eine möglichst günstige Aufteilung des Suchraumes überlegen. Der Hauptgedanke dabei muß sein: "Nach welchen Kriterien wird der Benutzer die Suche am ehesten einschränken?". Außerdem muß die Entscheidung getroffen werden, wer die kleinsten Einheiten - die dezentralen Indexe - verwalten soll.

In Web&Co werden die Indexe auf Ebene der Institutionen, die die Informationen bereitstellen, erstellt. Das heißt, daß beispielsweise alle Objekte, die sich unter der Adresse *.tuwien.ac.at zu finden sind, in einem Index verwaltet werden. Bleibt noch die Frage, nach welchen Kriterien die hierarchische Unterteilung des gesamten Suchraumes erfolgen soll.

Für Web&Co wurde diese Einteilung auf der obersten Ebene nach regionalen Gesichtspunkten durchgeführt. Das sieht so aus, daß der gesamte Suchraum von Web&Co auf Länderebene aufgeteilt wird, also daß - ähnlich dem DNS - die oberste Domänen jeweils einem Land gehören.

Um die Suche besser automatisieren zu können, müssen auch die Unterdomänen des Web&Co-Index standardisiert sein. Es gilt also nicht mehr, daß der Verwalter einer Domäne die Unterdomänen vollkommen autonom verwalten kann - wie es etwa im DNS der Fall ist. Die zweite Ebene der Hierarchie wird durch die Art der Organistation des Verzeichnis-Verwalters charakterisiert. (Firma, Organisation, Universität, Schule, Regierung…). Auch hier findet sich eine Analogie zur Struktur des DNS.

Die dritte (und letzte) Ebene der Struktur beinhaltet schließlich den Namen der Institution, welche die Informationen zur Verfügung stellt. Abb. 4 zeigt die Struktur der Indizierung von Web&Co:

Damit der jeweilige Index immer auf dem aktuellen Stand ist, müssen Änderungen in den Web&Co-Objekten sofort Auswirkung auf den Index haben. Es muß also etwa immer, wenn der Web&Co-Compiler ein Objekt erstellt, eine Methode aufgerufen werden, die den Inhalt dieses Objektes in den zugehörigen Index aufnimmt.

Genauso wie bei der Erstellung muß der Index auch bei einer Änderung eines Objektes angepaßt werden. Dabei müssen aber zuerst die nicht mehr aktuellen Einträge gelöscht werden. Wird ein Objekt ganz gelöscht, so müssen alle seine Einträge aus dem Index entfernt werden. Das Programm, das die Änderungen an den Indexobjekten vornimmt, muß auf jeden Fall direkt nach der Änderung vom Web&Co-Compiler aufgerufen werden.

Wird nun eine Suche durchgeführt, kann der Benutzer angeben, ob er im gesamten Web suchen will, oder ob die Suche auf bestimmte Bereiche (Länder, Konitnente, Universitäten etc.) beschränken will. Letzteres hat nicht nur den Vorteil, erheblich schneller zu sein, es reduziert auch den Aufwand des Benutzers, aus allen Treffern jene herauszufiltern, die für ihn brauchbar sind.

Natürlich kann man Internet-Inhalte nicht nur nach regionalen Gesichtspunkten unterteilen. Ein anderer Ansatz ist die Einteilung nach bestimmten Themen bzw. Unterthemen. Eine solche Einteilung ist in der folgenden Abbildung dargestellt:

Wird eine solche Einteilung gewählt, so kann natürlich nicht mehr an eine automatische Erstellung der Indexe gedacht werden. Die Ersteller von Internetobjekten sind dann alleine dafür verantwortlich, daß sich ihre Seiten an der richtigen Stelle im Index befinden. Nach der Erstellung von Internetobjekten muß der Ersteller also diese an der entsprechenden Stelle im Index eintragen.

Dafür müssen selbstverständlich geeignete Werkzeuge zur Verfügung gestellt werden, die es ermöglichen, diese Eintragung möglichst unkompliziert vorzunehmen. Der Index ist wertlos, wenn ein Großteil der Inhalte nicht registriert wird, weil die Eintragung für Laien zu kompliziert ist. Am besten wäre es, wenn die Eintragung über Formulare auf einer ganz normalen Web-Seiten zu ermöglichen.

Es ist allerdings trotzdem zu erwarten, daß bei der Eintragung in den Index ein ziemliches Chaos entstehen wird. Viele Benutzer, die sich nur oberflächlich mit der Struktur des Index beschäftigt haben, werden ihre Seiten - wenn überhaupt - an der falschen Stelle eintragen. Benutzer, die wollen, daß ihre Seiten möglichst oft gefunden werden, werden diese an vielen Stellen im Index eintragen, auch wenn sie thematisch nicht dort hinpassen.

Letztendlich ist aber zu hoffen, daß der Großteil der Benutzer seine Inhalte an den richtigen Stellen einträgt, da ja anzunehmen ist, daß jene, die diese Seiten suchen, an eben diesen Stellen nachschauen werden.

Es kann auch mehrere Index-Bäume nebeneinander geben. Sie können alle unterschiedlich aufgebaut sein. Wichtig ist, daß es nicht unübersichtlich viele Indexe gibt, da dies die Benutzer überfordern würde. Auch muß darauf geachtet werden, daß es nicht mehrere Indexe mit gleichem Aufbau gibt. Solche Redundanzen würden nur zur Unübersichtlichkeit beitragen und für die Zielsetzung, ein einfaches und flexibles Suchsystem zu etablieren, kontraproduktiv sein.

Umfangreiche Suchen können natürlich nicht so durchgeführt werden, daß der Benutzer die Indexobjekte auf seinen Rechner lädt und dort die Suche durchführt. Dazu reichten die Hardware-Ressourcen der Clientrechner nicht annähernd aus. Es muß auch weiterhin spezielle Suchmaschinen im Internet geben, die diese Suche für die Benutzer durchführen und ihnen die Ergebnisse zurückliefern.

Diese Suchmaschinen stellen, genau so wie die Suchmaschinen im WWW, eine Web-Seite als Benutzerschnittstelle zur Verfügung, in der der Benutzer seine Suchaufträge in ein Formular eingeben kann. Diese Web-Seite ist natürlich wieder ein Web&Co-Objekt. Die Eingaben, die der Benutzer in das Forumular eintippt, werden nach dem Abschicken in ein CoKe-Objekt geschrieben, auf das die Suchmaschine Zugriff hat.

Startet ein Benutzer nun eine Suche, so schreibt er in dieses Objekt seine(n) Suchbegriff(e) und die Domänen, in denen gesucht werden soll. Außerdem legt er automatisch ein CoKe-Objekt an, in das der Suchrechner das Suchergebnis ablegen soll. (Ansonsten würde der CoKe auf dem Clientrechner das Objekt mit dem Ergebnis nicht finden.) Eine Referenz auf dieses "Antwort-Objekt" muß natürlich auch an die Suchmaschine übergeben werden.

Als Suchdomäne kann der Benutzer beispielsweise eine Landesdomäne (z. B. at) angeben. Dann wird nur in jenen Indexobjekten gesucht, die sich innerhalb dieser Domäne befinden. Indexobjekte in anderen Landesdomänen werden außer Acht gelassen. Auch innerhalb einer Unterdomäne (z. B. at.co) kann gesucht werden.

Die Suche muß sich aber nicht auf einzelne Unterbäume des "Suchbaumes" beschränken. So ist es etwa denkbar, die Suche auf allen "ac"-Domänen durchzuführen, um im akademischen Bereich aller Länder zu suchen. Wie der Benutzer die Suchdomäne(n) einzugeben hat, ist Sache der Implementierung der jeweiligen Suchmaschine.

Die Suchmaschine liest die Suchanfrage nun aus seinem Such-Objekt aus und holt sich ein Indexobjekt aus dem angegebenen Suchraum. Die Namensresolution dieser Objekte funktioniert im Prinzip genauso wie bei den Verzeichnisobjekten von Web&Co. Es wird ein Domänenobjekt geholt und nachgeschaut, wo sich das Domänenobjekt der nächsten Ebene befindet, bis das gesuchte Indexobjekt gefunden ist.

Nachdem das Indexobjekt vom Suchrechner geladen worden ist, führt er darin die Suche durch und stellt eine Liste von Verweisen auf jene Web&Co-Objekte zusammen, welche die Suchbegriffen enthalten. Parallel dazu lädt der Suchrechner (der natürlich entsprechend leistungsfähig sein muß) auch die anderen Indexobjekte, die sich im spezifizierten Suchraum befinden, und führt dort die gleiche Arbeit aus.

Schließlich nimmt der Suchrechner die gesammelten Ergebnisse und schreibt sie in das Objekt, das vom "suchenden" Client angelegt worden ist. Dieses Objekt ist aufgebaut wie ein normales Web&Co-Objekt, dessen Inhalt im Prinzip genauso aussehen kann, wie die Antwortseiten der heute gebräuchlichen WWW-Suchmaschinen.

Auf die Art der Indizierung in Web&Co wird in dieser Arbeit nicht eingegangen, weil dies eine sehr kritische Frage ist, bei der die Betreiber der Suchmaschinen einiges mitzureden haben. Schließlich kann eine schlechte Indizierungsmethode die Performance eines Suchrechners erheblich beeinträchtigen.

Bevor die Web&Co-Indizierung also eingeführt wird, sollte mit den Betreibern der Suchmaschinen unbedingt weitgehende Einigung über die Art der Indizierung erzielt werden. Diese Einigung sollte dann als Standard auch für eventuell später dazukommende Suchmaschinen festgelegt werden.

In weiteren Ausbaustufen von Web&Co könnten die Suchmaschinen Thesauri verwenden. Dies kann so aussehen, daß optional die Möglichkeit geboten wird, neben dem Suchbegriff auch nach Synonymen oder Wörtern mit ähnlicher Bedeutung zu suchen. Dies wäre sicher eine enorme Erleichterung der Suche im Internet.

Die Suche nach konkreten Begriffen im WWW kann sehr effektiv implementiert werden, aber ist recht inflexibel. Es werden nur Begriffe gefunden, die exakt dem Suchbegriff entsprechen. Synonyme und verwandte Begriffe werden ignoriert, wenn der Suchende nicht explizit nach diesen suchen läßt. Dies setzt natürlich voraus, daß dieser alle diese Begriffe auch kennt.

Deshalb sollen in Web&Co Thesauri realisiert werden, die bei der Suche nach solchen Begriffen helfen. Um den Benutzern die Verwendung der Thesauri zu erleichtern, sollen alle in Web&Co verwendeten Thesauri bestimmte gemeinsame Merkmale besitzen. Neben diesen Merkmalen können auch optionale Erweiterungen in den jeweiligen Thesaurus integriert werden. Es ergibt sich daraus sozusagen eine Art "Rumpfthesaurus", der gewissermaßen eine "Mindestanforderung" an Web&Co-Thesauri darstellt.

Wie sehen diese Anforderungen an Web&Co-Thesuri aus? So wie jeder Thesaurus benötigt ein Web&Co-Thesaurus eine Datenbasis. Das ist Menge von Begriffen, die in diesem Thesaurus enthalten ist und nach denen gesucht werden kann bzw. in die neue Begriffe eingefügt werden können.

Dann gibt es Beziehungen zwischen diesen Begriffen. Diese Beziehungen werden im folgenden mit ihren englischsprachigen Bezeichnungen angeführt. Die Beziehungen des Web&Co-"Rumpfthesaurus" sind:

• Use (US): Verwendet für Beschreibungen, die anstatt veralteter, ungebräuchlicher oder unklarer Ausdrücke verwendet werden. (Beispiel: Rechnerverbund US Netzwerk) Begriffe, die in einer US-Beziehung zugewiesen wurden (im Beispiel: Netzwerk) heißen auch "preferred" (bevorzugt).
• Use for (UF): Die Umkehrung. (Netzwerk UF Rechnerverbund) Begriffe die in einer UF-Beziehung zugewiesen wurden, heißen auch "non-preferred" (nicht bevorzugt).
• Broader Term (BT): Ein Überbegriff für einen Begriff. Beziehung zwischen einem Element einer Gruppe und dieser Gruppe. (Festplatte BT Laufwerk)
• Narrower Term (NT): Beziehung zwischen einer Gruppe und einem Element aus dieser Gruppe (Laufwerk NT Festplatte)
• Related Term (RT): Jedwede Beziehung anderer Art. Etwa: Material, Ursprung, Coexistenz etc. (Computer RT Informatik)

Es gelten folgende Regeln:

• Die Beziehungen US und UF sind reziprok invers zueinander. Gilt A US B, so gilt B UF A und umgekehrt.
• Die hierarchischen Beziehungen BT und NT sind reziprok invers zueinander. Gilt A BT B, so gilt B NT A und umgekehrt.
• Die Beziehung RT ist symmetrisch und invers zu sich selbst. Gilt A RT B, gilt auch B RT A.
• Nicht bevorzugte Begriffe können ausschließlich weitere UF-Beziehungen zugewiesen bekommen. Es ist nicht möglich, einem solchen Begriff eine BT, NT, US oder RT-Beziehung zuzuweisen.
• Einem bevorzugten Begriff kann keine US-Beziehung zugewiesen werden. Es kann also kein Begriff einem bevorzugten "bevorzugt" werden.

Computer UF Rechner

Rechner US Computer

Festplatte BT Laufwerk

Diskettenlaufwerk BT Laufwerk

Laufwerk NT Festplatte, Diskettenlaufwerk

Floppydrive US Diskettenlaufwerk

Diskettenlaufwerk UF Floppydrive

Diskette RT Diskettenlaufwerk

Diskette RT Floppydrive Falsch! (Floppydrive = non-preferred)

Ein Thesaurus-Manager, der ähnlich aufgebaut ist, ist BEAT [Bea]. In BEAT werden die selben Beziehungen verwendet, wie oben beschrieben. Auch die Regeln für den Thesaurus sind die gleichen wie in BEAT.

Im Prinzip kann ein Begriff auch ohne Beziehungen im Thesaurus stehen. Nur nützt der Thesaurus natürlich nur dann etwas, wenn die Begriffe alle Beziehungen zu anderen Begriffen haben.

Wie bereits erwähnt, können in die jeweiligen Web&Co-Thesauri weitere Beziehungen eingebaut werden. Diese Möglichkeit stellt sicher, daß die Thesauri in Web&Co auch in Zukunft den gesteigerten Anforderungen gewachsen sein werden.

Da ein Thesaurus vor allem beim Suchen im Web Verwendung finden wird, ist es sinnvoll, wenn er in eine Suchmaschine eingebaut wird. Es könnte aber auch die Möglichkeit geben, einen Thesaurus als solchen zu nutzen. (Etwa um nach Synonymen für einen bestimmten Begriff zu suchen). In dem Fall wäre es naheliegend eine Webseite als Benutzerschnittstelle zur Verfügung zu stellen, mit der der Benutzer seine Anfragen an den Thesaurus schicken kann.

Wie ein Thesaurus in Web&Co konkret implementiert wird, bleibt - wie auch die Implementierung einer Suchmaschine - dem jeweiligen Entwickler überlassen. Würde man allzu viele Details im Vorhinein festlegen, würde das der Flexibilität und Erweiterbarkeit des Systems abträglich sein.

Durch die Verteilungskonzepte des CoKe können Thesauri natürlich ebenfalls verteilt sein. Wenn der Programmierer die Funktionalität des CoKe optimal einsetzt, kann er die Thesaurus-Einträge z. B. in verschiedenen Objekten verteilt verwalten. Dies würde auch der Erweiterbarkeit und Wartbarkeit des Thesaurus zuträglich sein.

Der Sicherheitsaspekt ist im heutigen Internet eines der größten Probleme überhaupt. Es existieren zwar Lösungsansätze, wie verschlüsselte Übertragung von Daten oder das sichere Bezahlen über das Netz, aber wirkliche Lösungen gibt es keine. Ein neuer Ansatz, das Web zu organisieren, sollte daher auf die Sicherheit besonderes Augenmerk legen.

Mögliche Sicherheitsprobleme sind vielfältig: Übermittelte Daten könnten von Unberechtigten gelesen werden, bestimmte Objekte können nur für bestimmte Personen oder Personengruppen bestimmt sein oder es könnten Objekte von fremden Personen verändert werden. In Web&Co soll nun verhindert werden, daß diese möglichen Probleme auftreten können.

Die Übertragung von Daten wie Kreditkartennummern wird derzeit realisiert durch eine Verbindung vom Client zum Server. Da es in Web&Co keine dezidierten Webserver gibt, auf dem Skripts ausgeführt werden können, muß die Übermittlung von Daten auf andere Weise realisiert werden. Programme müssen somit auf dem Clientrechner ausgeführt werden.

Da der Zugriff auf CoKe-Objekte sehr gut kontrolliert werden kann, ist die Gefahr, das die Informationen "ausspioniert" werden können, gering. Es muß selbstverständlich sichergestellt werden, daß nur jemand dieses Objekt lesen kann, der dazu berechtigt ist. Damit sind wir beim zweiten Sicherheitsproblem. Gewisse Objekte sollen nur von bestimmten Personen gelesen werden können.

Die Identifizierung von Teilnehmern im Internet ist ein Problem. Dazu muß jeder Teilnehmer registriert sein. Dies ist angesichts der enorm großen und ständig steigenden Zahl an Teilnehmern im Internet und auch aufgrund der Tatsache, daß sich von öffentlichen Terminals ("Cyber-Cafés" …) jeder ins Internet "hängen" kann, eine sehr schwierige Aufgabe. Diese Benutzererfassung muß natürlich dezentral und hierarchisch (also mit Hilfe von Domänen) erfolgen.

In dieser Arbeit wird für Web&Co keine verbindliche Art der Benutzeridentifizierung festgelegt. Zur Veranschaulichung der Sicherheitsfunktionen von Web&Co wird hier eine hierarchische Benutzeridentifizierung mit Zusammensetzungsordnung von links nach rechts, wobei die Namenselemente durch Doppelpunkte getrennt sind, verwendet. (siehe Abb. 4) Die oberste Domäne wird nach regionalen Gesichtspunkten unterteilt. Dies ist aber wie gesagt nur ein Vorschlag.

Es sollte auch eine Möglichkeit gefunden werden, den Zugriff auf Objekte zu regeln, ohne daß die Benutzer, die zugriffsberechtigt sind, bekannt sein müssen. Das wäre beispielsweise notwendig, wenn man nicht registrierten Benutzern Zugriff auf ein Objekt gewähren will, oder wenn man die Berechtigungen für ein Objekt nicht immer ändern will, wenn ein neuer Benutzer eine Lese- oder Schreibberechtigung erhalten soll.

Eine einfache Möglichkeit, dies umzusetzen, ist eine Verschlüsselung der Daten mittels Paßwort und die Mitteilung dieses Paßwortes an die berechtigten Benutzer. Dieses Paßwort wissen dann nur Personen, die Zugriffsrecht auf dieses Objekt haben und das Objekt bleibt für alle anderen Benutzern unbrauchbar.

Ein Anwendungsgebiet, das sich für diese Art der Sicherung geradezu aufdrängt, sind Internetseiten, die nicht jugendfrei sind. Die Inhalte solcher Seiten könnten mit einem vordefinierten Schlüssel verschlüsselt werden. Der Web&Co-Browser kann so konfiguriert werden, daß er solche Seiten nicht darstellt. Oder es könnten Versionen des Browser-Programmes angeboten werden, die solche Seiten - unabhängig von der Konfiguration - überhaupt nicht darstellen.

Als weitere Methode für die Verschlüsselung können zum Beispiel PGP-Schlüssel verwendet werden. Dies kann transparent für den Benutzer durchgeführt werden: Der Benutzer gibt sensible Daten in seinen Web&Co-Browser ein, dieser verschlüsselt die Daten mit dem öffentlichen Schlüssel des Empfängers und speichert die verschlüsselten Informationen in einem CoKe-Objekt ab.

Der Empfänger der Informationen kann diese mit seinem privaten Schlüssel entziffern. Diese Art der Verschlüsselung ist dann besonders sinnvoll, wenn eine große Zahl von Personen eine vertrauliche Information an einen bestimmten Empfänger senden wollen und nur dieser die Informationen lesen können soll.

Im Gegensatz zu anderen problematischen Internet-Inhalten - wie etwa Seiten von radikalen Organisationen - sind die Betreiber solcher Seiten meist selbst an einer Kontrolle des Zugriffs auf ihre Inhalte interessiert. Schließlich wollen sie ihr Angebot ja nur für zahlende Kunden zur Verfügung stellen. Nicht geschützt ist man klarerweise vor Inhalten, die der Veröffentlicher nicht geheimhalten will.

Es ist genauso wenig wünschenswert wie technisch möglich, den Zugriff auf bestimmte Inhalte des Web ohne Zustimmung des Anbieters zu verhindern. Erstens ist es nicht möglich, automatisiert festzustellen, welche Inhalte kritisch sind und welche nicht, zweitens wäre die Gefahr der Zensur - z. B. in totalitären Staaten - allzu groß. Inhalte wie Pornographie oder politischen Radikalismus wird es also auch weiterhin im Internet geben. Die Menschheit wird wohl lernen müssen, mit einem Internet mit diesen Inhalten vernünftig umzugehen.

Ein weiteres Anwendungsgebiet für Verschlüsselung als Art der Berechtigungsvergabe wäre z. B. der Vertrieb von Software. Jeder kann sich das Objekt mit den Installationsdateien holen, aber nur wer bezahlt hat, bekommt das Paßwort, mit dem er diese Dateien entschlüsseln kann. Man sieht sofort, daß diese Methode nicht die allersicherste ist. Wenn irgend jemand einmal das Paßwort weiß, kann er es beliebig vielen Personen weitergeben, die dann ungehindert Zugriff auf das "gesicherte" Objekt haben.

Für wirklich sicherheitskritische Aufgaben ist die Verschlüsselungsmethode alleine also kein geeignetes Mittel. Für den Vertrieb von Shareware beispielsweise ist das aber sicher geeigneter, als jeden Benutzer in die Liste der Leseberechtigten aufzunehmen. Auch wenn die Paßwörter nur ausgewählten, vertrauenswürdigen Personen bekannt sind, kann diese Art der Sicherung gewählt werden.

Weiters ist es natürlich möglich, beide Arten der Sicherung miteinander zu kombinieren. Also den Inhalt des Web&Co-Objektes verschlüsseln, und nur bestimmten, berechtigten Benutzern den Zugriff auf das Objekt gewähren. Dies ist vor allem für besonders sicherheitskritische Anwendungen - wie Bezahlung über das Web - sinnvoll.

Will ein Benutzer über das Internet bezahlen, verschlüsselt er die dafür benötigten Informationen mit einem Schlüssel des Empfängers (etwa eine Bank), den nur dieser wieder entschlüsseln kann. Dann speichert er die Informationen in ein Web&Co-Objekt, auf das jeder Schreibberechtigung, aber niemand außer dem Empfänger Leseberechtigung besitzt.

Bei derart kritischen Aktionen wie der Bezahlung über das Internet ist es ein großer Vorteil, daß Web&Co auf die Transaktionsfähigkeit des CoKe zurückgreifen kann. Transaktionen werden entweder korrekt durchgeführt, oder haben überhaupt keine Auswirkungen. Es kann also nicht passieren, daß bei der Bezahlung ein inkonsistenter Zustand in einem der beteiligten Objekte entsteht und damit Geld quasi "verloren geht".

Die Zugriffsinformationen - also die Namen derer, die auf ein Objekt zugreifen dürfen - befinden sich in jenem Verzeichnisobjekt, das auf dieses Objekt verweist. Ein Beispiel für einen solchen Verzeichniseintrag mit Zugriffsinformationen ist weiter oben zu finden. Dort werden in den Benutzernamen auch Wildcards (*) benutzt, die angeben, daß alle Benutzer in dieser Domäne Zugriff auf das Objekt haben.

Fehlt die Angabe von berechtigten Benutzern, so nimmt Web&Co an, das jeder (also *) Leseberechtigung besitzt, aber nur der Besitzer (owner) Schreibberechtigung.

Web&Co besteht im wesentlichen aus den folgenden Objekten:

• Webseiten-Objekte
• Verzeichnisobjekte
• Indexobjekte
• eingebettete Objekte

Ein Webseiten-Objekt entspricht einer herkömmlichen HTML-Datei. Dieses Objekt repräsentiert eine Webseite und enthält alle Informationen, die der Web&Co-Browser zur Darstellung einer Webseite braucht. Ein Webseiten-Objekt enthält HTML-Code, der mit dem Tag <HTML> beginnt und mit dem Tag </HTML> endet. Der HTML-Code zwischen diesen beiden Tags sollte bis auf wenige Ausnahmen der jeweils aktuellen HTML-Spezifikation entsprechen.

Das HREF-Attribut des <A>-Tags enthält keine Angabe des Protokolls (also kein http://), sondern ausschließlich die Adresse des Web&Co-Objektes, das referenziert wird.

Beispiel:
<A HREF="www.complang.tuwien.ac.at/index.html">

Um Webseiten modular aufbauen zu können, muß ein neues Tag eingeführt werden. Damit kann eine Webseite aus mehreren Fragmenten aufgebaut werden. Dies geschieht mit Hilfe des <WUCINSERT>-Tags.

Beispiel:
<WUCINSERT SRC="fragment2.htm">

In diesem Beispiel wird an dieser Stelle der Inhalt des Objektes mit dem Namen fragment2.htm in die Webseite eingefügt. Dies stellt eigentlich schon eine Erweiterung der HTML-Spezifikation dar. Das proprietäre Erweitern der Sprache HTML hat aber bereits eine große Tradition und wird deshalb auch in diesem Entwurf gemacht. Die Methode ist ähnlich der Methode, separate Webseiten in Frames zu laden, nur daß es keine klare Trennung der Seite in verschiedene Bereiche gibt.

Die Verzeichnisobjekte wurden bereits weiter oben kurz beschrieben. Hier wird das Beispiel noch einmal angeführt und erklärt:

Ein Verzeichnisobjekt besteht aus hinereinander folgenden Attribut-Wert-Paaren. Die einzelnen Elemente sind von einander durch das Zeichen | (ASCII-Code 124) getrennt. Die vordefinierten Attibute sind:

• NAME - Der Name des Objektes über den es vom Web&Co-Browser angesprochen wird.
• CREAT - Der Zeitpunkt der Erstellung des Objektes im UTC-Format
• MODIF - Der Zeitpunkt der letzten Modifikation des Objektes im UTC-Format
• OWNER - Die Identifikation des Besitzers des Objektes
• READ - Die Identifikation aller, die Leseberechtigung auf dieses Objekt besitzen
• WRITE - Die Identifikation aller, die Schreibberechtigung auf dieses Objekt besitzen
• OID - Die OID des CoKe-Objektes, welches das Web&Co-Objekt repräsentiert.

Das OID-Attribut ist der letzte Eintrag eines Objektes. Alle folgenden Einträge beziehen sich bereits auf die folgenden Objekte in diesem Verzeichnis. Eine Erweiterung um weitere Attribute ist kein Problem, da beliebig viele Attribute vor dem OID-Attribut eingefügt werden können.

Ein weiteres Attribut nimmt eine Sonderstellung ein:

• DIR - Ein Verweis auf ein Unterverzeichnis in diesem Verzeichnis

Das DIR-Attribut hat nicht einen, sondern zwei Werte. Den Namen des Unterverzeichnisses und die OID des CoKe-Objektes, das dieses Unterverzeichnis repräsentiert.

Ein DIR-Eintrag muß direkt nach einem OID-Eintrag oder einem anderen DIR-Eintrag stehen.

Indexobjekte enthalten einen Index über mehrere Seiten. Der Aufbau der Indexobjekte kann vom Ersteller der Indexobjekte frei bestimmt werden. Die Suchsoftware muß dann auf die jeweilige Struktur der Indexe angepaßt werden.

Eingebettete Objekte sind beispielsweise Bilder oder JAVA-Applets, die in eine Webseite eingefügt werden. Die Syntax der Einbettung in das Webseiten-Objekt ist die selbe wie in herkömmlichen HTML-Dateien. Der Inhalt der eingebetteten Objekte ist exakt der selbe Inhalt, der in einer entsprechenden Datei zu finden ist. Es wird also quasi nur der Dateiinhalt in ein CoKe-Objekt "verpackt".

Damit man mit diesen Objekten auch etwas anfangen kann, braucht man natürlich die entsprechenden Software-Werkzeuge. Mindestens zwei solcher Werkzeuge werden gebraucht: Der Web&Co-Compiler und der Web&Co-Browser. Der Web&Co-Compiler "packt" HTML-Dateien in CoKe-Objekte und trägt sie in einen Nameserver ein.

Er muß den HTML-Code geringfügig verändern. Aus den Links (<A HREF...>) muß das Protokoll entfernt werden. Außerdem sollte der Compiler fehlerhaftes HTML ausbessern (etwa ein fehlendes <HTML> am Beginn der Datei einsetzen). Ansonsten entspricht das zu verwendende HTML der jeweils aktuellen offiziellen Spezifikation.

Web&Co löst einige der brennenden Probleme des Internet. Wer öfters die Meldung "This site has moved to …" am WorldWideWeb gefunden hat, weiß wie wichtig es ist, das Problem der Migration von Internetobjekten in den Griff zu bekommen. Web&Co löst dies mit Hilfe der Funktionen des zugrundeliegenden CoKe. Da CoKe-Objekte keinen bestimmen Speicherort aufweisen, stellt sich dieses Problem überhaupt erst gar nicht.

So löst Web&Co auch das Problem der "dangling references". Als Links werden ausschließlich CoKe-OIDs verwendet. Diese OIDs werden aus dem Nameserver geholt und können daher nicht veraltet oder falsch sein.

Auch das Problem der Replikation wird durch den CoKe gelöst. Das Problem, daß eine Datei die mehrfach im Internet vorhanden ist (z. B. auf verschiedenen FTP-Servern rund um den Erdball), aber nur eine oder einige wenige dieser Orte bekannt sind, gehört damit der Vergangenheit an.

Auch auf den Sicherheitsaspekt nimmt Web&Co durch Identifizierung der Benutzer und die optionale Verschlüsselung der Inhalte durch Paßwörter Rücksicht. Wie die Benutzer des Internet erfaßt werden, und auf welche Weise diese Benutzer beschrieben werden, sind Fragen, die noch gelöst werden müssen.

Auch die Frage der Authentifizierung der registrierten Benutzer ist ein Problem, das erst gelöst werden muß. Das beste Zugriffs- und Verschlüsselungssystem ist nichts wert, wenn nicht sicher ist, daß ein Benutzer, der unter einem bestimmten Namen arbeitet, auch wirklich dieser Benutzer ist.

Die Realisierung von Web&Co würde allerdings auch einige beträchtliche Probleme aufwerfen. Das größte davon ist vermutlich die Akzeptanz. Wird das System von den Benutzern nicht angenommen, kann es noch so gut sein. Es wird bei einer Idee bleiben. Darum wurde beim Entwurf von Web&Co großer Wert darauf gelegt, gewohnte Eigenschaften - wie etwa die Schreibweise der Web-Adressen - unverändert zu lassen. Idealerweise merkt der Benutzer eines Web&Co-Browsers nicht einmal, daß er mit einem ganz neuen System arbeitet. Er tippt wie gewohnt seine Adressen ein und erhält im Browserfenster die gesuchten Webseiten.

Um die Akzeptanz von Web&Co zusätzlich zu erhöhen, muß Web&Co als Übergangslösung an das existierende WWW angebunden werden. Dies geschieht am besten mit Hilfe des Common Gateway Interface (CGI). Man plaziert Gateways im Internet, die an Web&Co angeschlossen sind und die CGI-Requests über HTTP auswerten und den Inhalt von Web&Co-Objekten über das CGI zurückschicken.

Bevor Web&Co in die Tat umgesetzt werden kann, muß natürlich bereits entsprechende Software existieren, also Web&Co-Browser und Entwicklungswerkzeuge (Web&Co-Compiler etc.) Diese sollten nach Möglichkeit für alle wichtigen Plattformen existieren (Windows, UNIX, Apple…). In der Übergangsfrist sollten die Web&Co-Browser auch die Möglichkeit besitzen, normale HTTP-Requests an herkömmliche Webserver zu schicken. Auf diese Weise könnte Web&Co langsam ins WWW "einsickern" und schließlich zum Standard werden.

Die hier vorgestellte Lösung ist keinesfalls bereits fertig ausgereift. Die Anzahl der möglichen Erweiterungen für Web&Co ist unabsehbar groß. Wie das gesamte Internet einer ständigen Entwicklung unterliegt, muß auch Web&Co ständig erweitert und verbessert werden. Immer, wenn das Internet um eine neue Anwendung reicher wird, werden auch zusätzliche Anforderungen an die Infrastruktur des Netzes gestellt.

Einige Ideen für zukünftige Erweiterungen könnte man sich von bereits existierenden Systemen, wie etwa HyperWave [Hyp97] abschauen, etwa eine Unterstützung von Mehrsprachigkeit. Der Benutzer stellt in seinem Web&Co-Browser seine bevorzugte Sprache ein und erhält die von ihm gewählte Web&Co-Seite - wenn vorhanden - automatisch in dieser Sprache vorgesetzt. Grafiken und Bilder in verschiedenen Formaten, Farbtiefen und Auflösungen wären ein weiteres solches Beispiel.

Es könnte in den Verzeichniseinträgen eine Information stehen, wie lange das entsprechende Objekt gültig ist (expire-date). Das wäre beispielsweise bei Online-Magazinen oder Online-Ausgaben von Nachrichtenmagazinen sinnvoll, die in regelmäßigen Abständen erscheinen. Das Web&Co-System am Clientrechner kann dann so konfiguriert werden, daß es nach Ablauf einer bestimmten Seite eine Meldung an den Benutzer schickt, oder automatisch die neue Version des Dokumentes lädt.

Es könnten Informationen darüber gesammelt werden, welche Benutzer eine Web-Site aufsuchen und demographische Daten über die Benutzer gesammelt werden. Informationen könnten gegen Entgelt angeboten werden. Der Benutzer könnte dann einen Hinweis auf die Kosten erhalten und, im Falle seiner Zustimmung, könnte das Entgelt gleich über das Internet überwiesen werden.

Dies sind aber nur einige wenige Ideen, wie das System noch ausgebaut werden kann. Viele Möglichkeiten sind heutzutage noch nicht einmal abzusehen. Durch die Möglichkeit, in einem Eintrag in einem Verzeichnisobjekt beliebig viele Attribute zu speichern, ist das System aber auf alle Fälle für künftige Erweiterungen gerüstet.

Ich möchte mich an dieser Stelle bei der Betreuerin dieser Diplomarbeit, Frau Uinv. Doz. Dr. Dipl. Ing. eva Kühn für die Unterstützung bei der Erstellung dieser Arbeit bedanken. Ich danke hiermit auch meinen Studienkollegen Christian Blaas und Fartash Modarres Sadeghi für die Unterstützung bei der Literatursuche und den Diskussionen während der Erstellung dieser Arbeit. Ich danke dem Internetclub Burgenland, der es mir ermöglichte, auf seinen Rechnern die Literatursuche im Internet durchzuführen.

Mein besonderer Dank gilt meinen Eltern, ohne deren Unterstützung es mir unmöglich gewesen wäre, jenes Studium zu absolvieren, im Laufe dessen diese Arbeit geschrieben wurde.

[Alt] Alta Vista Search Engine. http://www.altavista.digital.com

[ARJ1] Arjuna System. http://www.newcastle.ac.uk/prj/arjuna

[Bea] BEAT - Yet another Thesaurus Manager, © Josep Sau 1990 - 1997

[Boe96] Entwicklung verteilter Systeme mit CORBA. Bernd Boecker 1996. http://www.rvs.uni-hannover.de

[Bro96] Tutorial on Linda. Tom Brown 1996.

[BSSS90] Informatik. Blieberger, Schildt, Schmid, Stöckler 1990. Springer-Verlag. S 38.

[CABT] What’s in a name? Martin Chilvers, David Arnold, Andy Bond, Richard Taylor. http://www.dstc.edu.au/whatsinaname.html

[CaGe89] Linda in Context. Nicholas Carriero and David Gelernter 1989. "Communications of the ACM" April 1989 Volume 32 Number 4.

[CER1] CERN-Homepage. http://www.cern.ch

[CER2] World-Wide Web and CERN. http://www.cern.ch/CERN/WorldWideWeb/WWWandCERN.html

[Cha96] Research on OMG/CORBA. Francis Chan 1996.
http://www-cad.eecs.berkeley.edu/~fchan

[CoPe83] A Model of Name Resolution in Distributed Systems. Douglas E. Comer. Purdue University, Larry L. Peterson, University of Arizona.

[DN] DejaNews. http://www.dejanews.com

[Elm92] Database Transaction Models for Advanced Applicatoins. A. K. Elmagarmid. Morgan Kaufmann Publishers, 1992.

[Eng95] TCP/IP gets a face-lift. Erin English 1995. Computer, October 1995. S. 12.

[Exc] Excite. http://www.excite.com

[Fal95] IP - The Next Generation. Jens Fallesen, Dknet 1995. DKUUG-Nyt No. 82, Oktober 1995.

[Gel89] Multiple tupel spaces in Linda. David Gelernter. PARLE ’89 Volume II: Paralell Languages, Juni 1989.

[Gord95] Naming. Gordoni 1995. http://www.base.com/gordoni/web/naming.html

[Hyp97] HyperWave GMbh. http://www.hyperwave.de

[Lyc] Lycos Search. http://www.lycos.com

[Mei96] Der Weg ins Netz. Martin Meier 1996.

[Omg] OMG Home Page. http://www.omg.org/corba/

[RSA78] On a Method for Obtaining Digital Signatures and Public Key Cryptosystems. CACM, vol. 21, pp. 120-126, Feb. 1978.

[Sei97] Die Geschichte hinter dem Internet. Michael Seifert 1997. http://www.wifi.at/kurs/k111.htm

[Smi95] TWIG - What is Gopher? R. F. Smith 1995. http://spynet.net/~rfsmith/gopher.html

[Tan96] Computer Networks. Third Edition. Andrew S. Tanenbaum 1996. Prentice Hall International Editions.

[Tho95] IP Addresses. Arne Thon 1995. http://norway.attgis.com/~arnet/ipaddr.html

[W3C] HyperText Markup Language (HTML): Working and Background Materials. http://www.w3.org/pub/WWW/MarkUp/

[Weh95] Grundlagen zur Erstellung von Protokollen für einen Koordinationskernel. Christian Wehrl 1995. Diplomarbeit am Institut für Computersprachen der Technischen Universität Wien.

[Yor96] Garbage Collection and LINDA. The York Linda Team 1996. http://www.cs.york.ac.uk/linda/index.html

[Zie95] Eine kleine Einführung in die Geschichte des Internet. H. Zierke 1995.