\documentclass[a4paper,12pt]{article} \usepackage[latin1]{inputenc} \usepackage[T1]{fontenc} \usepackage{color} \usepackage{ngerman} \usepackage{graphicx} \usepackage{ae,aecompl} \begin{document} \definecolor{Blue}{rgb}{0.,0.,1.} \newcommand{\url}[1]{\texttt{\textcolor{Blue}{\underline{#1}}}} \title{Mobile Code} \author{Georg Lukas\\ Seminar Ubiquitous Computing\\ Universität Magdeburg} %\date{2003-01-29} \date{2003-11-16} \maketitle \begin{abstract} Auf dem Markt existieren zahlreiche Werkzeuge zur Entwicklung mobilen Codes, die zum Teil unterschiedliche Anforderungen erfüllen und nicht für jedes Szenario alle benötigten Funktionen bieten. Ziel dieser Ausarbeitung ist es, eine Klassifizierung dieser Werkzeuge vorzustellen, und an praktischen Beispielen zu zeigen, wie man diese Klassifizierung anwendet. Insbesondere wird auch auf Paradigmen, Sprachen und Sicherheitsaspekte eingegangen. \end{abstract} \renewcommand{\baselinestretch}{0.0} \tableofcontents \renewcommand{\baselinestretch}{1.0} \clearpage \section{Einführung} In den letzten Jahren gab es einen starken Schub in der Entwicklung von Computernetzen und daran gebundener Geräte. Zu nennen sind neben Netzwerkdruckern, DSL-Modems und WLan-AccessPoints auch PDAs, Handys und bald auch zentral gesteuerte Haushaltsgeräte, die mit immer mehr Speicher und schnelleren Prozessoren ausgestattet werden. Dieser Entwicklungsschub wurde jedoch nicht von einer vergleichbaren wissenschaftlichen Entwicklung im Bereich des Softwaredesigns für vernetzte Systeme begleitet, was zum einen dazu führte, dass die verwendete Terminologie nicht einheitlich ist oder sich überlagert, zum anderen aber, dass die eingesetzte Software nicht optimal an die Verbreitung und die neuen Fähigkeiten der Hardware angepasst ist. Der Schwerpunkt dieses Artikels ist \emph{Code Mobility} -- die Fähigkeit, die Bindung zwischen Code-Fragmenten und dem Ort ihrer Ausführung dynamisch zu verändern. Dabei wird auch auf die Unterschiede und Ähnlichkeiten zu anderen Verfahren eingegangen. Das weit verbreitete Client-Server-Paradigma sollte hinterfragt werden, wenn Clients immer mehr eigene Ressourcen haben, und die zentralen Server nicht mit der Auslastung skalieren können -- hier können die im nächsten Abschnitt vorgestellten Alternativen für Abhilfe sorgen. Danach geht es um die grundlegenden Kriterien von Mobile-Code-Systemen, also Sprachen und Umgebungen, die Code-Mobilität erlauben. Wichtig dabei ist auch der Sicherheitsaspekt bei der Ausführung von nicht vertrauenswürdigem Code, auf den der vierte Abschnitt eingeht. Schließlich wird dann darauf eingegangen, wie diese Kriterien von existierenden Mobile-Code-Systemen umgesetzt werden. \clearpage \section{Paradigmen} Das Design-Paradigma, welches man für eine Anwendung wählt, hat Einfluss auf alle weiteren Schritte der Entwicklung, daher sollte die Entscheidung für ein bestimmtes Paradigma wohlüberlegt sein. Weiterhin sollte das verwendete Werkzeug an dem Paradigma ausgerichtet sein -- es ist zwar auch möglich, mit nicht angepassten Tools Programme nach einem Designmuster zu schreiben, allerdings muss man dabei die musterspezifische Funktionalität selbst implementieren, statt sie vom Entwicklungssystem oder der Programmiersprache übernehmen zu können. Im Folgenden werden drei Paradigmen vorgestellt, die Code-Mobilität umsetzen, und miteinander sowie mit dem Client-Server-Modell verglichen. Um die Auswahl des passenden Konzepts zu erleichtern, werden hier Methoden vorgestellt, nach denen die Praxistauglichkeit von Paradigmen für eigene Szenarios untersucht werden kann. Um die Klassifizierung zu erleichtern, werden hier mehrere Begriffe definiert: \begin{itemize} \item \emph{Komponenten} sind die Grundeinheiten dieser Strukturierung. Sie unterteilen sich in \emph{code components}, die ausführbare Algorithmen enthalten, \emph{resource components} (Daten oder Gerätetreiber) und \emph{computational components}, welche in der Lage sind, Code-Komponenten auszuführen. \item \emph{Sites} sind Orte zum Speichern und Ausführen von Komponenten. Sie besitzen zu diesem Zweck meist eigene computational components. Sites werden durch reale oder virtuelle Maschinen repräsentiert. \item \emph{Interaktionen} sind Ereignisse oder Nachrichten, die zwischen unterschiedlichen Komponenten ausgetauscht werden -- man unterscheidet zwischen lokalen und site-übergreifenden Interaktionen, wobei die ersten mit kleinerem Aufwand (und damit kleineren Kosten) verbunden sind. \end{itemize} Um Code ausführen zu können, muss sich die entsprechende Co\-de-\-Kom\-po\-nen\-te zusammen mit allen benötigten Daten und Ressourcen auf einer Site befinden. Ferner wird dazu eine Rechenkomponente benötigt. Die einzelnen Paradigmen unterscheiden sich darin, wo sich die Komponenten vor Anfang der Ausführung befinden, und wohin das Ergebnis der Ausführung kommuniziert wird. Die Eignung eines Paradigmas für ein konkretes Problem sollte man daran bemessen, welcher Aufwand nötig ist, um alle zur Berechnung erforderlichen Komponenten auf die ausführende Site zu bewegen, und dann das Ergebnis an den Empfänger mitzuteilen. Der Aufwand kann über die Interaktionskosten gemessen werden, die wiederum vom Umfang und der Entfernung der zu transportierenden Daten abhängen. \subsection{Client-Server} Das in Computer-Netzen am weitesten verbreitete Paradigma ist das Client-Server-Modell. Obwohl es keine Code-Mobilität anbietet, wird es hier wegen seiner Bedeutung und als Referenz aufgeführt. Bei diesem Modell befindet sich ein Teil der Datenkomponenten vor der Ausführung auf dem Client, Code- und Rechenkomponente sowie weitere Daten sind dagegen auf dem Server. In einer ersten Interaktion übermittelt der Client seine für die Berechnung erforderlichen Daten an den Server, der dann die Code-Komponente ausführt, und das Ergebnis -- wiederum eine Daten-Komponente -- an den Client zurückschickt. Dieses Paradigma ist mit zwei Nachteilen verbunden. Zum einen ist der Server ein Single Point of Failure, so dass bei Ausfall oder Überlastung alle Clients betroffen sind. Zum anderen ist die Schnittstelle zwischen Client und Server starr vorgegeben -- ein Client kann nicht davon abweichen, um Interaktionskosten zu sparen, weil er nur eine Teilmenge der Daten braucht, und er kann nicht Informationen erhalten, die bei der Entwicklung der Schnittstelle nicht bedacht wurden. Weiterhin muss das Protokoll auf beiden Seiten einheitlich implementiert sein, Erweiterungen müssen immer beidseitig erfolgen, um genutzt werden zu können. \subsection{Code On Demand} Das Code-On-Demand-Modell (COD) sieht eine zentrale Speicherung des Codes vor. Wenn auf einer Site Daten vorliegen, die bearbeitet werden müssen, so fordert sie die benötigten Code-Komponenten vom zentralen Server an und arbeitet den Algorithmus mit lokalen Daten und Ressourcen auf der lokalen Rechenkomponente ab. Danach kann die Code-Komponente entweder verworfen oder für zukünftige Berechnungen zwischengespeichert werden, wobei man dabei vor der nächsten Ausführung das Vorhandensein einer aktualisierten Version auf dem Server überprüfen muss. Dieses Modell setzt wie das vorangegangene einen zentralen Server voraus, der auch hier eine Schwachstelle darstellt. Allerdings muss er nur Code-Komponenten ausliefern und braucht weder komplizierte Berechnungen\linebreak[4] durchzuführen, noch große Mengen an Daten oder Ressourcen vorzuhalten. COD bietet sich an, wenn auf einer großen Menge an Rechnern häufig modifizierte oder aktualisierte Software laufen soll -- damit werden von Hand durchgeführte Updates aller Systeme unnötig. Außerdem lässt sich das Modell einsetzen, um Nutzungsgebühren nach tatsächlicher Beanspruchung zu erheben, z.B. durch einen Application Service Provider. \subsection{Remote Evaluation} Remote Evaluation (REV) ist ein Modell des Software-Designs, bei dem sich die für eine Berechnung erforderlichen Daten und Ressourcen auf einer entfernten Gegenstelle befinden, und die Site, die an dem Ergebnis der Berechnung interessiert ist, die Code-Komponente hat. Diese muss an die entfernte Site geschickt und dort ausgeführt werden, damit das Ergebnis zurück an die Quellsite übermittelt werden kann. Auch dieses Verfahren hat Ähnlichkeiten zu Client-Server, die Datenspeicherung und Verarbeitung läuft zentral ab, und kann eine hohe Belastung des Servers mit sich bringen. Allerdings bietet das Modell dafür flexiblere Möglichkeiten, mit den Daten umzugehen, so dass effizient formulierte Code-Komponenten weniger Last verursachen und die Netzanbindung weniger beanspruchen, da nur die wirklich relevanten Daten zurückgeliefert werden müssen. \subsection{Mobile Agents} Der Begriff \emph{mobile agent} oder \emph{mobiler Agent} ist in unterschiedlichen Forschungsbereichen mit abweichenden Bedeutungen belegt, so wird er z.B. in der KI-Forschung genutzt, um selbständige ,,Intelligenzen'' zu beschreiben. In diesem Dokument ist ein mobiler Agent (MA) eine Code-Komponente zusammen mit eventuellen Daten-Komponenten, die auf eine entfernte Site übertragen und dort ausgeführt werden können, um dort vorhandene Ressourcen zu nutzen und die eigenen Daten zu verändern oder Interaktionen durchzuführen. Dieses Paradigma macht es möglich, einen MA auf einer fremden Site einzusetzen, damit dieser unmittelbar auf Ereignisse auf dieser Site reagieren kann. Der Versender des MA kann dabei seine Site abschalten oder die Verbindung zum Netz trennen, der Agent kehrt dann erst mit den Ergebnissen zurück, wenn die Verbindung wieder aufgebaut wurde. Alternativ kann er aber auch Ereignisse sofort an seinen Urheber signalisieren. \clearpage \section{Mobile Code Systems} \emph{Mobile Code}-Systeme (MCS) sind Sprachen und Umgebungen, die Mechanismen zur Unterstützung von Code-Mobilität anbieten. Solche Systeme müssen Schnittstellen für die oben erwähnten Elemente -- Komponenten, Interaktionen und Sites -- bereitstellen, bzw. diese implementieren. Dazu gehört eine Abstraktion von den Netzwerkprotokollen, die Möglichkeit für den Code, die aktuelle Ausführungsposition zu erfragen oder sogar zu ändern, die Verwaltung von Speicher und Ressourcen, einschliesslich der Möglichkeit, Ressourcen zwischen Komponenten zu teilen. Ausserdem sollte das MCS von der tatsächlich vorhandenen Hardware abstrahieren, damit der mobile Code auf unterschiedlichen Plattformen laufen kann. Man unterscheidet zwischen \emph{schwacher} und \emph{starker Code-Mobilität}: \begin{center} \includegraphics[width=\textwidth]{mobile_code1} \end{center} \begin{itemize} \item \emph{schwache Code-Mobilität} bedeutet, dass nur statische Daten und Code übertragen werden können, und der Code nach der Übertragung ausgeführt wird. Dabei wird unterschieden, ob die Aktion von der versendenden oder von der empfangenden Site initiiert wurde, und ob Code-Fragmente oder selbständige Anwendungen übertragen werden. \item \emph{starke Code-Mobilität} dagegen erlaubt die Migration von laufenden Prozessen. Läuft der Prozess nach seiner Migration auch auf der Quell-Site weiter, so spricht man von \emph{Clonen}. Weiterhin kann eine Migration \emph{proaktiv}, vom Mobile-Code selbst, oder \emph{reaktiv}, also durch Einwirkung von außen, eingeleitet werden. \end{itemize} Die Übertragung von laufendem Code auf ein anderes System erfordert ein ausgeklügeltes Ressourcen-Management, welches Bindungen zwischen dem Code und Ressourcen nach der Migration neu aufbaut oder der Anwendung signalisiert, dass sie ungültig geworden sind. Die Entscheidung kann aufgrund von zwei Kriterien gefällt werden, das erste ist, welche Bindung die Anwendung zur Ressource eingegangen ist: \begin{itemize} \item\emph{über Typ} -- nur die Art der Ressource spielt eine Rolle, das System kann stillschweigend diese Ressource durch eine gleichartige auf dem Zielsystem besser erreichbare ersetzen. Solche Ressourcen können Temporärspeicher oder site-lokale Einstellungen repräsentieren. \item\emph{über Wert} -- der Inhalt der Ressource ist relevant, sie kann bei der Migration auf das Zielsystem kopiert werden. Auf diese Weise lassen sich statische Daten ,,mitnehmen''. \item\emph{über Namen} -- die Ressource ist eindeutig gekennzeichnet, nach der Migration muss -- sofern überhaupt möglich -- genau diese Ressource wieder angesprochen werden können. Über diese Form der Bindung könnte ein Mobile Agent z.B. ein Fenster auf seinem ,,Heimsystem'' geöffnet halten und nach seinen Migrationen Status-Updates in diesem Fenster ausgeben. \end{itemize} Das andere Kriterium beim Wiederaufbau einer Bindung ist die ,,Bewegungsfreiheit'' der Ressource, die von ihrer Art und ihren Eigenschaften abhängt: \begin{itemize} \item\emph{not transferrable} - eine solche Ressource kann ihre Site nicht verlassen, da sie physikalisch daran gebunden ist. Peripheriegeräte wie Drucker oder Monitor sind nicht transferierbar. \item\emph{fixed, transferrable} - diese Ressourcen können zwar auf eine andere Site kopiert, jedoch nicht vom Ausgangssystem gelöscht werden. \item\emph{free, transferrable} - solche Ressourcen lassen sich frei übertragen. \end{itemize} Dem System stehen unterschiedliche Verfahrensweisen zur Verfügung, wie mit einer Ressourcenbindung bei der Migration verfahren werden kann: \begin{itemize} \item\emph{verwerfen} ist die einfachste Art, die Bindung wird einfach für ungültig erklärt. \item als \emph{Netzbindung} wiederherstellen, also die ursprüngliche Ressource für das migrierte Programm transparent weiter bereitstellen. \item\emph{re-binding}, Binden an eine lokale Ressource des gleichen Typs. \item\emph{duplizieren}, Erstellen einer Kopie auf der Zielsite. \item\emph{verschieben}, Duplizieren und Löschung des Originals. \end{itemize} \clearpage Die folgende Tabelle fasst zusammen, welche Verfahrensweisen in Abhängigkeit von Ressource und Art der Bindung verwendet werden können:\\\\ {\centering \begin{tabular}{|l|l|l|l|} \hline &\multicolumn{3}{c|}{Art der Bindung}\\ Ressourcenart&über Typ&über Wert&über Namen\\ \hline not transferrable&re-binding&Netzbindung&Netzbindung\\ &(Netzbindung)&&\\ \hline fixed, transferrable&re-binding&duplizieren &Netzbindung\\ &(duplizieren,&(Netzbindung)&\\ &Netzbindung)&&\\ \hline free, transferrable&re-binding&duplizieren&verschieben\\ &(duplizieren,&(verschieben,&(Netzbindung)\\ &verschieben,&Netzbindung)&\\ &Netzbindung)&&\\ \hline \end{tabular} }\\ Die eben vorgestellten Merkmale werden nicht von allen MCS implementiert, meist schränken die Sprachen die Flexibilität der Res\-sour\-cen-An\-bin\-dung ein. Daher ist der Umfang, in dem obige Eigenschaften in einer Sprache vorhanden sind, ein weiteres Kriterium, an dem die Sprache ausgewählt werden sollte. \clearpage \section{Sicherheit bei Mobile Code} Die Sicherheit ist ein sehr wichtiger Aspekt für Mobile-Code-Umgebungen, da unterschiedliche Code-Komponenten, die auf der selben Site laufen, sich nicht gegenseitig stören dürfen, selbst wenn ein Teil des Codes aus nicht zuverlässigen Quellen stammt. Man unterscheidet zwei wichtige Aspekte der Sicherheit: Unter \emph{safety} versteht man die Sicherheit vor Fehlern im Code oder in der Umgebung. Safety sollte auf Betriebssystemebene, in der Programmiersprache, im dazugehörigen Binärcode, und zur Laufzeit sichergestellt werden. Dagegen wird unter \emph{security} die Sicherheit gegenüber Angriffen verstanden. Security erfordert ein funktionierendes Safety-Konzept, da bei einem Angriff sonst Lücken im System ausgenutzt werden können, geht aber noch weiter, da man auch übermäßige Ressourcen-Nutzung und andere Attacken ausschliessen muss. Nach \cite{rusgan} wird security in vier Ziele unterteilt, die ein MCS einhalten muss: \begin{itemize} \item\emph{Vertraulichkeit} - Schutz vor dem Ausspionieren von Daten \item\emph{Integrität} - Schutz vor Veränderung \item\emph{Verfügbarkeit} - Sicherstellung des Betriebs \item\emph{Authentizität} - Echtheit der Daten und des Urhebers \end{itemize} Die Sicherheit hängt von allen Schichten eines Systems ab, sie ist eine Art Kette, die ein Angreifer an der schwächsten Stelle aufbrechen kann. Daher muss sie auf jeder Ebene beachtet werden. Auf der \emph{Kommunikationsebene} bei vernetzten Systemen kann, um safety zu gewährleisten, ein gegenüber Fehlern robustes Protokoll eingesetzt werden. Security spielt eine Rolle, wenn Datenverbindungen über nicht vertrauenswürdige Sites gehen, wo Abhören oder Manipulation möglich ist. Durch Verwendung kryptographischer Verfahren zur Authentifizierung der Gegenstellen und zur Verschlüsselung der Daten (z.B. IPSec oder SSL), kann soetwas ausgeschlossen werden. Es ist jedoch nicht möglich, Verfügbarkeit zu garantieren, wenn man nicht alle Sites unter Kontrolle hat. Das \emph{Betriebssystem} muss auch einen wesentlichen Beitrag zur Sicherheit leisten. Durch die Verwendung (und Verwaltung) von Hard\-wa\-re-Spei\-cher\-schutz können einzelne Prozesse voneinander isoliert werden, so dass sie nur über die Betriebssystem-Schnittstellen miteinander kommunizieren können und gegenseitige Störungen nicht möglich sind. Die Schnittstellen sind allerdings vom verwendeten Betriebssystem abhängig, was plattformübergreifende Entwicklung erschwert. Ausserdem ist Hardware-Speicherschutz auf vielen portablen Geräten wie Mobiltelefonen und PDAs, die ein wichtiges Ziel von Mobile-Code-Anwendungen sind, nicht vorhanden. In diesem Fall kann eine \emph{abstrakte Maschine} eingesetzt werden, die den unsicheren Code interpretiert, unzulässige Zugriffe abfängt, und damit einen Speicherschutz in Software bietet. Eine solche Maschine bietet weiterhin eine einheitliche Schnittstelle für Programme, die nicht von der verwendeten Plattform oder Architektur abhängig ist, und damit gute Voraussetzungen für Mobile Code bietet. Sie benötigt aber einen Zwischencode, der von ihr interpretiert wird, was mit deutlich höherem Aufwand verbunden ist, als direkte Ausführung durch die CPU. Die Sicherheit kann auch auf Ebene der \emph{Programmiersprache} verbessert werden. Dazu muss die Sprache unsichere Elemente wie Zeigerarithmetik und Speichermanagement aus den Händen des Programmierers nehmen, und weitere Überprüfungen wie z.B. von Array-Grenzen vorsehen. Wenn die Sicherheitsüberprüfung nur zur Compile-Zeit stattfindet, darf der erzeugte Binärcode durch spätere Manipulationen nicht für andere Anwendungen gefährlich werden. Ausserdem sollten Sprachkonstrukte mit Zugriff zur lokalen Site nicht uneingeschränkt nutzbar sein, und die Verwendung von Ressourcen sollte sich durch die Site begrenzen lassen. Diese Sicherheitskriterien, die für die Ausführung fremden Codes besonders wichtig sind, sind ein weiteres Kriterium zur Auswahl der richtigen Programmiersprache, und der dazugehörigen Laufzeitumgebung. \clearpage \section{Programmiersprachen} Dieses Kapitel wendet die oben dargestellten Klassifizierungsverfahren für Mobile-Code-Systeme beispielhaft auf drei Programmiersprachen an, besonders wird auf die Sicherheit der Sprachen eingegangen. Weitere Sprachen lassen sich nach dem selben Muster untersuchen und einordnen. \subsection{JAVA} JAVA\cite{java} ist eine von Sun entwickelte objektorientierte Sprache. Die primären Ziele bei der Entwicklung waren ein klares Objektmodell, eine für viele Entwickler verständliche C-ähnliche Syntax und Plattformunabhängigkeit, die durch die Verwendung von binärem Zwischencode (Bytecode) sichergestellt wurde. Der Bytecode einer JAVA-Anwendung wird durch die JVM (Java Virtual Machine) interpretiert, die gleichzeitig eine Abkapselung von der ausführenden Site darstellt, also eine Sandbox. Es existieren JVMs für zahlreiche Plattformen, auch für mobile Geräte wie Handys oder PDAs. Das Objektmodell von JAVA ist klassenbasiert, und die Standardumgebung bringt viele Klassen für Arbeit mit Ressourcen und für Benutzer-Interaktionen mit. Weitere Klassen können zur Laufzeit automatisch oder explizit vom laufenden Code angefordert werden. Sie werden dann durch den \emph{class loader}, der Teil jeder JVM ist, nachgeladen. Die Bekanntheit von JAVA ist auf die leichte Integration in Webseiten zurückzuführen. Dabei werden JAVA-Applets in ein HTML-Dokument eingebettet, der dafür notwendige Code wird vom Webserver geladen und lokal in der Browser-JVM gestartet. Dies ist eine Form schwacher Code-Mobilität, bei der Code-Fragmente empfangen und ausgeführt werden. Dadurch, dass dabei keine Bindungen zu dem den Code beherbergenden Server erhalten bleiben, entfällt die Notwendigkeit einer komplexen verteilten Ressourcen-Verwaltung. Es existiert jedoch mit der JAVA Aglets API\cite{jaapi} eine von IBM entwickelte Erweiterung, die proaktive Code-Migration und Ressourcenübertragung durch duplizieren erlaubt, sich aber auch nur auf schwache Mobilität beschränkt. Zum Safetykonzept von JAVA gehört, dass auf unsichere Elemente in der Sprache weitgehend verzichtet wurde. Es gibt keine Zeigeroperationen und unsichere Typumwandlungen, unions und der von C bekannte Präprozessor wurden ebenfalls nicht implementiert. Das Speichermanagement wurde dem Programmierer komplett aus der Hand genommen und Zugriffe auf Felder und Strings müssen immer von der JVM auf ihre Zulässigkeit überprüft werden. Fehlerzustände werden durch Exceptions behandelt, die den Code-Ablauf im Fehlerfall unterbrechen und an dem entsprechenden Exception Handler fortsetzen -- das erleichtert dem Programmierer den Umgang mit Laufzeitproblemen, und schützt gleichzeitig davor, dass in unvorhergesehenen Fehlersituationen Code ausgeführt wird, der das Problem nicht berücksichtigt. Zugriffe auf Ressourcen der lokalen Site dürfen nur durch bestimmte Klassen vorgenommen werden, die zur Laufzeitumgebung gehören und nicht ableitbar sind, und damit weder erweitert noch manipuliert werden können. Die Rechte, die diesen Klassen zustehen, werden vom \emph{SecurityManager} kontrolliert, der vom Benutzer konfiguriert werden kann. Obwohl JAVAs Sicherheitskonzept vielversprechend ist, und von der virtuellen Maschine bis zum Sprachdesign greift, ist es hauptsächlich auf die Ausführung von Applets ausgerichtet und macht deshalb Unterschiede zwischen über das Netz und von Festplatte geladenen Klassen. Außerdem sieht es einige Dinge, wie die Beschränkung des Arbeitsspeichers oder der Prozessorzeit nicht zu. % FIXME! \clearpage \subsection{Telescript} Die Sprache Telescript\cite{telescript} wurde 1996 von General Magic mit dem Ziel entwickelt, virtuelle Marktplätze realisieren zu können. Sie ist wie JAVA klassenbasiert und objektorientiert, ihr Schwerpunkt liegt jedoch auf Kommunikation. Die Sprache setzt starke proaktive Code Mobility um, und verwendet dafür eine portable Zwischensprache namens \emph{Low Telescript}. Objekte in dieser Zwischensprache (\emph{agents}) können zwischen Sites (die sich jeweils aus einer \emph{Engine} und ineinander verschachtelbaren \emph{Places} zusammensetzen) bewegt werden. Dafür gibt es die Befehle \emph{go} und \emph{send}, mit denen ein Agent proaktiv auf ein anderes Place migrieren oder sich dorthin klonen kann. Dabei werden die von dem Agenten benutzten Ressourcen zusammen mit ihm migriert, und die Bindungen auf der lokalen Site verworfen. Das auf Metaphern der realen Welt basierte Konzept wird auch bei der Abrechnung der Ressourcennutzung durchgesetzt: jede Ressource und jeder Agent haben einen Besitzer, der die Kosten der Benutzung zu tragen hat. Damit ein Agent auf ein anderes Place migrieren kann, benötigt er zuvor ein \emph{Ticket}, in dem das Ziel und eventuell die Route spezifiziert sind. Ein Place kann entscheiden, ob es einen ankommenden Agenten akzeptiert oder ablehnt. Im positiven Fall setzen sich die dem Prozess erlaubten Aktionen aus dem Mengen-Durchschnitt der \emph{Permit}s der engine, aller verschachtelten Places und von dem Agenten selbst. Diese regeln seine maximale Verweilzeit und Speicheraufnahme, aber auch ob der Agent weiterwandern, Unterprozesse erstellen und die Permits anderer Prozesse beeinflußen darf. Damit auch andere Einflüsse ausgeschlossen werden, läuft jeder Prozess in einem eigenen Kontext in der engine, so dass alle Aktionen zwischen unterschiedlichen Prozessen nur über eine einheitliche Schnittstelle der engine stattfinden. Zusätzlich stellt die engine sicher, dass Objekte durch einen Absturz oder Neustart nicht gefährdet werden. Das Sicherheitskonzept von Telescript ist von Anfang an in das Sprachdesign eingearbeitet worden. Es beachtet sowohl safety als auch security - ein Bug in einem Objekt kann keine anderen Objekte beeinflussen, und Angriffe auf fremde Objekte oder die Systemressourcen sind durch die einheitliche Kommunikationsschnittstelle und durch die Ressourcenbegrenzung kaum möglich. Allerdings ist ein solches Sicherheitskonzept für eine Sprache, deren Entwicklungsziel die Darstellung von Marktplätzen ist, in denen mit realem Geld umgegangen wird, auch zwingend notwendig. \clearpage \subsection{Safe-TCL} Im Gegensatz zu den oben vorgestellten Sprachen ist Safe-TCL\cite{stcl} eine (prozedurale) Scriptsprache, d.h. es existiert weder ein Zwischencode noch eine Binärform. Safe-TCL wurde als MIME-Erweiterung vorgesehen, um E-Mails mit aktiven Inhalten versehen zu können, und stellt eine Abwandlung von TCL mit eingeschränktem Funktionsumfang dar. Da die Verbreitung von Safe-TCL-Code mit E-Mails stattfindet, existieren in der Sprache keine Elemente zur Steuerung der Code-Mobilität. Es ist lediglich über die zusätzlichen MIME-Angaben möglich, zu bestimmen, ob das Script beim Versenden, beim Empfangen oder beim Ansehen der E-Mail ausgeführt werden soll. Bei der alternativen Verbreitungsform über Webseiten, wo die Interpretation im Browser stattfindet, fallen diese drei Phasen zusammen. Die Syntax von Safe-TCL entspricht der von TCL, entsprechend existieren auch keine Zeiger mit unsicheren Operationen, und der einzige vorhandene Datentyp ist String. Numerische Operationen sind mit einer Konvertierung zu Zahlen und wieder zurück zu Strings verbunden, und auch Programmcode wird mit Strings repräsentiert. Das macht die Variablenverwaltung einfacher und unanfälliger gegen Fehler, erhöht aber immens die Verarbeitungszeit. Variablen können dabei immer entweder global oder in der aktuellen Funktion lokal sein. Der Funktionsumfang von TCL wurde für Safe-TCL angepasst, um nicht vertrauenswürdigen Code ausführen zu können. Dabei wurden alle Funktionen von TCL auf ihre Eignung überprüft und entweder eliminiert oder durch weniger generische ersetzt. So gibt es statt vollem Dateizugriff nur einen Mechanismus um Konfigurationsdaten zu schreiben und zu lesen, der ähnliche Funktion wie die Cookie-Speicherung in Webbrowsern bietet. Um eine Abgrenzung zwischen Safe- und vollständigem TCL zu gewährleisten, existieren für beide Varianten eigene Interpreter, wobei der Safe-TCL-Interpreter nur sichere Funktionen implementiert. Dadurch ist dieser kompakt und lässt sich leichter in eigene Systeme einbinden. \clearpage \section{Zusammenfassung} Zuerst hat diese Arbeit dargelegt, dass Code-Mobilität durch die fortschreitende Entwicklung digitaler Netzwerke eine Daseinsberechtigung hat und eine höhere Aufmerksamkeit seitens der Wissenschaft verdient. Dann wurden Methoden vorgestellt, nach denen sich Paradigmen für Mobile Code unterteilen lassen, und wie man ihre Eignung für die eigene Problemstellung einschätzen kann. Als typische Paradigmen wurden ,,Client-Server'', ,,Remote Evaluation'', ,,Code on Demand'' und ,,Mobile Agents'' vorgestellt. Der nächste Abschnitt befasste sich mit Gliederungsmöglichkeiten für Mobile Code Systeme, also den Code-Mobilität unterstützenden Sprachen und ihren Umgebungen. Da wurden die Migrationsmöglichkeiten von Code und die dabei in Frage kommenden Verfahren zum Ressourcenmanagement untersucht. Im vierten Kapitel wurden die bei Mobile Code besonders wichtigen Sicherheitsaspekte untersucht. Es erfolgte eine Unterteilung in die vier Schichten Kommunikation, Betriebssystem/Hardware, abstrakte Maschine und\linebreak[4] Programmiersprache, für die jeweils auf safety und security, also Sicherheit vor Fehlern und vor bewußten Angriffen, eingegangen wurde. Im letzten Abschnitt wurden dann die zuvor gezeigten Verfahren der Klassifizierung auf die als Beispiel ausgewählten Programmiersprachen JAVA, Telescript und Safe-TCL angewandt. Dabei wurden die unterstützten Migrationsformen von Code und Daten, aber auch die Aspekte der Sicherheit auf den unterschiedlichen Schichten betrachtet. \vline Wenn man die beste Umgebung zur Implementierung einer Problemlösung sucht, sollte man sich zunächst für das sinnvollste Paradigma zur Umsetzung entscheiden. Diese Entscheidung kann erleichtert werden, wenn man die Lösung nach unterschiedlichen Paradigmen modelliert und die anfallenden Interaktionskosten betrachtet. Daraufhin sollte man aus den möglichen Mobile Code Systemen das auswählen, welches das passende Paradigma am besten umsetzt. Dabei gilt zu beachten, dass man nicht zwingend auf eine vollständig vorhandene Implementierung aller Möglichkeiten angewiesen ist, sondern diese in einem gewissen Rahmen auch selbständig nachgerüstet werden können. Dafür sollten dann aber Betrachtungen der gebotenen und der erforderlichen Sicherheit in die Entscheidung einfließen. Die letztendliche Implementierung kann durch eine geschickte Auswahl von Paradigma und Umgebung erleichtert werden, ganz entfallen wird sie aber nicht. \begin{thebibliography}{8} \addcontentsline{toc}{section}{\refname} \bibitem{ucm}A. Fugetta, G.P. Picco, G. Vigna,,Understandig Code Mobility'', IEEE Transactions On Software Engineering, Vol. 24, No. 5, May 1998. \bibitem{plmc}T. Thorn, ,,Programming Languages for Mobile Code'', ACM Computing Surveys, Vol. 29, No. 3, Sep 1997. \bibitem{rusgan}D. Russell, G.T. Gangemi Sr., ,,Computer Security Basics'', 1991, O'Reilly \& Associates Inc., Sebastopol, CA. \bibitem{java}Sun Microsystems, ,,The Java Language: An Overview'', Technical Report, 1994, Sun Microsystems. \bibitem{jaapi}\url{http://www.trl.ibm.com/aglets/} \bibitem{telescript}J.E. White, ,,Telescript Technology: Mobile Agents'', Software Agents, J. Bradshaw, ed. AAAI Press/MIT Press, 1996. \bibitem{stcl}N. Borenstein, ,,EMail with A Mind of Its Own: The Safe-Tcl Language for Enabled Mail'', technical report, First Virtual Holdings, Inc. 1994. \end{thebibliography} \end{document}