% PARTOF texte:da/tex/a_home.tex
%------------------------------------------------------------------------------
\chapter{Die Programmierumgebung Tycoon}
\label{tycoon}
Die persistente, polymorphe Programmierumgebung Tycoon eignet sich Aufgrund
ihrer bereits vorhandenen Systemdienste gut zur verteilten Programmierung und
damit zur Implementation des Modells f"ur verteilte Agenten. Hierf"ur sind
besonders die migrationsf"ahigen Threads, das dynamische Linken und die
Kommunikationsdienste f"ur heterogene Systeme n"utzlich.

\section{Allgemeine Konzepte}

Die Implementation aller im weiteren pr"asentierten Module erfolgte in der
streng typisierten, persistenten und polymorphen Programmierumgebung {\it
Tycoon}, die am Arbeitsbereich DBIS der Universit"at Hamburg entwickelt wurde. 
Sie basiert in weiten Teilen auf der funktionalen Programmiersprache {\it
Quest}~\cite{Card89}.
Eine detaillierte Beschreibung der vom Tycoon-System verwendeten Sprache TL ist
in \cite{MMM93,MMS94} nachzulesen. An dieser Stelle soll nur ein "Uberblick
"uber die Sprache TL und das Tycoon Language Environment gegeben werden.
 
\subsection{Werte und Typen}
Tycoon bietet sowohl statische als auch dynamische Bindungen von Werten an
Bezeichner. Statische Wertbindungen werden folgenderma"sen definiert:

\begin{xple}
\begin{tabbing}
{\bf let} $a = 3$
\end{tabbing}
\end{xple}

Nach Evaluation dieses Terms ist der Bezeichner a an den Wert 3 statisch
gebunden. Die rechte Seite der Bindung kann ein beliebiger Ausdruck sein. Wird
diese Bindung innerhalb eines \begin{bf} begin ... end \end{bf} Paars
geschrieben, so ist sie nur innerhalb dieses Blocks sichtbar.

\begin{xple}
\begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
{\bf let} a = 3\\
{\bf begin}\\
  \>{\bf let} a = 5\\
  \>{\bf let} b = a\\
{\bf end} \\
{\bf let} c = a\\
\end{tabbing}
\end{xple}

Hier wird der Bezeichner c an den Wert 3 gebunden,  da die lokale Bindung $a =
5$ au{\ss}erhalb des Blocks nicht sichtbar ist.
Dynamische Bindungen werden "uber Funktionen erzeugt. Tycoon verwendet
Funktionen als Elemente erster Ordnung und kennt rekursive Funktionen.
Funktionen werden durch das Schl"usselwort {\bf fun} eingeleitet und k"onnen an
Bezeichner gebunden werden.

\begin{xple}
\begin{tabbing}
{\bf let} succ = {\bf fun}(x {\bf :Int}) x+1
\end{tabbing}
\end{xple}
 
Hier wird die Funktion, die den Nachfolger einer ganzen Zahl berechnet, an den
Bezeichner {\it succ} gebunden. Der Bezeichner x ist eine dynamische
Bindung, die innerhalb des Funktionsrumpfs {\it $x+1$} sichtbar ist.

Im Funktionsrumpf sind sowohl die in der Signatur definierten Aktualparameter
sichtbar, als auch die im statischen Sichtbarkeitsbereich der Funktion
definierten globalen Bezeichner. Innerhalb des Funktionsrumpfs k"onnen
zus"atzlich beliebige weitere lokale Bindungen definiert werden.

Der Doppelpunkt leitet immer Typbezeichner ein. Folglich ist {\bf :Int} ein
(von TL vordefinierter Basis-) Typ des Formalparameters x. Es ist nicht immer
notwendig diesen Typ explizit anzugeben, in vielen F"allen ist die Typpr"ufung
des Tycoon-Systems in der Lage, diesen zu inferieren.

Da in TL alle Objekte typisiert sind, besitzt auch jede Funktion einen Typ. In
dem oberen Beispiel der Funktion {\it succ} ist dies: {\bf :Fun(:Int)
:Int}, also eine Funktion die genau ein Argument vom Typ {\bf :Int} erwartet
und einen Wert vom Typ {\bf :Int} als Ergebnis liefert.

Um Funktionen h"oherer Ordnung definieren zu k"onnen, ist solch ein
Funktionstyp notwendig.
   
\begin{xple}
\begin{tabbing}
{\bf let} twice = {\bf fun}(f {\bf :Fun}({\bf :Int}) {\bf :Int}  x {\bf :Int})
f(f(x))
\end{tabbing}
\end{xple}

Diese Funktion erwartet als erstes Argument eine Funktion vom Typ 
{\bf :Fun({\bf :Int}) {\bf :Int}} und als zweites Argument einen Wert vom Typ
{\bf {\bf :Int}}. Die Funktion selbst wendet die als Argument "ubergebene
Funktion (dynamisch an den Bezeichner f gebunden) zweimal an.

Neben den vordefinierten Basistypen {\bf :Int} {\bf :Bool} etc. gibt es die
M"oglichkeit eigene Typen zu vereinbaren. Zu diesem Zweck bietet TL die
Typkonstruktoren Tupel, Tupel mit Varianten, Records und Records mit Varianten.

\begin{itemize}
\item{Tupel sind geordnete Mengen von Bindungen.}

\begin{xple}
\begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
{\bf Let} Person = {\bf Tuple} \\
  \>name {\bf :String} \ age {\bf :Int} \\
{\bf end} \\
{\bf let} p :Person = {\bf tuple} \\
  \>``Peter'' \ 15 \\
{\bf end} \\
\end{tabbing}
\end{xple}

Auf die Komponenten eines solchen Tupels (der Wertbindung p) kann "uber die
Punktnotation zugegriffen werden.

\begin{xple}
\begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
p.name \\
$=>$ ``Peter''
\end{tabbing}
\end{xple}

\item{Records sind ungeordnete Mengen benannter Bindungen.}

\begin{xple}
\begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
{\bf Let} PersonRecord = {\bf Record}\\
  \>name {\bf :String} \ age {\bf :Int} \\
{\bf end}\\

{\bf let} p :PersonRecord = {\bf record} \\
  \>{\bf let} age = 12 \ {\bf let} name = ``Fred'' \\
{\bf end} \\
\end{tabbing}
\end{xple}

Auf die Komponenten eines Records wird ebenfalls "uber die Punktnotation
zugegriffen. Im Gegensatz zu Tupeln k"onnen Records dynamisch um neue
nicht-anonyme Bindungen erweitert werden.

\begin{xple}
\begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
{\bf let} p2 = {\bf extend} p {\bf with} \\
  \>{\bf let} semester = 1 \\
{\bf end} \\
\end{tabbing}
\end{xple}
\end{itemize}

Variante Tupel oder Recordtypen unterscheiden mehrere disjunkte und
benannte F"alle, mit jeweils eigenen Komponenten. Komponenten, die
allen F"allen gemeinsam sind, k"onnen vor der F"allunterscheidung
definiert werden. Werte dieser varianten Type k"onnen mit den Konstruktoren
{\bf tuple\_case} und {\bf record\_case} erzeugt werden, bei denen dann auch
die gew"unschte Variante angegeben werden mu"s. Auf die Komponenten
einses varianten Tupels bzw. eines varianten Records kann mittels eines
Projektionsoperators zugegriffen werden.

\begin{xple}
\begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
{\bf Let} Person = {\bf Tuple} \\
  \>name {\bf :String} \ age {\bf :Int} \\
  \>{\bf case} employee {\bf with} \\
  \>\>salary{\bf :Real} \\
  \>{\bf case} ceo \\
{\bf end} \\
{\bf let} peter = {\bf tuple\_case} ceo {\bf of} :Person {\bf with} \\
  \>``Peter'' \ 40 \\
{\bf end} \\
{\bf let} fred = {\bf tuple\_case} employee {\bf of} :Person {\bf with} \\
  \>``Fred'' \ 31 \\
  \>4600.0 \\
{\bf end} \\
\end{tabbing}
\end{xple}

\subsection{Subtypbeziehungen und Subtyppolymorphismus}
Signaturen der Form x :A stellen partielle Spezifikationen dar, die aussagen,
da"s x \begin{it} mindestens \end{it} A erf"ullt. Ein an den Bezeichner x
gebundener Wert kann aber eine genauere Spezifikation B erf"ullen. Die zugrunde
liegende partielle Ordnung auf Typen ''B ist pr"aziser als A'' wird durch die
induktiv definierte B $<:$A (B ist Subtyp von A) in TL explizit beschrieben.
\cite{Matt93} Der Supertyp aller nicht parametrisierten Typen ist
\begin{bf}Ok\end{bf}.

\begin{xple}
\begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
{\bf Let} Person = {\bf Tuple} \\
  \>name {\bf :String} \ age {\bf :Int} \\
{\bf end} \\

{\bf Let} Student = {\bf Tuple} \\
  \>name {\bf :String} \ age {\bf :Int} \ semester {\bf :Int} \\
{\bf end} \\

{\bf let} fred :Student = {\bf tuple} \\
  \>``Fred'' \ 20 \ 1 \\
{\bf end} \\

{\bf let} getPersonAge(p {\bf $<:$}Person) = p.age \\
\\
getPersonAge(fred); \\
$=>$ 20 \\
\end{tabbing}
\end{xple}
 
Die Funktion {\it getPersonAge} ist eine polymorphe Funktion, da sie keinen
expliziten Argumenttyp vorschreibt, sondern lediglich einen Mindesttyp
spezifiziert. Daher arbeitet die Funktion {\it getPersonAge} auch mit Werten
vom Typ :Student. Generell liefert die Funktion {\it getPersonAge} f"ur alle
denkbaren Typen ein Ergebnis, solange diese Subtyp des Types :Person sind. F"ur
Tupeltypen gilt die Subtypbeziehung A $<:$B solange A strukturell mit B
kompatibel ist. F"ur eine detaillierte Beschreibung der Subtypisierungsregeln
siehe \cite{Matt93}. Subtypbeziehungen gelten in TL f"ur alle in der Sprache
definierbaren Typen (einschliesslich der Basistypen).

\subsection{Module, Schnittstellen und Bibliotheken}
In TL werden Programmteile zur Unterst"utzung der Programmierung im
Gro"sen analog Modula-2 in Module und Schnittstellen getrennt. Ein Modul,
welches Funktionen anderer Module nutzen will, mu{\ss} diese importieren.
Zugreifen kann das Modul allerdings nur auf die Funktionen die in der
zugeh"origen Schnittstelle exportiert wurden. Die Schnittstellen bilden somit
die Typen der Module. Es besteht keine Notwendigkeit einer festen 1:1 Beziehung
zwischen Modulen und Schnittstellen. Jedes Modul kann beliebig viele
Schnittstellen haben, die dann unterschiedliche Sichten auf das Modul
darstellen. Auch kann jedes Schnittstelle zu beliebig vielen Modulen geh"oren,
wenn diese mindestens die in der Schnittstelle spezifizierten Elemente
exportieren.

\begin{minipage}[t]{4.5cm}
 \begin{xple}
  \begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
    {\bf module} a \\
    {\bf import} b \\
    {\bf export} \\
      \>{\bf let} f1(x {\bf :Int}) = b.f(x) \\
    {\bf end} \\
    \\
    {\bf interface} A \\
    {\bf export} \\
      \>f1({\bf :Int}) {\bf :Int} \\
    {\bf end} \\
  \end{tabbing}
 \end{xple}
\end{minipage}\hfill
\begin{minipage}[t]{5cm}
 \begin{xple}
  \begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
    {\bf module} b \\
    {\bf export} \\
      \>{\bf let} f(x {\bf :Int}) $= x+1$ \\
      \>{\bf let} g(x {\bf :Int}  y {\bf :Int}) $= x+y$ \\
    {\bf end} \\
    \\
    {\bf interface} B \\
    {\bf export} \\
      \>f({\bf :Int}) {\bf :Int} \\
    {\bf end} \\
  \end{tabbing}
 \end{xple}
\end{minipage}\hfill

Die Verbindung von Modul zur Schnittstelle wird "uber sog. Bibliotheken
hergestellt.

 \begin{xple}
\begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
{\bf library} test {\bf with} \\
  \>{\bf interface} B \\
  \>{\bf module} b :B \\
  \>{\bf interface} A \\
  \>{\bf module} a :A \\
{\bf end} \\
\end{tabbing}
 \end{xple}
     
\subsection{Persistenz}
Alle in TL beschreibbaren Bindungen k"onnen persistent werden, d.h. die
Ausf"uhrung des Tycoon-Prozesses "uberdauern. Tycoon nutzt hierf"ur einen
Objektspeicher, in dem s"amtliche Bindungen abgelegt werden. Die Bindungen
m"ussen nicht explizit als persistent gekennzeichnet werden; die Tycoon
Lauf\-zeit\-umgebung sorgt mittels Garbage-Collection f"ur das Beseitigen nicht
mehr referenzierter Bin\-dungen. Der Objektspeicher kann zu jeder beliebigen
Zeit eingefroren werden, um so nach einem Neustart des Systems sofort alle bis
dahin definierten Bindungen wieder bereitzustellen.

\subsection{Erweiterbarkeit um externe Bibliotheken}
\label{sec:TL-CAnbindung}
Ein wichtiger Bestandteil des Tycoon-Systems und der Sprache TL ist die
M"oglichkeit, externe Funktionsbibliotheken der verwendeten
Betriebssystemumgebung typsicher in TL-Programme einbinden zu k"onnen. Diese
Bibliotheken liegen entweder als sog. {\it 'shared-libraries'} vor oder werden
statisch an die virtuelle Tycoon-Maschine gebunden. Eine Funktion einer
externen Bibliothek wird "uber das \begin{bf} bind \end{bf}--Konstrukt dem
Tycoon-System bekannt gegeben.

\begin{xple}
\begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
{\bf let} tycoonFunction = \\
  \>{\bf bind}({\bf :Fun}({\bf :Int}) {\bf :Int}  ''libraryName''
''functionName'' ''externalSignatur'') \\ \\ tycoonFunction(5) \\ $=>$ 1017 \\
\end{tabbing}
\end{xple}

Funktionen, die in der Sprache 'C' geschrieben wurden, k"onnen leicht in TL
genutzt werden. Daf"ur mu"s f"ur jede 'C'-Funktion eine 'TL'-Signatur gefunden
werden und die Funktion entweder statisch an die Tycoon-Laufzeitumgebung
gebunden oder wie beschrieben in einer dynamisch bindbaren Bibliothek
organisiert sein.

Ein weiteres sehr n"utzliches Element des Tycoon-Systems ist die M"oglichkeit,
aus diesen 'C'-Funktionen wiederum 'TL'-Funktionen ausf"uhren zu lassen. Ein
solcher {\it 'C'-Callback} wird auf der Tycoon-Seite eingerichtet mit einem
Aufruf von:

\begin{xple}
\begin{tabbing}
\hspace*{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=
\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}\=\hspace{0.5cm}
\=\hspace{0.5cm}\=\kill
{\bf let} cTLFunktion = \\
  \>cCallback.new( ''tlFunktion''  ''externeSignatur'') \\
\end{tabbing}
\end{xple}

Der 'C'-Callback {\sl cTLFunktion} kann nun an eine beliebige 'C'-Funktion als
'C'-Funk\-ti\-ons\-zei\-ger\-ar\-gu\-ment "ubergeben werden. Wird innerhalb der 'C'-Funktion
die "ubergebene Funktion aufgerufen, so wird vom Tycoon-System die Funktion
''tlFunktion'' evaluiert und das Ergebnis an die aufrufende 'C'-Funktion
zur"uckgegeben. Ein 'C'-Callback unterliegt nicht der Garbage-Collection und
mu"s daher explizit freigegeben werden, wenn er nicht mehr verwendet werden
soll.

\section{Nebenl"aufigkeit und Synchronisationsmechanismen}

Tyoon unterst"utzt nebenl"aufige Programmierung "uber leichtgewichtige
Prozesse, sog. Threads. Threads sind orthogonal zu allen anderen Konzepten der
Progammiersprache TL verwendbar, insbesondere sind sie auch persistent
\cite{MaSc94}. Jede TL-Funktion kann bei Bedarf nebenl"aufig zu anderen
TL-Funktionen evaluiert werden, wenn sie als eigener Ausf"uhrungfaden (Thread)
vom aktuellen Thread abgespalten wird ({\em fork-Operation}). Da Threads
TL-Funktionen verwenden, gelten f"ur sie die normalen statischen
Sichtbarkeitsbereiche der Sprache. Werden ver"anderliche Bindungen von mehr als
einem Thread konkurrierend zugegriffen, so ist zur Wahrung der Konsistenz die
Synchronisation dieser Zugriffe notwendig. TL bietet hierf"ur die bekannten
Mechanismen Semaphore, Mutexe, Rendezvous und Ereignisvariablen in einer
Standardbibliothek an. Alle diese Verf"ahren basieren auf der gezielten
Unterbindung des Kontextwechsels der virtuellen Tycoon-Maschine \cite{Piel96}.

\section{Kommunikationsdienste}

Verteilte Programmierung mit dem Tycoon-System kann sich auf eine Reihe von
TL-Bibliotheken st"utzen, die eine Reihe unterschiedlicher
Kommunikationsabstraktionen f"ur den Entwickler bieten. Die Basis bildet eine
Kernbibliothek zur typsicheren Anbindung von Unix-Sockets (TCP bzw. UDP/IP) an
das Tycoon-System. Aufbauend auf diesen Kommunikationskan"alen (Streams), die
nur explizit typisierte TL-Objekte "ubertragen k"onnen, existiert ein
typisierter RPC-Mechanismus \cite{JO95}. Generell k"onnen beliebige TL-Objekte
"uber die Kommunikationsmechanismen in heterogenen Systemumgebungen ausgetauscht
werden. Die virtuelle Maschine "ubernimmt ggf. notwendige Konvertierungen
automatisch. Der RPC des Tycoon-Systems ben"otigt keine gesonderte IDL
(Interface Definition Language) zur Spezifikation von Dienstschnittstellen.
Stattdessen werden TL-Typen zur Beschreibung entfernter Dienste verwendet. Auf
diese Weise, und unter Verwendung von dynamischen Typen, k"onnen Funktionen
eines entfernten Dienstes vollst"andig statisch typisiert verwendet
werden\footnote{Die vollst"andige Typinformation liegt ja bereits zur
"Ubersetzungszeit des lokalen TL-Kodes vor.}.

\section{Bindungstechniken und Mobilit"at}
\label{Bindungstechniken}

Aufgrund der orthogonalen Einbindung von Threads in das Sprachgef"uge von TL
k"onnen Threads auch als Parameter f"ur entfernte Funktionen verwendet werden.
Geschieht dies, so wird ein Thread und seine transitive, referentielle
H"ulle auf den Zielrechner kopiert ({\em deep copying}). Auf diese Weise sind
Threads {\em mobil}. Da Threads eine reflexive Bindung an sich selbst besitzen,
k"onnen sie ihre eigene Migration veranlassen. Diese Technik bildet die Basis
f"ur einen mobilit"atsorientierten Programmierstil zur Beschreibung von
langlebigen Aktivit"aten \cite{MMS95a}.

Wird ein Thread in einen anderen Adressraum kopiert, so enth"alt dieser alle
Bindungen, die sich zum Zeitpunkt des Kopierens in seinem Sichtbarkeitsbereich
befanden und transitiv alle dar"uber erreichbaren. Hierbei k"onnen auch
Bindungen auf Objekte enthalten sein, deren Semantik eine Mobilit"at verbietet
oder nicht sinnvoll ist. Dies sind externe Ressourcen, die nicht unter der
direkten Kontrolle des Tycoon-Systems stehen, wie z.B. Datei-Deskriptoren oder
Fenster. Andererseits gibt es Objekte, deren Mobilit"at nicht erw"unscht ist,
z.B. im Tycoon-System verwaltet Massendatenbest"ande oder ubiquit"ar vorhandene
TL-Bibliotheken.

Tycoon bietet f"ur den Umgang mit solchen Objektbindungen zwei Ans"atze:

\begin{itemize}
\item Dynamisches Relinken.
\item Neuerzeugung fl"uchtiger Ressourcen.
\end{itemize}

Der Mechanismus des dynamischen Relinkens kann f"ur ubiquit"are Ressourcen
verwendet werden. Hierbei ist es erforderlich, jedes Objekt mit einem sog.
Linksymbol zu versehen und es "uber einen Funktionsaufruf von {\sl
ubiquitous.register(\dots)} bei der virtuellen Maschine als ubiquit"ar zu
registrieren. Kern des Verfahrens ist, jedes so registrierte Objekt immer dann
gegen das entsprechende Linksymbol zu ersetzen, wenn das Objekt f"ur den
Versand linearisiert werden soll. Auf der Empf"angerseite k"onnen dann, im Zuge
der Delinearisierung, transparent alle symbolischen Referenzen gegen die lokal
vorhandenen Objektreferenzen ersetzt werden.

Das Versenden fl"uchtige Ressourcen erfordert ein geordnetes zerst"oren und
wiedererzeugen der zug. externen Datenstrukturen, um die scheinbare Mobilit"at
zu erreichen. Zu diesem Zweck bieten die Funktionen des Moduls {\sl volatile}
eine Pseudo-Persistenz f"ur Objekte au"serhalb des Tycoon-Systems. Das dort
vorgesehene Protokoll erfordert hierf"ur ein Registrieren von entsprechenden
Funktionen f"ur die jeweilige fl"uchtige Ressource, mit denen diese kontrolliert
werden kann. Das Erzeugen und Zerst"oren, sowie die Einhaltung der korrekten
Reihenfolge, geschieht automatisch durch das Tycoon-System.

