Private Sichten auf das WWW

Oliver Becker, Jens-Peter Redlich
Institut für Informatik, Humboldt-Universität zu Berlin

Mit der Einführung des Personal Computers (PC) hatte der Nutzer erstmals die Möglichkeit, das Arbeitsinstrument "Computer" bezüglich Hardware und Software seinen individuellen Bedürfnissen optimal anzupassen.
Heutzutage werden viele der ihn interessierenden Dienste von Netzwerken, z.B. dem Internet, angeboten. Anders als beim PC hat der Nutzer keine Handhabe, den Aufbau des Netzwerks gemäß seinen Wünschen zu gestalten. Er muß die Menge der Dienste und ihre organisatorische Verwaltung als etwas Unabänderliches hinnehmen.
In diesem Artikel zeigen wir, wie man die mit dem PC assoziierte Idee der persönlichen Arbeitsumgebung im Kontext des Internets wiederbeleben kann und welche Vorteile sich daraus für den Nutzer ergeben.

Einleitung

Mit der Einführung des World Wide Web (WWW) vor wenigen Jahren wurde das Internet schlagartig für eine große Anzahl von Benutzern interessant. Auf verschiedenartige, über den ganzen Globus verteilte Informationen kann dank der Beschreibungssprache HTML mit Hilfe graphischer HTML-Browser kinderleicht zugegriffen werden. Sowohl die Anzahl der Anwender als auch die Anzahl der Informationsanbieter im Internet hat sich seither vervielfacht.

Mittlerweile gibt es HTML-Browser für alle gängigen Plattformen und Betriebssysteme. Inzwischen können sie auch weit mehr, als nur einfachen Text anzeigen. Andere Dienste des Internet, wie e-Mail, ftp oder News sind soweit in das WWW integriert, daß keine speziellen Kenntnisse mehr zu ihrer Benutzung benötigt werden. Über interaktive Gestaltungselemente kann der Anwender Informationen mit Anbietern im Netz austauschen. Auf diese Weise entwickeln sich Anbieter von statischen Informationen allmählich zu spezialisierten Diensterbringern. Gängige Beispiele sind Auskunftssysteme für WWW-Adressen (sogenannte Suchmaschinen), für Postleitzahlen oder Online-Wörterbücher.

Der allbekannte HTML-Browser entwickelt sich damit mehr und mehr zur universellen Bedienoberfläche der Zukunft. Gleichzeitig wandelt sich das "Netz" vom einfachen Übertragungsmedium zwischen Rechnern zum universellen globalen Dienstanbieter. Viele Dienste müssen nicht mehr lokal vom eigenen Rechner realisiert werden, sondern können z.B. über das WWW angefordert werden. Dabei ist es in der Regel unerheblich, welcher Rechner im Netz den Dienst letztendlich erbringt. Der eigene Rechner mutiert schrittweise zum universellen, mit eigener Intelligenz ausgestatteten Zugangspunkt zum Netz (Terminal). Der Kauf und die Installation großer Softwarepakete werden damit hoffentlich einmal der Vergangenheit angehören. Alle benötigten Dienstleistungen werden dann von (vermutlich auch kommerziellen) Dienstanbietern des Netzes bereitgestellt. Dafür treten nun Fragen der Abrechnung und Entlohnung für die Erbringung von Diensten in den Vordergrund.

Diese Entwicklung wirft aber auch neue Probleme auf, für die wir in diesem Artikel Lösungen skizzieren wollen. Durch den rapiden Zuwachs der im Netz verfügbaren Ressourcen wird es für den Benutzer immer schwieriger, das vorhandene Angebot zu überblicken. Zukünftig wird es also nötig sein, die Menge der verfügbaren Netzwerkressourcen für jeden Nutzer individuell einzuschränken. Jeder Nutzer schafft sich eine von administrativen Gesichtspunkten unabhängige Sicht auf das Netz, die an seinen persönlichen Bedürfnissen orientiert ist und ihm einen optimalen Zugriff auf bestimmte, von ihm benötigte Dienste des Netzes ermöglicht. Wir werden diese maßgeschneiderte Arbeitsumgebung im weiteren als personalisierte Arbeitsumgebung des Nutzers bezeichnen.

Personalisierte Arbeitsumgebungen

Eine wesentliche Voraussetzung für die effektive Nutzung des Netzes durch den "ganz normalen Nutzer" besteht folglich in der Bereitstellung von personalisierten Arbeitsumgebungen durch das Netz. Die wichtigsten Gründe, die zu dem Wunsch nach solchen Arbeitsumgebungen führen, werden hier kurz zusammengetragen:

Nutzer möchten, daß sie auf Netzwerkdienste überall in derselben Weise zugreifen können, unabhängig davon, von welchem Endgerät aus der Zugang zum Netz erfolgt. Die Struktur der ihnen bereitgestellten Arbeitsumgebung soll dabei allein an ihre Person, aber nicht mehr an die lokale Rechner- und Betriebssystem-Konfiguration gebunden sein.
Die wachsende Menge potentiell verfügbarer Dienste und Medien (ASCII-, Postscript-, RTF-, HTML-Text; X.500-Einträge; GIF-, TIFF-, JPEG-Bilder; SND-, WAV-, MULAW-, ADPCM-Audiodaten; JPEG-, MPEG-Videos, usw.) wird für den Durchschnittsnutzer immer weniger überschaubar. Zum einen wird eine Vielzahl dieser Dienste gar nicht benötigt, zum anderen besteht für viele von ihnen ohnehin keine Zugangsberechtigung.
Nutzer möchten daher individuell die Menge der für sie sichtbaren Ressourcen auf ein überschaubares Maß einschränken können.
Viele Ressourcen im Netz sind in der Lage, mehrere Dienste zu erbringen. Ebenso kann ein Dienst über verschiedene Zugriffsmechanismen verfügbar gemacht werden.
Nutzer möchten daher festlegen können, welche Eigenschaft einer Ressource im Netz sie benötigen und in welcher Form ihnen eine bestimmte Funktionalität angeboten wird.

Zusammenfassend legt also die Arbeitsumgebung eines Nutzers auf abstrakte Weise fest, welche Ressourcen des Netzes für den Nutzer sichtbar sind, und in welcher Form auf sie zugegriffen werden kann. Die konkreten Anbieter von Diensten müssen in Abhängigkeit vom Aufenthaltsort des Nutzers dynamisch bestimmt werden. Gegebenenfalls müssen dabei auch Kompromisse eingegangen werden, etwa hinsichtlich der Qualität oder des Preises des erbrachten Dienstes.

Die aus dem WWW bekannten Homepages stellen bereits eine Vorstufe solcher personalisierten Arbeitsumgebungen dar. Ihre Adresse, ein URL (Uniform Resource Locator), ist weltweit eindeutig. Der Zugriff ist von jedem beliebigen Ort mittels eines HTML-Browsers möglich. Die dargestellte Seite erscheint dabei prinzipiell immer in der gleichen Form, selbst wenn man textbasierte Browser wie lynx berücksichtigt. Über in das HTML-Dokument eingebaute Verweise, sogenannte Links, kann auf andere Dienste im WWW zugegriffen werden.

In der Regel sind solche Homepages allerdings statischer Natur. Sie enthalten damit Bestandteile, die an bestimmten Orten wenig Sinn ergeben. So wird ein in seiner Homepage eingebauter Verweis auf das Kinoprogramm seines Heimatortes für einen Dienstreisenden sicher nutzlos sein. Was er bräuchte, wäre ein generischer Verweis auf das aktuelle Kinoprogramm an seinem augenblicklichen Aufenthaltsort.

Eine solcherart mit Intelligenz ausgestattete Homepage fungiert dann nicht mehr als Präsentationsseite nach außen, sondern als universeller, auf die Bedürfnisse des Nutzers ausgerichteter Einstiegspunkt zum Netz.

Architekturvorschlag

Im folgenden wird die prototypische Implementation eines Systems vorgestellt, das dem Nutzer - abhängig vom Aufenthaltsort - seine Arbeitsumgebung in Form einer HTML-Seite bereitstellt. Es besitzt im wesentlichen die folgenden Komponenten:

einen Netzwerkdienst User Profile Service (UPS), der für einen Nutzer eine abstrakte Beschreibung seiner persönlichen Arbeitsumgebung verwaltet. Bei dieser Beschreibung handelt es sich um ein HTML-Dokument, das neben den herkömmlichen Bestandteilen auch Spezifikationen von Ressourcen enthält, die der aktuellen Aufenthaltsumgebung des Nutzers zu entnehmen sind. Ein solches Dokument werden wir im folgenden abstrakte Arbeitsumgebung Personal Working Environment (PWE) nennen.
eine Vermittlungs-Komponente (PWE-Trader), die aus der vom UPS bereitgestellten abstrakten PWE eine aktuelle Instanz (instantiierte oder aktuelle PWE) bildet, indem die darin enthaltenen abstrakten Ressourcenbeschreibungen durch vor Ort verfügbare reale Ressourcen ersetzt werden.
einen Network Infrastructure Information Service (NIIS), der den PWE-Trader mit Informationen darüber versorgt, welche Ressourcen für den Nutzer an einem gegebenen Ort tatsächlich zur Verfügung stehen.
ein universelles, möglicherweise nicht stationäres Netzendgerät - Mobile Intelligent Network Terminal (MINT) -, das die Darstellung der aktuellen PWE sowie den Zugriff auf enthaltene Ressourcen ermöglicht.

Der letztgenannte Punkt - das MINT - wird, bedingt durch die Wahl des Mediums WWW, durch beliebige HTML-Browser realisiert. Da somit eine Verteilung von spezieller Software an die Anwender entfällt, ist der von uns implementierte Dienst sofort global verfügbar. Inwieweit gängige Browser unseren Anforderungen genügen, bedarf weiterer kritischer Untersuchungen. Wir werden am Ende des Artikels darauf zurückkommen.

Abbildung 1 gibt einen zusammenfassenden Überblick über die Komponenten des Systems und veranschaulicht ihr Zusammenwirken.

Abbildung 1: Bereitstellung personalisierter Arbeitsumgebungen im WWW.

UPS

Die Aufgabe des Netzwerkdienstes UPS besteht in der Verwaltung und Bereitstellung persönlicher Arbeitsumgebungen. Dazu müssen sowohl der Nutzer selbst (gesichert durch eine entsprechende Authentisierung) als auch sein Aufenthaltsort bekannt sein.

In unserem Fall kann diese Aufgabe sehr einfach durch einen WWW-Server (httpd) erfüllt werden. Da jedoch die aktuelle PWE eines Nutzers bei jeder Abfrage neu erzeugt werden muß (um auf zwischenzeitliche Änderungen der Umgebung zu reagieren), kann der Server nicht einfach ein statisches, als Datei vorliegendes HTML-Dokument zurückliefern. Statt dessen muß er mittels eines CGI-Skriptes die aktuelle PWE jedesmal neu "errechnen".

CGI steht dabei für Common Gateway Interface und ist durch eine Sammlung von Programmen, meist Shell-Skripten, realisiert, die über einen URL adressiert werden können (z.B. http://www.hu-berlin.de/cgi-bin/skript1). Diese CGI-Skripte werden vom Betreiber eines WWW-Servers installiert und erzeugen dynamisch ein HTML-Dokument als Ausgabe, das dem Browser als Antwort auf seine Anfrage zurückgeliefert wird. Bei der Ausführung eines CGI-Skripts stehen in den Umgebungsvariablen REMOTE_HOST der Rechnername und in REMOTE_ADDR die IP-Adresse des HTML-Browsers (also des MINT) zur Verfügung. Diese Informationen reichen allerdings in vielen Fällen zur Lokalisierung des Nutzers nicht aus, wie dies z.B. beim Zugang über einen Telefonanschluß (Modem) zum Internet der Fall ist. Folglich muß der Nutzer den UPS mit weiteren Lokalisierungsinformationen versorgen. Dies können beispielsweise Telefonnummern bei stationären Anschlüssen oder physische Koordinaten auf der Erdoberfläche sein, wie man sie beispielsweise mit einem bereits in PCMCIA-Format erhältlichen Global Positioning System (GPS) ermitteln kann.

Unbedingt zu beachten ist, daß vom HTML-Browser keine Proxy- WWW-Server verwendet werden dürfen, da in diesem Fall der UPS die physische Adresse dieses Proxy-Servers und nicht die des Nutzer-Terminals (MINT) in der Variablen REMOTE_ADDR erhalten würde. Damit könnten vom UPS falsche Rückschlüsse auf den aktuellen Aufenthaltsort des Nutzers gezogen werden.

Für die Authentisierung eines Nutzers gibt es mehrere Möglichkeiten. Zum einen lassen sich die durch das Protokoll http bereits vorgesehenen Mechanismen nutzen. Der Zugriff auf ein Verzeichnis läßt sich durch das File .htaccess regeln. Dieses hat z.B. das in Abbildung 2 gezeigte Aussehen.

   AuthName User Profile Service
   AuthType Basic
   AuthUserFile /var/httpd/conf/passwd
   AuthGroupFile /var/httpd/conf/group

   <LIMIT GET>
   require valid-user
   </LIMIT>

Abbildung 2: Regelung des Zugriffes auf Dokumente eines WWW-Servers mittels .htaccess.

Um auf ein vom UPS (httpd) bereitgestelltes Dokument zuzugreifen, übermittelt das MINT (d.h. der HTML-Browser) die folgende Zeichenkette an den Server:

   GET /ups/access HTTP/1.0

Daß es sich bei dem als /ups/access spezifizierten Dokument um ein CGI-Skript handelt, ist dabei nur dem Server bekannt.

Befindet sich auf dem Server im Verzeichnis /ups die oben skizzierte Datei .htaccess, so wird vom Nutzer eine Authentisierung mit Paßwort verlangt. In diesem Fall kann innerhalb des Skriptes der Name des Nutzers über die Umgebungsvariable REMOTE_USER ermittelt werden. Diese Vorgehensweise besitzt den Vorteil, daß die notwendige Authentisierung bereits durch das Zusammenspiel von HTML-Browser (MINT) und httpd-Server (UPS) durchgeführt wird. Nutzer, die nicht in der Paßwort-Datei /var/httpd/conf/passwd registriert sind, erhalten keinen Zugang. Nachteilig wirkt sich die Tatsache aus, daß auf diese Weise keine zusätzlichen Lokalisierungsinformationen übertragen werden. Zudem können als Nutzerkennungen nur die üblichen, aus acht Zeichen bestehenden Namen verwendet werden.

Zum anderen können die zur Authentisierung benötigten Informationen mit der Methode POST vom MINT zum UPS übertragen werden. Dazu bietet es sich an, auf der Eingangsseite des UPS das in Abbildung 3 dargestellte Formular bereitzustellen.

   <FORM METHOD=POST 
         ACTION="http://ups.informatik.hu-berlin.de/ups/access">
   <PRE>
   User:     <INPUT TYPE=text     SIZE=33 NAME=user><BR>
   Password: <INPUT TYPE=password SIZE=33 NAME=password><BR>
   Location: <INPUT TYPE=text     SIZE=33 NAME=location><BR>
   </PRE>
   <INPUT TYPE=submit VALUE="Enter network">
   </FORM>

Abbildung 3: Anmeldeformular für den Benutzer eines MINT.

Damit ergibt sich allerdings innerhalb des Skriptes /ups/access der Aufwand, die in der folgenden Form übertragenen Daten einzulesen und sie für die Weiterverarbeitung in geeigneter Form bereitzustellen:

   POST /ups/access HTTP/1.0 

   user=somebody&password=MySecret&location=phone%28001+1234%29

Einige Zeichen werden dabei gesondert kodiert übertragen. So verbirgt sich beispielsweise hinter der Variablen location der Wert phone(001 1234).

Weiterhin muß durch das Skript die Authentisierung des Nutzers anhand der Werte von user und password durchgeführt werden. Ein entsprechendes CGI-Skript (als Perl-Skript realisiert) ist in Abbildung 4 zu sehen.

   #!/usr/bin/perl

   $| = 1;                                  # schalte "flushing" ein
   print "Content-type: text/html\n\n";     # http-Header
   $line = <STDIN>;
   chop($line);
   do {
      ($record,$line) = split('&', $line, 2);
      ($f1,$f2) = split('=', $record, 2);
      if ($f1 eq "location") {
         $location = $f2;
         # Dekodierung der geposteten Informationen
         $location =~ tr/+/ /;
         $location =~ s/%([0-9A-F][0-9A-F])/chr(hex($1))/eg;
         # Definition der Umgebungsvariablen REMOTE_LOCATION
         $ENV{"REMOTE_LOCATION"} = $location;
      }
      # ... analog Einlesen von user und password 
      # ... Setzen der Umgebungsvariablen REMOTE_USER
   } until $line eq "";

   # Authentisierung
   $pwd = (getpwnam($username))[1];
   $salt = substr($pwd, 0, 2);
   if (crypt($password, $salt) ne $pwd) {
       $check_passwd = "wrong";
   }

Abbildung 4: Erster Teil des CGI-Skripts /ups/access. Hier wird die Anfrage an den UPS (httpd) aufbereitet und die Authentisierung des Nutzers durchgeführt.

Die Dekodierung der durch das Formular erfaßten Daten erfolgt, indem zunächst alle Pluszeichen in Leerzeichen umgewandelt und anschließend die in Hexadezimalform kodierten Zeichen in ihre normale Darstellung zurückverwandelt werden.

Als Nutzernamen lassen wir zunächst (analog zur ersten Variante) nur normale UNIX-Accounts zu. Zur Überprüfung des Paßwortes wird hier der Einfachheit halber die Nutzer-Paßwortdatei herangezogen.

Problematisch für beide Möglichkeiten der Authentisierung ist der geringe Schutz der übertragenen Daten. So werden die mittels POST gelieferten Einträge des Formulars im Klartext über das Netz geschickt, insbesondere auch das Paßwort. Die vom http-Protokoll verwendete Verschlüsselungsmethode Basic (siehe AuthType im File .htaccess) läßt sich ebenfalls relativ einfach wieder entschlüsseln. Fortschritte sind hier mit der Weiterentwicklung des http-Protokolls und dem von Netscape entwickelten Verfahren der Secure Sockets Layer (SSL) zu erwarten.

Zu guter Letzt muß der in Abbildung 5 wiedergegebene zweite Teil des Skriptes access die dem Nutzer gehörende abstrakte PWE bereitstellen (Zeile 1 und 2) und sie in eine aktuelle PWE umwandeln (ab Zeile 4).

   $userhome = (getpwnam($username))[7];
   $filename = $userhome . "/.public_html/PWE/index.pwe";

   if (-r $filename && $check_passwd ne "wrong") {
      $pwetrader = "/var/httpd/htdocs/ups/pwetrader " . $filename;
      system($pwetrader);
   }
   else {
      # ... geeignete Fehlerausschrift in HTML
   }

Abbildung 5: Im zweiten Teil des CGI-Skriptes /ups/access wird die abstrakte PWE bereitgestellt und in eine aktuelle PWE umgewandelt.

Jeder in unserem System registrierte Nutzer kann folglich in der Datei $HOME/.public_html/PWE/index.pwe seine eigene abstrakte PWE hinterlegen. Der mit dieser Datei als Argument aufgerufene PWE-Trader erzeugt daraus eine aktuelle Instanz und schreibt sein Ergebnis auf die Standardausgabe. Das so erzeugte HTML-Dokument wird vom UPS (httpd) zum MINT (HTML-Browser) zurückgeliefert und von diesem dem Nutzer präsentiert.

PWE-Trader

Neben der abstrakten PWE als Eingabedatei benötigte der PWE-Trader noch Informationen über den Nutzer und seinen Aufenthaltsort. Diese werden ihm über die Umgebungsvariablen REMOTE_USER, REMOTE_HOST, REMOTE_ADDR und REMOTE_LOCATION mitgeteilt. Durch den NIIS wird unter Berücksichtigung dieser Variablen eine Liste verfügbarer Ressourcen bereitgestellt, aus denen der PWE-Trader eine geeignete auswählen muß. Dazu können verschiedene Strategien verwendet werden (z.B. die erste passende oder wenn möglich, dann die gleiche wie letztes Mal, usw.).

Die abstrakte PWE ist im wesentlichen ein HTML-Dokument. In ihm können, eingeschlossen in die für unsere Zwecke zusätzlich eingeführten Tags <PWE> und </PWE>, abstrakte Ressourcen spezifiziert werden. Dabei gibt es zunächst die Möglichkeit, den Inhalt von Umgebungsvariablen mittels $VARIABLE auszugeben:

   Ihr Remote-Rechner heißt: <PWE> $REMOTE_HOST </PWE>.

Für den Aufbau einer Ressourcen-Spezifikation ist in Abbildung 6 eine entsprechende Grammatik angegeben.

   description : resource ("|" resource)*
   resource    : resourceName (attribute)*
   attribute   : attributeName op value
   op          : "=" | "<" | ">" | "<=" | ">=" | "<>"
   value       : String | Integer | Real

Abbildung 6: Aufbau einer Ressourcen-Spezifikation in einer abstrakten PWE.

Pro Beschreibung können alternativ mehrere durch senkrechte Striche (|) getrennte Ressourcen mit abnehmender Priorität angegeben werden. Jede Ressourcen-Anforderung besteht dabei aus einem Namen und einer Liste von Attributen, die spezielle Eigenschaften dieser Ressource spezifizieren.

Angenommen, wir benötigen einen Laserdrucker mit mindestens 300 dpi. Falls ein solcher nicht verfügbar ist, würden wir uns auch mit einem Farb-Tintenstrahldrucker zufrieden geben, vorausgesetzt, der Preis pro Seite liegt unter 10 (Pfennigen). Diese Anforderung läßt sich nun wie folgt spezifizieren:

   <PWE>
   printer type=laser    dpi>=300 |
   printer type=inkColor price<10
   </PWE>

Schließlich sind an jeder Stelle innerhalb der PWE-Tags mit dem Hash-Zeichen (#) beginnende Zeilenendekommentare möglich.

Als Besonderheit wurde die Ressource text message=... eingeführt. Sie ist immer verfügbar (Notanker) und führt dazu, daß ein entsprechender Text mit der hinter message angegebenen Ausschrift bereitgestellt wird. Mit ihrer Hilfe lassen sich geeignete Fehlermeldungen formulieren, falls für keine der vorangehenden Ressourcen eine Entsprechung gefunden werden konnte:

   <PWE>
   printer type=laser    dpi>=300 |
   printer type=inkColor price<10 |
   # kein Drucker gefunden ...
   text    message="no printer!"
   </PWE>

NIIS

Informationen darüber, welche realen Ressourcen augenblicklich beim Nutzer vor Ort vorhanden sind, werden dem PWE-Trader vom Network Infrastructure Information Service (NIIS) geliefert. Ausgestattet mit der Kenntnis der Identität des Nutzers, seines Aufenthaltsortes und der angeforderten Ressourcen liefert diese Komponente eine Liste realer Ressourcen aus der aktuellen Aufenthaltsumgebung des Nutzers, zusammen mit diversen Attributen (z.B. Zugriffsrechte, Benutzungskosten).

In der jetzigen prototypischen Implementation erhält der NIIS seine Informationen aus einer lokalen Datenbank, in der Informationen über Rechner und vorhandene Ressourcen eingetragen sind. Abbildung 7 zeigt ein Beispiel.

	artus	merlin
printer	type=laser dpi=400 `{ Raum 220 }`	-
phone	`{ Raum 221 }`	`{ Raum 221 }`

Abbildung 7: Vom NIIS ermittelte Ressourcen-Aufstellung.

Für einen Nutzer am Rechner artus ist als Drucker ein Laserdrucker mit 400 dpi im Raum 220 verfügbar, während am Rechner merlin kein Drucker zur Verfügung steht. Die Frage nach dem nächsten Telefon liefert für beide Rechner einen Hinweis auf Raum 221. Die tabellenartige Darstellung verführt zu der Annahme, daß pro Rechner-Ressourcen-Paar maximal eine reale Ressource zur Verfügung steht. Dies ist in der Regel nicht der Fall. Weiterhin fehlen in diesem Beispiel Angaben darüber, welche Nutzer diese Ressourcen unter welchen Umständen überhaupt benutzen dürfen.

Abbildung 8 verdeutlicht noch einmal die vom NIIS beeinflußte Arbeitsweise des PWE-Traders.

Abbildung 8: Die Übersetzung einer abstrakten PWE in eine aktuelle PWE erfolgt durch den PWE-Trader unter Zuhilfenahme der vom NIIS ermittelten Angaben über die beim Nutzer vor Ort verfügbaren Ressourcen.

Global eindeutige Ressourcen

Zusätzlich zu lokal angeforderten Ressourcen können innerhalb der abstrakten PWE auch global eindeutige Ressourcen angegeben werden. Solche Ressourcen sind in der Regel Daten auf bestimmten Rechnern, wie z.B. die Mailbox eines Nutzers oder die Datenbank eines Unternehmens. Solche eindeutig adressierbaren Ressourcen müssen durch den PWE-Trader nicht mehr umgewandelt werden. (1) Sie werden in der abstrakten PWE bereits durch ihre endgültigen URLs spezifiziert. Auf Server-Seite (d.h. durch UPS und PWE-Trader) muß lediglich dafür gesorgt werden, daß der Zugriff auf diese Ressourcen z.B. über CGI-Skripte ermöglicht wird.

Ein prinzipielles Problem besteht dabei in der Autorisierung des Ressourcen-Zugriffs. Der Dämon httpd arbeitet in einem UNIX-System beispielsweise in der Regel unter dem User-ID -1 (nobody). Damit hat er zunächst keinen Zugriff auf geschützte Daten, wie z.B. auf die Mailbox eines Nutzers. Ein entsprechendes Programm, das diesen Zugriff ermöglichen soll, muß daher dem privilegierten Nutzer root gehören und in seinen Zugriffsrechten die set-uid-and-gid-on-execution-Bits gesetzt haben. Nach erfolgter Authentisierung des Nutzers gegenüber dem UPS kann dieses Programm seinen effektiven User-ID auf den des Nutzers setzen und so mit definierten Zugriffsrechten die Ressource benutzen.

Ein Nachteil des Protokolls http besteht in der Tatsache, daß es ein zustandsloses Protokoll ist. Nach der Beantwortung einer Anfrage wird die Verbindung zwischen HTML-Browser und Server (httpd) gelöst, die Authentisierungsinformationen auf Server-Seite gehen wieder verloren. Jeder neue Zugriff benötigt damit eine erneute Authentisierung durch den Nutzer. Bei Verwendung des http-eigenen Authentisierungsverfahrens wird der Nutzer davon verschont, da der HTML-Browser einen einmal abgefragten Nutzernamen und das dazugehörige Paßwort speichert und von sich aus bei Bedarf an den Server sendet. Davon machen wir nun Gebrauch, um uns die erneute Programmierung einer Authentisierung für den Zugriff auf die Mailbox eines Nutzers zu ersparen.

Zunächst trägt der Nutzer in seine PWE einen Verweis auf ein "Mail-Programm" ein, dem als Parameter die Mail-Datei übergeben wird. Der UPS (httpd) muß folglich über das lokale Filesystem auf diese Datei zugreifen können. Die entsprechende Passage in der als HTML-Dokument bereitgestellten aktuellen PWE könnte für den Nutzer somebody so aussehen:

   <A HREF="/ups/mail.pl?/usr/spool/mail/somebody">meine Mail</A>

Hinter mail.pl verbirgt sich das in Abbildung 9 abgebildete Perl-Skript, das unter Zuhilfenahme des Programmes rootcat die angegebene Datei einliest und eine entsprechende neue Seite erzeugt. Das in C geschriebene Programm rootcat ermittelt über die Umgebungsvariable REMOTE_USER den angemeldeten Nutzer, setzt seinen effektiven User-ID auf den des Nutzers und führt anschließend das Programm cat aus.

   #!/usr/bin/perl

   $user = $ENV{"REMOTE_USER"};
   $mailfile = $ENV{"QUERY_STRING"};
   print "<HTML><HEAD><TITLE>Mail</TITLE></HEAD>\n";
   print "<BODY><H1>Mailbox of user $user</H1>\n";
   print "<TABLE>\n";
   $count=0;
   open (MAIL, "rootcat " . $mailfile . "|");
   while ( $line = <MAIL> ) {
      if ($line =~ /^From /) {         # Beginn einer Mail
         # ... Parsen von Titel ($subject) und Absender ($from)
         $count = $count + 1;
         print "<TR> <TD> $count ";
         print "<TD> <A HREF=\"showmail.pl?$count&$mailfile\">";
         print "$from </A>";
         print "<TD> <A HREF=\"showmail.pl?$count&$mailfile\">";
         print "<strong>$subject</strong></A><BR>\n";
      }
   }
   close (MAIL);
   print "</TABLE></BODY></HTML>\n";

Abbildung 9: Bereitstellung eines Mail-Zugangs mit definierten Zugriffsrechten.

Für jede Mail wird ein Link innerhalb einer Tabelle erzeugt, über den dann auf diese Mail zugegriffen werden kann. Das ebenfalls in Perl geschriebene Skript showmail.pl besitzt den gleichen prinzipiellen Aufbau wie mail.pl. Als Parameter wird zusätzlich zur Mail-Datei die Nummer der Mail übergeben.

Ausblick

Die hier vorgestellte prototypische Implementation von personalisierten Arbeitsumgebungen mit Hilfe des WWW sollte einen Eindruck vermitteln, welche Perspektiven sich in Zukunft im Netz bieten.

Zur Demonstration haben wir an unserem Institut vor kurzem einen User Profile Service in Betrieb genommen. Jeder Student oder Mitarbeiter des Institutes kann für sich eine abstrakte PWE erstellen und über den UPS darauf zugreifen. Hinter dem URL

   http://ups.informatik.hu-berlin.de

verbirgt sich eine Eingangsseite, die das anfangs beschriebene Formular enthält. Zusätzlich haben wir einen Gastzugang guest geschaffen, der die hier vorgestellten Beispiele noch einmal demonstriert, unter anderem auch das Mail-Beispiel. Da wir zur Zeit mit der Implementation des NIIS noch ganz am Anfang stehen, werden mit großer Sicherheit keine Ressourcen außerhalb unseres Instituts zur Verfügung gestellt werden können.

Für die Zukunft sind noch eine Reihe von Problemen zu lösen: Zunächst muß eine geeignete verteilte Implementation des NIIS geschaffen werden. Offenbar kann nicht ein NIIS-Server allein Wissen über Ressourcen der ganzen Welt verwalten, vielmehr wird er sich anderer Dienste zur Informationsbeschaffung bedienen müssen (z.B. X.500, IN). Zur Implementation eines weltweiten NIIS kann der Namensdienst des Internet (DNS) als technologische Vorlage dienen. Besitzt der lokale Server kein Wissen über ein bestimmtes Gebiet auf der Erde, so gibt es vielleicht einen anderen Server, an den die Frage delegiert werden kann. Weiterhin sind Agenten denkbar, die nur Wissen über bestimmte Arten von Lokalisierungsinformationen verwalten, etwa nur über GPS-Koordinaten oder Telefonnummern. Wir werden in Kürze die Implementation eines solchen verteilten NIIS auf der Basis von CORBA in Angriff nehmen.

Weiterer Forschungsbedarf besteht in der Weiterentwicklung der Ressourcen-Spezifikation für den PWE-Trader. Hier sollten sich auch logische Verknüpfungen in der Art: "Ich benötige diese und diese Ressource, ansonsten zwei andere" ausdrücken lassen. Weiterhin sollte jeder Nutzer bei Bedarf seinen eigenen PWE-Trader einsetzen können. Denkbar wäre auch ein universeller PWE-Trader, der sich umfangreich konfigurieren läßt, etwa hinsichtlich der Auswahlstrategie.

Abhängig von dem vom Nutzer verwendeten Endgerät (z.B. stationäre Workstation mit schnellem Netzzugang oder über ein Funknetz angeschlossener Laptop) müssen zukünftig verschiedene PWEs bereitgestellt werden können. Auf diese Weise kann auch ein einfaches Telefon zum Netzendgerät werden, indem beispielsweise eingegangene Mails vorgelesen oder ihr Ausdruck per Fax über ein Voice-Menü veranlaßt werden kann.

Weiterhin müssen alle Ressourcen nach außen ein einheitliches Interface bereitstellen, über das auf sie zugegriffen werden kann. Im günstigsten Fall läßt sich der gewünschte einheitliche Zugriff auf das http-Protokoll abbilden und das Interface in HTML "programmieren". Dies dürfte eine starke Vereinfachung in der Bedienung unterschiedlichster Ressourcen für den Benutzer mit sich bringen. In diesem Fall kann der HTML-Browser tatsächlich die Bedienoberfläche der Zukunft werden. Große Hoffnungen setzen wir in dieser Richtung auf die Einbeziehung von Java-Applets, wie sie zur Zeit beispielsweise von Netscape genutzt werden können. Eine gegenwärtig von der Firma IONA entwickelte Verbindung von Java und CORBA würde dann schließlich sogar den Zugriff auf alle über CORBA (und damit dank dem CORBA 2.0 Interoperability-Standard unter anderem auch über DCE) erreichbaren Ressourcen ermöglichen.

1 Gegebenenfalls müssen abhängig vom Endgerät verschiedene Repräsentationen bereitgestellt werden. Da wir uns hier aber auf die Verwendung von HTML-Browsern als MINT beschränken, entfällt dieser Fall.