
\section{Protokoll zum externen Aufruf von \emph{Tycoon}-Funktionen (TIP)}
Zur Visualisierung von Hypertext soll die Technologie des WWW benutzt werden.
Der Hypertext soll jedoch von einem Programm erzeugt werden, das mit Hilfe der
Programmiersprache \emph{TL} beschrieben wird.  Die aus \emph{TL} generierten
Programme befinden sich normalerweise in einem \emph{Tycoon}-Objektspeicher und sind
auch nur von hier aus aufrufbar. Ben"otigt wird also eine Verbindung zwischen
WWW und \emph{Tycoon}-Objektspeicher. Diese Verbindung soll es erlauben, Funktionen
eines \emph{Tycoon}-Objektspeichers von au\ss erhalb des Objektspeichers, also von Programmen,
die sich nicht im Objektspeicher befinden, aufzurufen. Ferner soll es m"oglich sein,
den Funktionen des Objektspeichers beim Aufruf Parameter zu "ubergeben. Das Ergebnis
der Ausf"uhrung einer Funktion soll an den Aufrufer zur"uckgegeben werden.

Da f"ur das \emph{Tycoon}-System bereits eine Bibliothek mit Funktionen zur
Kommunikation "uber ein Netzwerk vorhanden ist, bietet es sich an, eine
Verbindung zwischen Programmen innerhalb und au\ss erhalb eines
\emph{Tycoon}-Objektspeichers als Client/Server Paar zu implementieren.

Das Protokoll, das die Kommunikation zwischen Client und Server regelt, hei\ss
t TIP (\emph{Tycoon Interface Protocol}). Mit TIP ist es einem, sich nicht in
einem \emph{Tycoon}-Objektspeicher befindlichen, Programm m"oglich, in einem
\emph{Tycoon}-Objekt\-speicher befindliche Funktionen aufzurufen. Der Aufrufer kann der
Funktion Parameter "ubergeben. Das Ergebnis der Funktion wird an den Aufrufer
zur"uckgegeben (vgl. Abb. \ref{TIPFIG}).

Es folgt die Beschreibung des Protokolls von Client und Server sowie die
Beschreibung eines f"ur diese Studienarbeit implementierten TIP-Clients und
eines TIP-Servers.

\begin{figure}[h]
  \centering{ \includegraphics*{tip.eps}}
\caption{Kommunikation externer Programme mit einem \emph{Tycoon}-Server}
\label{TIPFIG}
\end{figure}

\subsection{Das Protokoll}
Das TI-Protokoll ist textbasiert und transferiert ausschlie\ss lich Zeichenketten
zwischen Client und Server. Nachdem der Client eine Verbindung zu einem
TIP-Server aufgebaut hat, schickt er diesem die TIP-Kennung ``TIP'', erg"anzt
um die Versionsnummer, und anschlie\ss end eine mit einem leeren Paar
abgeschlossene Folge von Namen/Werte Paaren.  Anhand des ausgezeichneten
Wertepaares mit Namen \emph{SERVICE\_NAME}, ermittelt der TIP-Server die zu
aktivierende Funktion und ruft diese auf. Als Ergebnis dieser Funktion wird
vom TIP-Server eine Zeichenkette erwartet, welche an den Client zur"uckgegeben wird.
Anschlie\ss end baut der Server die Verbindung zum Client ab. Die Verpflichtung des
Clients zur Spezifikation des zu erbringenden Service erlaubt es dem
TIP-Server, eine Vielzahl von Servicefunktionen zum Aufruf anzubieten.

\begin{figure}[h]
  \centering{ \includegraphics*{protTip.eps}}
\caption{Beispielkommunikation zwischen TIP-Client und TIP-Server}
\label{PROTEXP}
\end{figure}

Abbildung \ref{PROTEXP} zeigt eine Beispielkommunikation zwischen TIP-Client
und TIP-Server. Der TIP-Client wurde in diesem Beispiel von einem CGI-Gateway
ge\-startet. Das Gateway "ubergibt dem Client seine Umgebungsvariablen sowie den
Namen der aufzurufenden Funktion und einen Parameter. Ergebnis ist
der in HTML konvertierte Quelltext der \emph{Tycoon}-Schnittstelle {\tt Lines.ti}
(im Protokoll abgek"urzt dargestellt).

TIP hat nur zwei Kommunikationsphasen, zuerst transferiert der Client die
f"ur den Funktionsaufruf n"otigen Parameter, anschlie\ss end gibt der Server
das Ergebnis des Aufrufs an den Client zur"uck. Es ist auch m"oglich, ein
mehrphasiges Protokoll zu verwenden. Beispielsweise braucht der Client zu
Anfang nur den Namen der aufzurufenden Funktion anzugeben. Die Servicefunktion
stellt nun f"ur jeden Parameter eine Anfrage an den Server und  dieser gibt die
Anfrage an den Client weiter. Das Ergebnis wird vom Client "uber den Server an
die Servicefunktion zur"uckgegeben. Vorteil eines solchen Protokolls ist die
erh"ohte Flexibilit"at, da die Servicefunktion je nach Bedarf Anfragen stellen
kann. Nachteil ist der erh"ohte Programmieraufwand der Servicefunktion. Es
ist auch m"oglich, den TIP-Ansatz sowie den eben beschriebenen zu
kombinieren. Dies w"urde eine Erweiterung des TI-Protokolls sowie der
Serverobjektspezifikation (siehe Abschnitt \ref{tipServer}) erfordern.


\subsection{Der Server} \label{tipServer}
Zur Unterst"utzung der Implementation eines TIP-Servers existiert das
Tycoon-Modul \emph{TipServer}. Abbildung \ref{itfTipServer} zeigt die
exportierten Funktionen.

\begin{figure}[h]
  \input{TipServer.ti.tex}
\caption{TIP-Serverschnittstelle}
\label{itfTipServer}
\end{figure}

Das Modul \emph{TipServer} implementiert einen generischen TIP-Server.  Es
k"onnen beliebig viele TIP-Serverobjekte erzeugt werden. Jedes
TIP-Serverobjekt belegt einen Netzwerkport. Bei einem Serverobjekt k"onnen
beliebig viele Servicefunktionen angemeldet werden.

Die vom TIP-Client an den TIP-Server "ubergebene Menge von benannten
Zeichenketten werden der Servicefunktion als Parameter in Form einer Tabelle
"ubergeben. Es ist Aufgabe der Servicefunktion, die f"ur sie wichtigen
Parameter aus der Tabelle auszuw"ahlen. Eine eindeutige Zuordnung von Namen zu
Werten ist m"oglich, da das Modul \emph{TipServer} mit Hilfe von HashTabellen
implementiert wurde. Der Schl"ussel eines jeden Eintrags einer Tabelle ergibt
sich aus dem Namen des Eintrags. Ist ein Name nicht eindeutig, so ist auch
sein Schl"ussel nicht eindeutig, was zur Folge hat, das die Funktion zum
Hinzuf"ugen eines Eintrags zu einer Hashtabelle eine Ausnahme generiert.

\begin{figure}[h]
  \input{exServInst.tex}
\caption{Beispiel f"ur einen TIP-Server}
\label{exTipServer}
\end{figure}

Abbildung \ref{exTipServer} zeigt ein Beispiel f"ur die Erzeugung und
Verwendung eines TIP-Servers. Dieses Beispiel ist f"ur die Verwendung in einem
\emph{Tycoon}-TopLevel gedacht. Zu Anfang wird ein Serverobjekt erzeugt (\textit{ts}),
dieses belegt nach seiner Erzeugung einen Netzwerkport. Dem Serverobjekt wird
daraufhin eine Servicefunktion (\textit{webService}) hinzugef"ugt. Nach der anschlie\ss enden
Aktivierung wartet das Serverobjekt auf Verbindungsanfragen von Clients.
Sollte eine Ausnahme bei der Bearbeitung einer Servicefunktion auftreten, so
kehrt die Serveraktivierungsfunktion zur"uck und das n"achste Kommando wird
bearbeitet. In diesem Fall wird das Serverobjekt gel"oscht.

Der hier implementierte Server f"ur TIP ist nicht in der Lage, mehrere
Verbindungsanfragen von Clients gleichzeitig zu bearbeiten. Er stellt auch
keine Funktionen zur Verf"ugung, um zu ermitteln, welche Servicefunktionen
schon vorhanden sind.


\subsection{Der Client} \label{tipClient}
Zur Kommunikation mit dem TIP-Server wird ein in der Programmiersprache
\emph{C} implementierter Client verwendet. Tabelle \ref{tipClientParameter}
zeigt die Menge der m"oglichen Optionen des Clients. 

\begin{table}[h]
  \begin{center}
    \begin{tabular}{|l|l|}
      \hline Option & Beschreibung \\ \hline -help & Ausgabe einer
      Parameterbeschreibung \\ -debug & Ausgabe von Debuginformation \\ -port
      & Spezifikation des Server Ports \\ -server & Spezifikation des Servers
      \\ Name / Wert & Benannte Parameter f"ur den Service \\ \hline
    \end{tabular}
    \caption{Parameter des TIP-Clients}
    \label{tipClientParameter}
  \end{center}
\end{table}


Ein Beispielaufruf sieht folgenderma\ss en aus:
\begin{verbatim} 
tipClient -port 6001 -server dbis11 SERVICE_NAME MeinService Wert1 1 Wert2 2 
\end{verbatim}

Durch die Optionen \textit{port} und \textit{server} wird der Server
ausgew"ahlt. Die angegebene Menge von benannten Werten wird an den Server
"ubertragen. Anhand des Wertes mit Namen \emph{SERVICE\_NAME} w"ahlt der
Server die Servicefunktion aus. Das Ergebnis des Aufrufs der Servicefunktion
wird an den TIP-Client und von diesem an seinen Aufrufer zur"uckgegeben.

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "quas"
%%% End: 


