% Diplomarbeit von Andreas Boesch
%
% Universitaet Hamburg
% Fachbereich Informatik
% Arbeitsbereich DBIS
%
% Kapitel: Kontexte im WWW

\chapter{Konfigurationsmanagement im WWW}
\label{Kap. kontexte}

Im vorherigen Kapitel wurde gezeigt, da"s die Versionierung von Ressourcen im WWW die Stabilit"at von Hyperlinks unterst"utzt, indem einzelne Hyperlinks versioniert werden und so auf eine unver"anderliche spezifische Version einer Ressource zeigen. Diese Ressource steht unter der Kontrolle eines Versionierungssystems, das "Anderungen an der Ressource in neuen Versionen ablegt, anstatt die vorhandene Instanz zu "andern.

Versionierung in Hypermediasystemen erfordert nicht nur die Verwaltung von Revisionen und Varianten einzelner Objekte beliebigen Typs, sondern auch das versionierte {\em Konfigurationsmanagement} von Strukturen und Beziehungen, die zwischen diesen bestehen \cite{HLS91}. Konfigurationsmanagment kontrolliert die Evolution eines Produktes u.a. durch die Identifikation seiner Komponenten und Ver"anderungen \cite{F91}. 

Eine {\em Konfiguration} umfa"st eine Menge von Objekten innerhalb eines Systems und ihre Beziehungen untereinander. So ist z.B. eine Menge von Klassen, die ein Softwaresystem bilden, eine Konfiguration. Im WWW kann man z.B. die Struktur einer Softwaredokumentation, die sich aus HTML Dokumenten und Bildern zusammensetzt, als Konfiguration auffassen. Solche Konfigurationen k"onnen im WWW auch andere Objekttypen enthalten, z.B. Audio- oder Videodateien, {\java} Klassen, CGI Skripte, etc. Benutzer des WWW m"ochten lesenden Zugang zu verschiedenen Versionen von Objekten haben, wie z.B. Dokumentationen von HTML, HTTP oder SQL Standards. Diese Objekte k"onnen aus mehreren Teilobjekten zusammengesetzt sein und Konfigurationen bilden. F"ur den Benutzer ist es wichtig, da"s er in solchen Konfigurationen kontextabh"angige Hyperlinks zur Verf"ugung gestellt bekommt, d. h. in Objekten vorkommende Hyperlinks m"ussen auf die in diesem Kontext richtigen Versionen anderer Objekte zeigen. 

Werden die einzelnen Objekte einer Konfiguration versioniert, mu"s festgelegt werden, welche Version eines Objektes zu einer Konfiguration geh"ort. Abbildung~\ref{konfigAuswahl} zeigt drei Objekte, die jeweils in mehreren Versionen vorliegen. Die Konfigurationsbeschreibung legt fest, welche Versionen zur Konfiguration geh"oren. Die Bestimmung der zu einer Konfiguration geh"orenden spezifischen Versionen der einzelnen Komponenten kann auf zwei Arten erfolgen:


\begin{description}
\item[statisch:]
Es wird zum Erstellungszeitpunkt der Konfigurationsbeschreibung festgelegt, welche Version eines Objektes zu einer Konfiguration dazugeh"ort.
\item[dynamisch:]
Die Auswahl der zu einer Konfiguration geh"orenden spezifischen Version eines Objektes wird erst zum Auswertungszeitpunkt der Konfigurationsbeschreibung bestimmt. So ist es m"oglich, festzulegen, da"s z.B. immer die aktuellste Version eines Objektes zu einer Konfiguration geh"ort.
\end{description}

\begin{figure}[htb]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=4cm
\epsffile{Bilder/kontexte/konfigAuswahl.eps}
\end{center}
\caption{Zuordnung von versionierten Objekten zu Konfigurationen}
\label{konfigAuswahl}
\end{figure}


Werkzeuge f"ur das Konfigurationsmanagement bieten M"oglichkeiten zur eindeutigen Identifikation der Komponenten einer Konfiguration und der Beziehungen zwischen ihnen. Das Konfigurationsmanagementwerkzeug {\em make} \cite{H94} z.B. benutzt dazu eine Beschreibung der Konfiguration in Form einer speziellen Datei --- dem {\em makefile}. 

Im Folgenden wird zuerst die eindeutige (evtl. dynamische) Spezifikation verschiedener Versionen einzelner Objekte im WWW als Voraussetzung f"ur das Konfigurationsmanagement erl"autert ({\VAS}~\ref{verAnker}). In Abschnitt~\ref{konfWWW} wird die Notwendigkeit des Konfigurationsmanagement f"ur WWW Ressourcen motiviert. Danach werden verschiedene M"oglichkeiten zur Realisierung von Konfigurationsmanagment im WWW dargestellt ({\VAS}~\ref{realKont}).

\section{Versionierung von Ankern}
\label{verAnker}
{\em Anker} sind die Endpunkte von Hyperlinks. Anker k"onnen einerseits einen ganzen Knoten in einem Netzwerk bezeichnen, wie z.B. eine HTML Seite oder ein Bild. Zum anderen k"onnen Anker eine bestimmte Stelle in einem Knoten bezeichnen ({\em interner Anker}). Auf der Ebene der nicht internen Anker kann die Versionierung statisch oder dynamisch mit Hilfe von Attributen erfolgen, z.B. k"onnte ein Anker, der stets dynamisch auf die aktuelle Version eines Objektes zeigen soll, ein Attribut {\em version=head} haben:
\begin{xple}
$<$a href="'http://www.foo.bar/doc.html;version=head"'$>$ Link zum ak\-tu\-el\-len Do\-ku\-ment $<$/a$>$
\end{xple}
Eine "altere Version w"are statisch mit der Angabe eines Datums oder einer Versionsnummer zu referenzieren, z.B.:
\begin{xple}
$<$a href="'http://www.foo.bar/doc.html;version=1.3"'$>$ Link zu der Version 1.3 des Do\-ku\-men\-tes $<$/a$>$
\end{xple}
Nicht interne Anker lassen sich wie oben beschrieben mit Hilfe eines erweiterten URL versionieren. In HTML ({\VAS}~\ref{html}) werden interne Anker als Markierung einer bestimmten Stelle in einem Dokument definiert:
\begin{xple}
$<$a name="'info"'$>$ Ein beliebiger Text$<$/a$>$
\end{xple}
Befindet sich dieser Anker z.B. in einem Dokument "'doc.html"' wird er von einem anderen Dokument referenziert mit:
\begin{xple}
$<$a href="'doc.html\#info"'$>$ Link zu einem beliebigen Text$<$/a$>$
\end{xple}
Eine sichere Referenzierung von internen Ankern ist nur m"oglich, wenn explizit die Version des den internen Anker umgebenden Objektes angegeben wird. Dies k"onnte folgenderma"sen erfolgen:
\begin{xple}
$<$a href="'doc.html;version=1.3\#info"'$>$ Link zu einem beliebigen Text$<$/a$>$
\end{xple}
Wird keine spezifische Version in der Referenz auf den internen Anker angegeben, ist es m"oglich, da"s die vom Konfigurationsmanagementwerkzeug ausgew"ahlte Version (z.B. die neuste) diesen internen Anker nicht mehr enth"alt oder er mit einer anderen Semantik besetzt ist.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Konfigurationen im WWW}
\label{konfWWW}

Im WWW werden Konfigurationen durch die Verbindung einzelner Objekte mittels Hyperlinks hergestellt. Jede HTML Seite, die Hyperlinks enth"alt, baut explizit eine Beziehung zu anderen Ressourcen auf und ist, wenn sie von anderen Hyperlinks referenziert wird, implizit Teil einer oder mehrerer solcher Beziehungen. Der Autor eines Hyperlinks kann mit diesem zwei unterschiedliche Intentionen verfolgen:

\begin{description}
\item[Eine allgemeine Referenz] bezieht sich auf das allgemeine Thema eines Zielobjektes (z.B. einer HTML Seite). Hierbei ist die Version des Objektes nicht relevant. 
\item[Eine spezifische Referenz] bezieht sich auf den exakten Inhalt des Zielobjektes. Die Version des Zielobjektes ist hier entscheidend f"ur die Integrit"at der Referenz.
\end{description}

Ein Beispiel soll die obige Definition verdeutlichen. Der im folgenden Beispiel enthaltene Hyperlink referenziert eine spezifische Version der HTML Spezifikation n"amlich die Version 2.0 und ist somit eine spezifische Referenz. 

\begin{xple}
$<$a href="'http://www.foo.bar/html-spec\_toc.html"'$>$HTML$<$/a$>$ ist in der Version 2.0 stan\-dar\-di\-siert.
\end{xple}

Spezifische Referenzen erfordern bei einer Abfrage einer Ressource exakt den gleichen Zustand der Ressource, den diese zum Zeitpunkt der Erstellung der Referenz hatte. W"ahrend in obigem Beispiel die Ersetzung der Ressource durch einen neuen HTML Standard den Hyperlink ung"ultig machen w"urde, bliebe er im n"achsten Beispiel weiter g"ultig, da er hier die Intention einer allgemeinen Referenz verfolgt.

\begin{xple}
$<$a href="'http://www.foo.bar/html-spec\_toc.html"'$>$HTML$<$/a$>$ ist eine auf SGML basierende Seitenbeschreibungssprache.
\end{xple}


Um die Integrit"at spezifischer Referenzen zu bewahren, mu"s der jeweilige Hyperlink entweder explizit versioniert werden --- z.B. durch eine versionierte URL:

\begin{xple}
$<$a href="'http://www.foo.bar/html-spec\_toc.html;version=2.0"'$>$HTML$<$/a$>$ ist in der Version 2.0 stan\-dar\-di\-siert.
\end{xple}

--- oder der Hyperlink mu"s Teil eines Kontextes sein. Ein {\em Kontext} ist eine Menge spezifischer Versionen von Links, die als eine Einheit betrachtet, benannt und referenziert werden k"onnen \cite{HLS91}. In Abbildung~\ref{kontext} ist ein Kontext mit dem Namen "`WWW 1995"' abgebildet. Er enth"alt eine Menge spezifischer Versionen von Hyperlinks.  

\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=5cm
\epsffile{Bilder/kontexte/kontext.eps}
\end{center}
\caption{Ein Kontext}
\label{kontext}
\end{figure}


Der Kontext k"onnte dann z.B. auf Basis der Quellressource des Hyperlinks die passende Version der Zielressource bestimmen. In Abbildung~\ref{linkKontext} ist zum einen die Beziehung von Quelle, Hyperlink und Ziel ohne die Unterst"utzung von Kontexten visualisiert und zum anderen die Spezifikation einer Version eines Hyperlinks unter Zuhilfenahme eines Kontextes. 
 
\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=6cm
\epsffile{Bilder/kontexte/linkKontext.eps}
\end{center}
\caption{Auswahl einer Version durch einen Kontext}
\label{linkKontext}
\end{figure}

Bewegt sich ein Benutzer z.B. durch eine bestimmte Version einer aus vielen Dokumenten bestehenden Softwaredokumentation, wird jeder Hyperlink durch den Kontext auf die entsprechende Version des Zielobjektes umgeleitet. Der Vorteil der Verwendung von Kontexten besteht also darin, da"s die in den einzelnen Ressourcen enthaltenen Hyperlinks keine Versionsinformationen enthalten m"ussen und keine "Anderungen an den Hyperlinks einer Ressource erforderlich werden, wenn eine neue Version der Ressource erzeugt wird.

Angenommen ein Dokument "`http://foo.bar/www.html"' enth"alt Hyperlinks zu den im Kontext "`WWW 1995"' enthaltenen Zielen. Der Kontext sorgt dann f"ur die Auswahl der richtigen Version der Zielressource. Das hei"st, die im Dokument "`http://foo.bar/www.html"' enthaltenen Hyperlinks sind nicht versioniert (z.B. durch Angabe einer Versionsnummer "`.../htmlSpez.html;version=2.0"') sondern enthalten lediglich die "ublichen Links auf das Zielobjekt (z.B. "`.../htmlSpez.html"'). Wird das Dokument "`http://foo.bar/www.html"' "uberarbeitet, m"ussen lediglich die Versionen der Links im Kontext "`WWW 1995"' ge"andert werden. Allerdings gibt es dann keinen Zugriff mehr auf alte Versionen des Kontextes und der Name des Kontextes ist semantisch nicht mehr korrekt. Es ist also w"unschenswert, da"s Kontexte selbst ebenfalls versioniert werden. 

In Abbildung~\ref{kontextVersioniert} ist das Dokument "`http://foo.bar/www.html;version=1.0"' dem Kontext "`WWW;ver\-si\-on= 1.0"' zugeordnet und die enthaltenen Hyperlinks werden entsprechend dem Stand des Jahres 1995 versioniert. Das Dokument "`http://foo.bar/www.html;version=3.0"' hingegen wird in diesem Beispiel dem Kontext "`WWW;version=3.0"' zugeordnet, damit die enthaltenen Hyperlinks entsprechend dem Stand des Jahres 1997 versioniert werden.\footnote{Die schwarzen Punkte in der Abbildung stellen weitere m"ogliche Versionen des Dokumentes "`http://foo.bar/www.html"' bzw. des Kontextes "`WWW"' dar.}


\begin{figure}[hbt]
\begin{center}
\leavevmode
\epsfxsize=13cm \epsfysize=10cm
\epsffile{Bilder/kontexte/kontextVersioniert.eps}
\end{center}
\caption{Ein versionierter Kontext}
\label{kontextVersioniert}
\end{figure}

M"oglichkeiten zur Realisierung des Kontextmanagement werden im n"achsten Abschnitt vorgestellt.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Realisierung von Kontexten}
\label{realKont}
Das Problem des Konfigurationsmanagement ergibt sich als Folge der Integration von Versionierungsmechanismen in Hypermediasysteme wie dem WWW. Ein {\em Kontext} ist eine Menge spezifischer Versionen von Links, die als eine Einheit betrachtet, benannt und referenziert werden k"onnen. In diesem Abschnitt werden Ansatzm"oglichkeiten\footnote{Eine Implementation dieser Ans"atze k"onnte zum Gegenstand weitergehender Untersuchen genutzt werden ({\VAS}~\ref{ausblick}).} zur Realisierung von Kontexten untersucht.  

\subsection{Kontextmanagement durch den Server}
\label{kMServer}

Ein Kontext auf dem Server besteht aus einer Menge von nicht versionierten URLs, die jeweils einer versionierten URL zugeordnet sind. Erh"alt ein Server eine Anfrage nach einer Ressource, mu"s der Client als zus"atzlichen Parameter der Anfrage den Namen eines Kontextes mitliefern, der f"ur diese Anfrage gelten soll. Danach pr"uft der Server, ob die URL der Anfrage des Client in dem spezifizierten Kontext enthalten ist. Ist dies der Fall, wird anstatt der URL der Anfrage die dieser im spezifizierten Kontext zugeordnete versionierte URL vom Server mit der HTTP Methode betraut.

Die Realisierung w"are z.B. m"oglich, indem beim erstmaligen Betreten eines Kontextes der Server dem Client einen {\net} Cookie ({\VAS}~\ref{cgi}) mit dem Namen des Kontextes "ubergibt, der bei jedem Aufruf des Servers wieder an diesen zur"uckgegeben wird. Dieser kann dann mit Hilfe eines CGI Skriptes oder einer erweiterten Serverfunktionalit"at Anfrage und Kontext auswerten und die entsprechende Ressource ausliefern. 

Die Zuordnung von spezifischen Versionen zu Kontexten kann im {\em Revision Control System} (RCS) mit Hilfe von symbolischen Namen vorgenommen werden \cite{BB95}. Ein symbolischer Name kann genau einer Version einer Ressource zugeordnet werden. Einer Version k"onnen jedoch mehrere symbolische Namen gegeben werden. Im Zusammenhang mit Kontexten in Hypermediasystemen hei"st das, da"s jede Version einer Ressource in mehreren Kontexten enthalten sein kann, ein Kontext jedoch nur eine Version einer Ressource beinhalten darf. Ein symbolischer Name bezeichnet hier alle zu einem Kontext geh"orenden Versionen in verschiedenen Archivdateien. Ein CGI Skript oder eine Servererweiterung mu"s zur Bestimmung der spezifischen Version einer Ressource den in der Anfrage mitgelieferten Kontextnamen mit dem symbolischen Bezeichner der verschiedenen Versionen der angeforderten Ressource vergleichen und die entsprechende Version identifizieren und ausliefern.

\subsection{Kontextmanagement durch den Client}
\label{kMClient}
Das Kontextmanagment durch den Client kann wie in Abschnitt~\ref{wwwvsup} beschrieben mit Hilfe von Konfigurationsdateien erfolgen, die nicht versionierte URLs versionierten URLs zuordnen und wie ein Filter die jeweiligen Anfragen des Client beeinflussen.

Die automatische Ersetzung einer URL einer Anfrage beim Client ist ein potentielles Sicherheitsrisiko f"ur den Benutzer, da er beim automatischen Laden und Anwenden von Konfigurationsdateien nicht sicher sein kann, da"s er tats"achlich die von ihm gew"unschte Ressource erh"alt, da die Konfigurationsdatei URLs automatisch auf andere Rechneradressen umleiten kann. So sollte durch den Benutzer definierbar sein, ob eine Konfigurationsdatei eine komplette URL ersetzen oder nur Versions- bzw. Kontextinformation hinzuf"ugen darf.  


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



