% ****************************************************************************
\chapter{Einleitung}
\label{sec:Einleitung}

\enlargethispage{.5cm}

\sidenote{{\uc}} Informationstechnologie hält zunehmend Einzug in den menschlichen Alltag. Dieser Trend wird in der Fachwelt \emph{{\uc}}\footnote{Ubiquitous (engl.): allgegenwärtig. Oft wird auch das industriell geprägte Synonym \emph{Pervasive Computing} verwendet, von pervasive (engl): durchdringend.} genannt. Geprägt wurde der Begriff von Mark Weiser in seinem Aufsatz "`The Computer of the 21st Century"' \cite{we91_computer}. Auslöser des Trends sind die großen Fortschritte der Informationstechnik in den vergangenen Jahren: Nach dem \emph{Mooreschen Gesetz} verdoppelt sich die Leistungsfähigkeit integrierter Schaltungen alle zwei Jahre. Damit werden informationstechnische Geräte immer kleiner und preiswerter. Zusätzlich nehmen die Kommunikationsfähigkeiten von Geräten permanent zu, wodurch vormals voneinander isolierte Geräte in verteilten Systemen aufgehen. Eine wesentliche Eigenschaft von {\uc}-Systemen ist, dass die Informationstechnologie für den Menschen unsichtbar wird.

\sidenote{Typische Szenarien} Typische {\uc}-Szenarien spielen im intelligenten Heim, im intelligenten Büro oder auch in zunehmendem Maße in industriellen Umgebungen. Dabei werden untereinander vernetzte, intelligente Geräte verwendet, um den Menschen in seiner häuslichen Umgebung oder bei seiner Arbeit zu unterstützen oder Arbeitsabläufe dynamischer und flexibler zu gestalten. Anwendungsfälle erstrecken sich von der Umsetzung reiner Komfortfunktionen wie automatische Beleuchtungssteuerungen oder der Steuerung von Multimedia-Geräten über ökonomisch relevante Funktionen wie die intelligente Regelung von Klimasystemen.

\sidenote{Sensoren und Aktuatoren} Die Kopplung von physikalischer und informationsstrukturierter Umgebung wird durch \emph{Sensoren} und \emph{Aktuatoren} erreicht. Sensoren werden verwendet, um den Zustand der physikalischen Umgebung zu ermitteln und an die informationsverarbeitenden Komponenten weiterzuleiten. Einfache Beispiele für Sensoren aus dem Bereich des intelligenten Heims sind die Messung der Raumtemperatur, Helligkeit oder Luftfeuchtigkeit. Darüber hinaus sind komplexere Sensoren wie Präsenzmelder oder auch Sensoren zur Lokalisierung von Menschen und Gegenständen zu nennen. Aktuatoren (Stellglieder) haben die umgekehrte Funktion von Sensoren: Sie werden von den informationsverarbeitenden Komponenten angesprochen, um Einfluss auf die physikalische Umgebung zu nehmen. Einfache Beispiele für Aktuatoren sind Fenster- und Türöffner, Heizungsregulatoren oder Beleuchtungssteuerungen.

%\sidenote{Komplexität, Heterogenität und Dynamik} Aufgrund der engen Verzahnung von physikalischer und informationsstrukturierter Umgebung sind {\uc}-Systeme in der Regel komplex. Daneben zählen Heterogenität und Dynamik zu den typischen Eigenschaften. Die Heterogenität rührt daher, dass viele unterschiedliche Arten von Geräten verwendet werden, die nicht notwendiger Weise von einem einzelnen Hersteller stammen und damit über unterschiedliche Schnittstellen verfügen. Dynamisch sind die Umgebungen, weil sie mitunter mobile Geräte enthalten, die dem System zu beliebiger Zeit beitreten und auch wieder aus ihm entfernt werden können.

\sidenote{Komplexität, Heterogenität und Dynamik} Aufgrund der engen Verzahnung von physikalischer und informationsstrukturierter Umgebung sind {\uc}-Systeme in der Regel komplex. Daneben zählen Heterogenität und Dynamik zu den typischen Eigenschaften. Die Heterogenität rührt von der Verwendung unterschiedlicher Arten von Geräten, deren Schnittstellen mitunter verschiedenen Standards entsprechen oder gar proprietär sind. Dynamisch sind die Umgebungen, weil sie mitunter mobile Geräte enthalten, die dem System zu beliebiger Zeit beitreten und auch wieder aus ihm entfernt werden können.

\sidenote{Middle\-ware und SOA} Die genannten Eigenschaften der Systeme können mit klassischen "`starren"' Netzwerkstrukturen quasi nicht beherrscht werden. Ein aus dem Umfeld verteilter Systeme bekanntes Hilfsmittel, um mit diesen Eigenschaften umzugehen, ist die \emph{Middleware}. Middleware ist eine Adaptionsschicht, die Komplexität, Heterogenität und Dynamik der Systeme beherrscht und für die Anwendungen transparent macht \cite{em00_middleware}. Damit ist die Middleware das Schlüsselelement für den Aufbau \emph{Service-orientierter Architekturen (SOA)} \cite{bi05_soa, fu04_soa}. Eine zunehmend in den Vordergrund rückende Spielart von SOA sind \emph{Device-level SOA} \cite{ja05_sirena, ba07_soa}. Hierbei werden SOA im Sinne des {\uc} durch alltägliche Geräte gebildet. In einer Device-level SOA bieten Geräte Dienste an und können die Dienste anderer Geräte nutzen. Dabei bleibt die eigentliche Abwicklung der Kommunikation für die Anwendungen transparent. Ferner können sich Geräte für \emph{Ereignisbenachrichtigungen (Events)} bei anderen Geräten registrieren. Über \emph{Discovery-Verfahren} können Geräte und ihre Dienste automatisch im Netzwerk gefunden werden. Die sich aus dem Einsatz von SOA ergebenden Vorteile sind ein geringerer Implementierungsaufwand, erhöhte Robustheit der Systeme sowie erleichterte Wartbarkeit der Systeme im Vergleich zu klassischen Systemstrukturen \cite{ba07_soa}.

\minisec{Middleware-Unterstützung limitierter Geräte}

\enlargethispage{.5cm}

\sidenote{Middleware-Unterstützung von Sensoren} Aufgrund der Vorteile von SOAs bietet es sich an, auch sehr kleine Geräte wie zum Beispiel Sensoren mit einer Middleware-Unterstützung auszustatten und in SOAs aufzunehmen. Dies stellt nach dem heutigen Stand der Technik kein Problem dar, solange der Preis der Geräte keine Rolle spielt. Wird vorausgesetzt, dass kleine Geräte möglichst preiswert sein müssen, so ist anzunehmen, dass sie nur über entsprechend geringe Ressourcen wie Rechenleistung, Arbeitsspeicher, Kommunikationsbandbreite und Energie verfügen. Leider stellen typische Middleware-Systeme relativ hohe Anforderungen an kleine Geräte. So setzen viele Systeme wie zum Beispiel \emph{Universal Plug and Play (UPnP)}\footnote{http://www.upnp.org} die Fähigkeit voraus, XML-Nachrichten parsen beziehungsweise dynamisch erzeugen zu können oder, wie im Falle der \emph{Jini-Technologie}\footnote{http://www.sun.com/jini}, eine \emph{Java Virtual Machine (JVM)} auszuführen. Aufgrund dieser Diskrepanz sind viele Anwendungsfälle denkbar (wie bei Verwendung kleiner, batteriebetriebener Sensoren...), in denen kein geeigneter Kompromiss zwischen Leistung und Preis von kleinen Geräten gefunden werden kann, beziehungsweise in denen bei einem festgelegten Preis die Leistungsfähigkeit der Geräte nicht ausreicht, die Anforderungen einer Middleware zu erfüllen.

\sidenote{Erwartete zukünftige Entwicklung} Wie eingangs erwähnt steigt nach dem Mooreschen Gesetz die Leistungsfähigkeit von Geräten bei gleich bleibendem Preis stetig an. Daher ist durchaus zu erwarten, dass die Leistungsprobleme, die heute für eine bestimmte Klasse von Geräten gelten, in Zukunft obsolet werden. Es gibt allerdings zwei weitere Faktoren, die bei dieser Fragestellung berücksichtigt werden müssen: Zum einen kann erwartet werden, dass nicht nur die Leistungsfähigkeit von kleinen Geräten steigt, sondern auch die Ansprüche steigen, die an die Geräte gestellt werden. Zum anderen ist die Leistungsfähigkeit, die von einem Gerät erwartet werden kann, nicht nur eine Frage des Preises, sondern wird auch von der Größe (das heißt von den physikalischen Abmessungen) des Gerätes beeinflusst. Aufgrund dieser Überlegungen muss angenommen werden, dass es stets Situationen gibt, in denen Anforderungen an kleine Geräte gestellt werden, die sie nicht auf eigenständige Weise erfüllen können.

\minisec{Nutzung akkumulierter Ressourcen}

\sidenote{Klassifizierung von Geräten} Geräte in {\uc}-Umgebungen lassen sich in zwei Klassen einteilen, wie in Abbildung~\ref{fig:Geräteklassifizierung} dargestellt. Die erste Klasse (Innenbereich der Darstellung) enthält Geräte, die bezüglich ihrer Ressourcen als unbeschränkt eingestuft werden können, da sie über entsprechend große Mengen an Rechenleistung, Arbeits- und Festspeicher, Bandbreite sowie Energie verfügen. Die zweite Klasse (äußerer Ring) enthält kleine, leistungsarme Geräte, die zwar über Kommunikationsschnittstellen verfügen, jedoch aus Gründen ihrer geringen Leistungsfähigkeit keinen von Geräten der ersten Klasse angewendeten Middleware-Standard unterstützen.

\begin{figure}[htbp]
  \begin{center}
    \vspace{1cm}
    \includegraphics[width=10cm,angle=0]{fig/Geräteklassifizierung.png}
    \setzeBreite
    \caption[Geräteklassen in {\uc}-Umgebungen.]{Geräteklassen in {\uc}-Umgebungen (Klasse~1: innerer Kreis, Klasse~2: äußerer Ring).}
    \label{fig:Geräteklassifizierung}
  \end{center}
\end{figure}

\sidenote{\dproxies} Der Ansatz, der im Rahmen der vorliegenden Arbeit verfolgt wurde, um das Problem des möglichen Missverhältnisses zwischen erforderlicher und verfügbarer Geräteleistung zwischen den zwei genannten Geräteklassen zu lösen beziehungsweise zu umgehen ist, die kleinen Geräte zu befähigen, akkumulierte Ressourcen im verteilten System für ihre Zwecke zu nutzen. So kann zum Beispiel die Rechenleistung oder der Arbeitsspeicher anderer Geräte, die in {\uc}-Umgebungen ohnehin vorhanden sind, genutzt werden, um ein limitiertes Gerät bei der Erfüllung seiner Aufgaben zu entlasten. Hierzu wurde das Konzept der \emph{\dproxies} angewendet.

\sidenote{System-inhärente Nachteile} Die Vorteile, die sich durch Anwendung des Proxy-Konzeptes ergeben, werden durch eine aufwendige Lebenszyklusverwaltung sowie einen hohen Entwicklungsaufwand der Proxies erkauft. Außerdem wird durch die Anwendung des Proxy-Konzep\-tes die Robustheit der Dienste im Vergleich zu Standalone-Geräten reduziert. Das liegt daran, dass Gerät und Proxy ein Seriensystem bilden. Der Dienst des Gerätes fällt nicht nur aus, wenn das Gerät selbst ausfällt, sondern auch, wenn der Proxy des Gerätes ausfällt.

\minisec{Sindrion}

\vspace{-.75ex} %\piccaption{Sindrion-Logo.\label{fig:Sindrion-Logo}}
\parpic(2.4cm,0cm)[r]{\includegraphics[width=2.25cm]{fig/Sindrion-Logo.png}} \noindent Eine Java-basierte Implementierung des im Rahmen dieser Arbeit entwickelten Systems liegt unter dem Namen \emph{Sindrion Application Manager} vor und ist im Auftrag und mit Unterstützung von Infineon Technologies entstanden \cite{bi04_sindrion, gs04_sindrion}. Das Sindrion-System bindet batteriebetriebene, kabellose Sensoren (sog. \emph{\strans}, siehe Anhang \ref{sec:Anhang_Sindrion_Transceiver}) über Proxies in UPnP-Netzwerke ein. Der Sindrion {\am} sorgt dabei für die Lebenszyklusverwaltung der Proxies bzw. den Bezug des Proxy-Codes. Ferner spezifiziert Sindrion als Erweiterung zum UPnP-Standard Geräte, die ihre eigenen Steuerapplikationen in Form von UPnP-basierten \emph{Specific {\cp}s (SCPs)} oder Java-basierten \emph{Sindrion-Applets} bereit stellen. Sindrion wird heute im Rahmen verschiedener Projekte wie {\zb} den EU-Projekten \emph{Promise}\footnote{http://www.pabadis-promise.org} oder \emph{CoBIs}\footnote{http://www.cobis-online.de} eingesetzt.

% ----------------------------------------------------------------------------
\section{Einordnung in das thematische Umfeld}
\label{sec:Thematisches_Umfeld}

%Ein wichtiger Aspekt bei der Entwicklung dieser Komponenten ist \emph{Hardware-Software-Codesign} \cite{le03_embedded}.

\sidenote{{\uc} und SOA} Die vorliegende Arbeit reiht sich in das Umfeld des \emph{Ubiquitous Computing} \cite{we91_computer, bo00_embedded} ein. Die kleinsten Komponenten dieser Systeme sind {\og} Sensoren bzw. Aktuatoren, aus denen \emph{Sensornetzwerke} aufgebaut werden \cite{co01_sensor, sa02_sensor}. Besondere Anforderungen an Ubiquitous Computing Umgebungen \cite{ed01_challenges, sa01_challanges} wie der Umgang mit Dynamik und Heterogenität werden mit dem Einsatz von \emph{Middlewaresystemen} \cite{em00_middleware, mu02_invisible} adressiert. Mit Hilfe von Middleware werden \emph{Service-Oriented Architectures (SOA)} aufgebaut \cite{ba07_soa}.  Wird, wie im Rahmen der vorliegenden Arbeit eine SOA aus relativ kleinen Geräten aufgebaut, so spricht man von \emph{Device-Level SOA} \cite{ja05_sirena}.

%SOA ist die Umsetzung einer an die klassische Objektorientierung angelehnte Design-Philosophie nach der Geräte in verteilten Systemen sich ausschließlich durch die Dienste auszeichnen, die sie anderen Geräten anbieten. Dadurch wird eine strikte Kapselung von Funktionalität erreicht, womit die Komplexität heutiger verteilter Systeme handhabbar wird \cite{ba07_soa}.

\sidenote{Kommunikations\-infrastrukturen} Relevante Arbeiten und Projekte lassen sich grob in die folgenden Bereiche eingliedern: Der erste Bereich umfasst Kommunikationsinfrastrukturen bzw. Middlewareprotokolle. Verbreitete Middlewareprotokolle sind \emph{Jini} \cite{gu02_jini}, \emph{JXTA} \cite{ne02_edutella}, \emph{CORBA} \cite{vi97_corba} und \emph{UPnP} \cite{mi01_upnp, so02_upnp, so05_ants}. Ansätze wie \emph{Salutation} (bzw. \emph{HP JetSend}) \cite{be00_comparison} haben heute praktisch keine Bedeutung mehr. Allgemein ist ein Trend hin zu einer Anlehnung von Middlewareprotokollen an Internet-Technologien zu beobachten. Dieser Trend wird bereits durch UPnP verfolgt und durch Technologien wie \emph{DPWS}\footnote{Device Profile for Web Services} \cite{ja05_sirena} fortgesetzt.

\sidenote{Adapter} Der zweite Bereich umfasst \emph{Geräte-} bzw. \emph{Protokolladapter}. Häufig werden \emph{Gateways} eingesetzt, um unterschiedliche (Middleware-)Protokolle aufeinander abzubilden \cite{al03_upnp, ri03_eib, we01_eib, sc06_eiblue}. Viele Ansätze sind speziell darauf ausgelegt, ressourcenarme Geräte in Middleware-basierte Umgebungen zu integrieren \cite{le01_jini, br02_ninja, hu02_jini, la02_jini, surrogate_spec, sc04_gateway, bi04_sindrion, gs04_sindrion, ba06_sindrion}. Oft wird auch \emph{Codegenerierung} eingesetzt, um Code an bestimmte Plattformeigenschaften oder Anwendungsfälle anzupassen \cite{lo97_corba, ma00_code, ch04_javassist, ce05_mobcon, my02_mobile, tr02_personalizing, ho99_mobile}. Viele verwandte Arbeiten verwenden Proxies, um limitierte Geräte in verteilten Systemen zu vertreten \cite{ma99_mobile, ro02_composable, ho99_mobile}. Die limitierten Geräte sind allerdings oft ausschließlich Clients, die über einen Proxy in die Lage versetzt werden, einen bestimmten Dienst in Anspruch zu nehmen. Das in dieser Arbeit angewendete Proxy-Konzept kommt auch in ähnlicher Form in der \emph{Jini Surrogate Architecture} \cite{surrogate_spec} zum Einsatz. Im Bereich von Sensornetzwerken sind Arbeiten entstanden, die in die vorliegende Arbeit eingeflossen sind \cite{sc04_gateway}.

\sidenote{Verwaltungs\-strukturen} Der dritte Bereich umfasst Verwaltungsstrukturen (Frameworks), die eine komponentenbasierte Verwaltung verteilter Systeme erlauben. Ein verbreiteter Standard ist hier \emph{OSGi} \cite{osgi03_spec, go01_gateways, ma01_osgi, ho02_home} -- teils mit kommerziellen Implementierungen \cite{va02_gateway}. Viele aktuelle Projekte sind im Bereich \emph{kontextsensitiver Systeme} \cite{gu04_osgi, ch03_ontology} oder im Bereich \emph{Location-Awareness} \cite{he03_elderly} angesiedelt. Andere Ansätze wie das Web-basierte \emph{CoolTown} (HP) \cite{ki01_nomadic} oder \emph{Gaia} (nutzt CORBA) \cite{ce01_gaia, ra03_gaia} basieren nicht auf OSGi, sondern auf proprietären Architekturen. Viele Systeme sind speziell auf das Umfeld des intelligenten Heims wie im Falle von \emph{Easy Living} \cite{br00_living} oder des intelligenten Konferenzraumes (ICrafter \cite{sh01_icrafter}) ausgelegt.

\sidenote{Monitoring} Der Status einzelner Systemkomponenten wird durch \emph{Monitoring-Verfahren} ermittelt. Hier kommt erschwerend hinzu, dass die genutzten Systeme oft auf \emph{Managed Code} wie \emph{Java} oder \emph{.Net} basieren und daher zum Teil besondere Verfahren zur Ermittlung des Zustandes erfordern \cite{to02_observation}. Häufig spielen auch Echtzeitanforderungen eine wichtige Rolle. Die Erfüllung dieser Anforderungen wird allerdings wie schon im Umfeld des Monitoring durch die auf Managed Code basierenden Softwareumgebungen erschwert \cite{bo00_realtime}. Systeme im hier betrachteten Umfeld sind daher i. d. R. nicht in vollem Umfang echtzeitfähig, sondern binden allenfalls echtzeitfähige Sub-Komponenten ein \cite{su01_osgi}. Einige Projekte adressieren allerdings die Integration von Echtzeitfähigkeit in Middlewarearchitekturen \cite{li93_qos}.

\enlargethispage{-.5cm}

\sidenote{Mobile Agenten} Ferner wird in vielen Systemen das Modell von \emph{mobilen Agenten} angewendet, um Anforderungen wie Dynamik und Heterogenität zu entsprechen \cite{go01_ubiquitous, ba00_active, ba03_agent}. Neben der Migration einzelner Komponenten oder Applikationen ist auch eine Migration virtueller Maschinen denkbar \cite{cl05_migration}. Beispiele sind \emph{Java Party} \cite{ph97_party} und \emph{Mole} \cite{st97_mole}. Ein spezieller Fall mobiler Applikationen sind \emph{Follow-Me Applications} \cite{st98_follow, ka01_follow, ma99_mobile, ro02_middleware, ro02_mobility}, die einem Benutzer durch ein System folgen.

\sidenote{Bezug zur vorliegenden Arbeit} Das im Rahmen der vorliegenden Arbeit vorgestellte System verbindet die Bereiche der Sensornetzwerke mit dem Bereich der Middleware-basierten Device-Level SOA. Um diese Bereiche zu verbinden, wird das {\og} Konzept der Geräte- {\bzw} Protokolladapter angewendet. Verwaltungsstrukturen sowie Monitoring-Verfahren werden eingesetzt, um die Vorgänge im System regeln zu können. Das Konzept der Mobilen Agenten ist schließlich für die im Rahmen der vorliegenden Arbeit eingesetzte \emph{Migration} von Proxies relevant, die als Mittel der Vorbeugung von Störungen dient. Fehlertoleranzverfahren \cite{ja98_fault_tolerance} kommen schließlich zum Einsatz, um mit Ausfällen angemessen umgehen zu können.

% ----------------------------------------------------------------------------
\section{Struktur der vorliegenden Arbeit}

Die Struktur der vorliegenden Arbeit orientiert sich an der Vorgehensweise der Entwicklung, wie in Abbildung \ref{fig:Vorgehensweise} dargestellt. Im ersten Teil der Arbeit wird eine Infrastruktur für Proxy-basierte Systeme konzipiert und ihre Realisierung beschrieben. Im zweiten Teil wird die Infrastruktur um dedizierte Fehlertoleranzmerkmale erweitert, die anschließend evaluiert werden. Dazu kommen zum einen Messungen am implementierten System und zum anderen Simulationen zum Einsatz. Das der Simulation zugrunde liegende Modell wurde dabei mit Hilfe der Messungen am implementierten System geeignet parametriert.

\vspace{1.5cm}

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=8.5cm,angle=0]{fig/Vorgehensweise.pdf}
    \setzeBreite
    \caption{Vorgehensweise und Struktur.}
    \label{fig:Vorgehensweise}
  \end{center}
\end{figure}

% ****************************************************************************
% ****************************************************************************
% ****************************************************************************
\part{Infrastruktur}
\label{part:Infrastruktur}

% ****************************************************************************
\chapter{Die Middleware Universal Plug and Play}
\label{sec:Universal_Plug_and_Play}

\sidenote{Warum UPnP?} Die im Rahmen der vorliegenden Arbeit vorgenommenen Untersuchungen lassen sich im Grunde auf alle gängigen Middleware-Systeme beziehen. Um jedoch einen möglichst konkreten Bezug zu einer existierenden Technologie herzustellen, wurde die Middlware \emph{Universal Plug and Play (UPnP)} als Referenz ausgewählt -- zumal sie im Rahmen der Implementierung des Sindrion-Systems (siehe Kapitel \ref{sec:Einleitung}) zum Einsatz kam. Um eine Verständnisgrundlage zu schaffen, wird die grundlegende Architektur von UPnP im Folgenden in knapper Form vorgestellt. Für eine genauere Betrachtung sei auf weiterführende Literatur verwiesen \cite{je03_upnp, upnp_spec}.

\begin{figure}[htbp]
%  \vspace{.5cm}
  \begin{center}
    \includegraphics[width=6.5cm,angle=0]{fig/Middleware.pdf}
    \setzeBreite
    \caption{Middleware als Verbindungsschicht.}
    \label{fig:Middleware}
  \end{center}
\end{figure}

\sidenote{Definition des Middleware-Begriffs} Allgemein wird eine Middleware, wie in Abbildung \ref{fig:Middleware} dargestellt, als Verbindungsschicht zwischen Applikationen und dem Netzwerk definiert \cite{em00_middleware}. Ihre zentrale Aufgabe ist der Umgang mit systeminhärenten Eigenschaften wie \emph{Heterogenität} und \emph{Dynamik}. Somit kommt Middleware in beinahe sämtlichen IT-Bereichen zum Einsatz. Auch im Umfeld von {\uc}-Umgebungen spielt Middleware eine zentrale Rolle. In diesem Umfeld hat eine Middleware folgende konkrete Aufgaben:

\begin{itemize}

\item \sfb Device- und Service-Discovery \normalfont\\ Die Middleware muss in der Lage sein, Geräte und Dienste zur Laufzeit bei Bedarf zu finden. Dies kann auf zwei Arten erfolgen: Entweder wird ein Lookup-Dienst verwendet (Jini-Technologie), bei dem verfügbare Geräte sich und ihre Dienste anmelden. Alternativ können Advertisement-Nachrichten verschickt werden, über die Geräte sich anderen Geräten bekannt machen.

\item \sfb Übermittlung von Steuerbefehlen \normalfont\\ Die von Geräten bereitgestellten Dienste enthalten Aktionen und Zustandsvariablen. Es ist Aufgabe der Middleware, Steuerbefehle an ein Gerät zu übermitteln. Das Gerät führt daraufhin Aktionen aus und der Status der Zustandsvariablen verändert sich.

\item \sfb Verwaltung von Ereignissen \normalfont\\ Wenn der Wert einer Zustandsvariablen sich verändert, sendet das Gerät ein Ereignis-Signal an beliebig viele Interessenten (Multicast). Diese Interessenten müssen sich zuvor für bestimmte Ereignisse oder Ereignistypen registrieren.

\end{itemize}

\parpic(2.5cm,1.5cm)[l]{\includegraphics[width=2.5cm]{fig/UPnP-Logo.png}} \sidenote{Einleitung} Die genannten Aufgaben werden von der Middlware Universal Plug and Play erfüllt. Sie dient der herstellerübergreifenden Ansteuerung von Geräten über ein IP-basierendes Netzwerk. Die Technologie basiert auf einer Reihe von standardisierten Netzwerkprotokollen und Datenformaten. Ursprünglich von der Firma Microsoft eingeführt, spezifiziert heute das UPnP-Forum\footnote{http://www.upnp.org} den UPnP-Standard und zertifiziert Geräte, die dem Standard entsprechen.

\vspace{-1ex} \piccaption{Struktur eines UPnP Device.\label{fig:Struktur_UPnP-Device}} \parpic[r][t]{\includegraphics[width=6cm]{fig/Struktur_UPnP-Device.pdf}} \sidenote{Struktur eines Devices} Allgemein werden \emph{UPnP Devices} und \emph{UPnP {\cp}s} unterschieden. Das Device ist ein Dienst\-anbieter, der {\cp} ist Dienstnehmer. Ein physikalisches Gerät kann sowohl Device als auch {\cp} sein. Ein Device bietet, wie in Abbildung~\ref{fig:Struktur_UPnP-Device} veranschaulicht, einen oder mehrere \emph{Services} an, die wiederum eine oder auch mehrere \emph{Actions} enthalten. Eine Action entspricht einer Kontrollnachricht, die dem Device gesendet werden kann, um eine bestimmte Aktion durchzuführen. Neben den Actions enthält ein Service auch Zustandsvariablen (\emph{State Variables}), die durch die Actions beeinflusst werden können oder Ereignisbenachrichtigungen (\emph{Events}) an {\cp}s senden können, sobald ihr Status sich ändert. Darüber hinaus kann ein Device beliebig viele \emph{Embedded Devices} enthalten, die ihrerseits wieder Services anbieten. Zur besseren Unterscheidung wird das "`äußere"' Device auch \emph{Root Device} genannt.

\sidenote{Der UPnP-Stack} Abbildung \ref{fig:UPnP-Stack} zeigt den UPnP-Protokoll-Stack, wie er in der \emph{UPnP Device Architecture} \cite{upnp_spec} definiert ist. Wie der Abbildung zu entnehmen ist, basiert UPnP auf TCP/IP und UDP/IP. Als eigentliches Transportprotokoll wird HTTP verwendet, wobei zwei spezielle Varianten von HTTP für die UDP-basierte Übertragung zum Einsatz kommen: HTTPU\footnote{Hypertext Transfer Protocol UDP} und HTTPMU\footnote{Hypertext Transfer Protocol Multicast UDP}. Die eigentlichen UPnP-Protokolle sind SSDP\footnote{Simple Service Discovery Protocol}, über das Discovery-Funktionen bereitgestellt werden, GENA\footnote{Generic Event Notification Architecture} für das Versenden und den Empfang von Ereignisbenachrichtigungen (Events), sowie SOAP\footnote{Simple Object Access Protocol} für den Aufruf von Actions. Die drei oberen Schichten des Protokoll-Stacks definieren die allgemeine Architektur eines UPnP-konformen Gerätes (UPnP Architecture Defined), welche Schnittstellen von dem Gerät bereitgestellt werden (UPnP Forum defined) und schließlich, welche Hersteller-spezifischen Erweiterungen {\ggf} im Gerät enthalten sind (UPnP Vendor defined).

\sidenote{Verfügbarkeit von Stacks} UPnP-Stacks sind für eine große Anzahl an Plattformen verfügbar. Als Beispiele seien der UPnP-Stack \emph{Cyber Garage}\footnote{http://www.cybergarage.org} (C++ und Java), die \emph{Windows Mobile Server Components} für Pocket PC (C++), sowie die Embedded UPnP Stacks von \emph{Atinav}\footnote{http://www.atinav.com} oder \emph{EBSnet}\footnote{http://www.ebsnetinc.com} zu nennen. Im Rahmen der vorliegenden Arbeit wurde ein Java-basierter Stack von Infineon Technologies (Infineon UPnP/1.0 Protocol Stack 1.21) eingesetzt.

\begin{figure}[htbp]
  \vspace{.5cm}
  \begin{center}
    \includegraphics[width=9cm,angle=0]{fig/UPnP-Stack.pdf}
    \setzeBreite
    \caption{Der UPnP Protokoll-Stack.}
    \label{fig:UPnP-Stack}
  \end{center}
\end{figure}

\sidenote{Kommunikations\-phasen} Der Ablauf der UPnP-Kommunikation wird allgemein in 5 Phasen eingeteilt (siehe Abbildung~\ref{fig:UPnP-Kommunikationsphasen}). Phasen 0-2 finden stets in angegebener Reihenfolge statt, während für die Phasen 3-5 keine feste Reihenfolge vorgesehen ist \cite{upnp_spec}:

\begin{enumerate}

\item[0.] \sfb Addressing \normalfont\\ Da UPnP auf IP-Netzwerken basiert, muss dem Gerät im ersten Schritt eine IP-Adresse zugeordnet werden. Dies kann nach dem UPnP-Standard einerseits via DHCP erfolgen oder, sofern kein DHCP-Server verfügbar ist, via AUTO-IP. Da die Zuordnung der IP-Adresse eine elementare Grundvoraussetzung für die folgenden Schritte ist, wird dieser Schritt oft als "`Schritt 0"' bezeichnet.

\item[1.] \sfb Discovery \normalfont\\ Sobald ein Gerät über eine IP-Adresse verfügt, muss es seine Existenz im Netzwerk bekannt machen. Dies erfolgt durch das Versenden von Multicast-Nachrichten auf Basis des SSDP-Protokolls. Dabei enthält die \emph{Discovery Message} nur die wichtigsten Angaben über das Gerät und seine Dienste, wie z. B. den Gerätenamen, Gerätetyp und eine URL zur genauen Beschreibung des Gerätes. Umgekehrt können {\cp}s auch aktiv nach UPnP-Geräten im Netzwerk suchen.

\item[2.] \sfb Description \normalfont\\ Sobald ein {\cp} ein Gerät im Netzwerk entdeckt hat, lädt er Beschreibungsdateien von dem Gerät herunter und wertet sie aus. Diese XML-formatierten \emph{Device- und Service Descriptions} beinhalten neben allgemeinen Geräteinformationen Angaben über die von dem Gerät bereitgestellten Dienste sowie eine genaue Beschreibung ihrer Schnittstellen. Beispiele für UPnP Descriptions befinden sich in Anhang \ref{sec:Anhang_Description_Beispiele}.

\item[3.] \sfb Control \normalfont\\ Anhand der Informationen, die der {\cp} der Beschreibungsdateien des Gerätes entnommen hat, kann er nun SOAP-Mitteilungen an das Gerät schicken, um es zu steuern.

\item[4.] \sfb Eventing \normalfont\\ Um den Zustand von Zustandsvariablen nicht über Polling-Verfahren abfragen zu müssen, können {\cp}s sich für Ereignisbenachrichtigungen registrieren. Somit werden sie bei jeder Änderung einer Zustandsvariablen automatisch über das GENA-Protokoll benachrichtigt.

\enlargethispage{.5cm}

\item[5.] \sfb Presentation \normalfont\\ Neben der Möglichkeit zur Steuerung über das SOAP-Protokoll und der GENA-Ereignis\-benachrichtigung bietet jedes UPnP-Gerät eine eigene Web-Seite an, auf die über einen herkömmlichen Web-Browser zugegriffen werden kann. Neben allgemeinen Informationen über das Gerät kann die {\sog} \emph{Presentation Page} auch eine Benutzeroberfläche zur direkten Steuerung {\bzw} Konfiguration des Gerätes enthalten.

\end{enumerate}

\vspace{1cm}

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=10.5cm,angle=0]{fig/UPnP-Kommunikationsphasen.pdf}
    \setzeBreite
    \caption{Phasen der UPnP-Kommunikation.}
    \label{fig:UPnP-Kommunikationsphasen}
  \end{center}
\end{figure}

% ****************************************************************************
\chapter{Konzeptionelle Überlegungen zur Infrastruktur}
\label{sec:Konzeption_Infrastruktur}

\sidenote{Übersicht} Im Folgenden werden einige grundlegende Überlegungen, die zum einen die Analyse des Problems, limitierte Geräte in Middleware-basierte Netzwerkgemeinschaften zu integrieren und zum anderen mögliche Lösungsansätze betreffen, diskutiert. Die in der vorliegenden Arbeit präferierte Lösung ist schließlich die Unterstützung limitierter Geräte über {\dproxies}. Während in diesem Kapitel lediglich grundlegende Konzepte diskutiert werden, erfolgt die Beschreibung einer Lebenszyklusverwaltung für {\dproxies} in Kapitel~\ref{sec:Lebenszyklusverwaltung}.

% ----------------------------------------------------------------------------
\section{Merkmale limitierter Geräte}
\label{sec:Merkmale_limitierter_Geraete}

\sidenote{Was ist ein limitiertes Gerät?} Allgemein zeichnet sich ein limitiertes Gerät durch sein Unvermögen aus, existierende Anforderungen aufgrund beschränkter Ressourcen nicht bzw. nicht zufriedenstellend zu erfüllen. Im Rahmen der vorliegenden Arbeit sprechen wir dann von limitierten Geräten, wenn sie aufgrund ihrer Beschränkungen Middleware-Protokolle, die zur Teilnahme an der Netzwerkgemeinschaft erforderlich sind, nicht oder nur unzureichend unterstützen. Typische Beispiele für limitierte Geräte sind \emph{Sensoren} und \emph{Aktuatoren}. Typische Kenngrößen limitierter Geräte sind:

\begin{itemize}

\item \sfb Geringe Rechenleistung \normalfont\\ Die Hardware-Plattform basiert auf einem 8-Bit oder 16-Bit Mikrocontroller.

\item \sfb Geringe Speicherkapazität \normalfont\\ Es stehen ca. 64 kB ROM / 16 kB RAM oder weniger zur Verfügung.

\item \sfb Geringe Energiereserven \normalfont\\ Es steht {\idr} keine permanente Energieversorgung zur Verfügung.

\item \sfb Eingeschränkte Konnektivität \normalfont\\ Das Gerät verfügt über zumeist kabellose Konnektivität, selten werden kabelgebundene Verbindungen verwendet. Brutto-Datenraten liegen im Bereich von 50 kbit/s.

\end{itemize}

\sidenote{Referenz\-implemen\-tierung} Die im Rahmen der vorliegenden Arbeit betrachtete Referenzimplementierung eines limitierten Gerätes ist der \emph{\strans}, der im Rahmen des Sindrion-Projektes parallel zur vorliegenden Arbeit entwickelt wurde -- für Evaluierungen allerdings nur in Form eines Emulators zur Verfügung stand. Nähere Informationen zum {\strans} befinden sich in Anhang~\ref{sec:Anhang_Sindrion_Transceiver}.

% ----------------------------------------------------------------------------
\section{Problemanalyse}
\label{sec:Problemanalyse}

\sidenote{Worin ist die Beschränkung begründet?} Es gilt zu klären, warum die Unterstützung einer Middleware für ein limitiertes Gerät wie den Sindrion Transceiver nicht oder nur eingeschränkt möglich ist: Die Fähigkeit einer Middleware, mit System-inhärenten Merkmalen wie \emph{Heterogenität} und \emph{Dynamik} umzugehen, wird {\idr} durch den Einsatz plattformunabhängiger und damit zumeist komplexer Protokolle erkauft. So basiert {\zb} die Jini-Technologie wesentlich auf \emph{Java Remote Method Invocation (RMI)}, während UPnP XML-basierte Protokolle wie \emph{SOAP} verwendet (siehe Kapitel~\ref{sec:Universal_Plug_and_Play}). Um ein vollwertiges UPnP Device bereit stellen zu können, müsste ein limitiertes Gerät in der Lage sein, XML-basierte SOAP-Actions auszuwerten. Listing~\ref{lst:SOAP-Action} zeigt beispielhaft die SOAP-Action \emph{SwitchPower} eines \emph{UPnP Binary Light} \cite{upnp_blight}. Wie dem Beispiel zu entnehmen ist, erfordert selbst ein vergleichsweise simpler Vorgang, wie das Setzen eines neuen Lichtwertes (Zeilen 7 bis 9), die Verarbeitung von XML-Nachrichten.

\lstinputlisting[caption=Aufbau einer SOAP-Action.,basicstyle=\footnotesize, breaklines=true, breakatwhitespace=true, label=lst:SOAP-Action]{fig/listings/Soap_Action}

\sidenote{Erforderliche Protokolle} Als UPnP {\cp} müsste ein limitiertes Gerät in der Lage sein, XML-basierte Device bzw. Service Descriptions zu verarbeiten wie in Anhang \ref{sec:Anhang_Description_Beispiele} dargestellt. Alles in allem muss ein vollwertiges UPnP-Gerät (Device oder {\cp}) folgende Protokolle unterstützen:

\begin{itemize}

\item Ein Netzzugangsprotokoll (Ethernet, WLAN etc.),

\item das Internetprotokoll (IP),

\item DHCP und Auto IP (zum Beziehen einer IP-Adresse),

\item TCP und UDP als Transportprotokolle,

\item HTTP (HTTPU/HTTPMU), sowie

\item SOAP, GENA und SSDP als Anwendungsprotokolle.

\end{itemize}

Neben den entsprechenden Protokoll-Stacks werden folgende zusätzliche Komponenten benötigt:

\begin{itemize}

\item ein (einfacher) Webserver,

\item ein XML Parser.

\end{itemize}

\goodbreak \sidenote{Speicherbedarf} Embedded UPnP-Stacks wie von \emph{Atinav} oder \emph{EBSnet} (siehe Kapitel~\ref{sec:Universal_Plug_and_Play}) belegen allein ca. 80 - 120 kB ROM \cite{kr06_upnp}, während embedded TCP/IP Stacks 10 - 40 kB ROM (uIP\footnote{http://www.sics.se/\~{}adam/uip} bzw. IwIP\footnote{http://savannah.nongnu.org/projects/lwip}) belegen. Für einen einzelnen SOAP-Service fallen allein 65 kB RAM an \cite{ma06_embedded}. Insgesamt übersteigt dieser Speicherbedarf die Kapazitäten eines limitierten Gerätes wie dem Sindrion Transceiver bei weitem. Natürlich trifft diese Problematik auch --~und mitunter in höherem Maße~-- auf andere Middlewaretechnologien als UPnP zu. So würde {\zb} eine Unterstützung der Jini-Technologie eine vollwertige \emph{Java Virtual Machine (JVM)} erfordern \cite{gu02_jini}. Die JVM der \emph{Java Standard Edition} belegt {\zb} bei Ausführung eines Programms, das eine einfache Schleife durchläuft, bereits 7 MB RAM\footnote{Getestet auf einem herkömmlichen PC.}. Für die virtuelle Maschine der Java Micro Edition, Connected Device Configuration sind immer noch mindestens 2 MB RAM erforderlich~\cite{re06_bluetooth}.

\sidenote{Resume} Zusammenfassend kann gesagt werden, dass limitierte Geräte die genannten Anforderungen nicht oder nur unzureichend erfüllen können, da sie über zu geringe Ressourcen wie Rechenleistung oder Arbeitsspeicher verfügen.

%\sidenote{Konn., Rechenl., Energie} XML hat großen Overhead -- {\zb} liegt der Overhead (Laufzeitverhalten) von XML-RPC beim 10-fachen Wert von RMI \cite{do01_xml}. Kabellose Kommunikation erfordert ungleich mehr Energie als die Durchführung von Berechnungen \cite{sa02_sensor}. \todo{Recherchieren!} XXX Jule pro Byte \cite{he00_energy}. XML-basierte Protokolle erhöhen den Kommunikationsoverhead sowie den Verarbeitungsaufwand.

% ----------------------------------------------------------------------------
\section{Verwendung von \dproxies}

\sidenote{Lösungsansätze} Um das im vorherigen Abschnitt betrachtete Problem zu lösen --~also limitierte Geräte trotz ihrer Beschränkungen in Middleware-basierte Netzwerkgemeinschaften aufzunehmen~-- können folgende grundlegende Ansätze verfolgt werden:

\begin{itemize}

\item \sfb Optimierte Implementierung \normalfont\\ Die Architektur und Algorithmik der Software des limitierten Gerätes kann bis zu einem gewissen Grad auf einen geringen Ressourcenverbrauch optimiert werden. Dies erfolgt {\idr} durch eine gezielte Abstimmung der Implementierung auf den Verwendungszweck und die Hardwareplattform des Gerätes. Hierzu werden oft Codegenerierungsverfahren \cite{lo97_corba, ma00_code} eingesetzt. Diese Vorgehensweise schränkt jedoch die Vielseitigkeit der Applikation ein und kann einen erhöhten Implementierungsaufwand nach sich ziehen.

\item \sfb Verzicht auf Funktionalität \normalfont\\ Ein weiterer möglicher Ansatz ist, die Funktionalität des Systems zu reduzieren, indem etwa alternative oder speziell angepasste Middleware-Protokolle mit geringeren Anforderungen systemweit eingesetzt werden. Dies ist jedoch {\ia} keine angemessene Lösung, da im System einzusetzende Protokolle oft äußere Vorgaben sind und durch mögliche proprietäre Veränderungen die Anforderung der Standard-Konformität (siehe Abschnitt \ref{sec:Allgemeine_Anforderungen}) verletzt wird. \goodbreak

\item \sfb Verlagerung von Funktionalität \normalfont\\ Der dritte mögliche Ansatz besteht in der Verlagerung von Funktionalität vom limitierten Gerät auf ein oder mehrere entfernte Geräte, die über entsprechend mehr Ressourcen verfügen und dem Aufbau einer Kommunikationsverbindung zwischen den Geräten. Somit wird aus dem limitierten Gerät und dem entfernten Host, der Funktionalität des limitierten Gerätes aufnimmt, ein verteiltes System.

\end{itemize}

\sidenote{Fokus auf Verlagerung von Funktionalität} Im Rahmen der vorliegenden Arbeit liegt der Fokus auf dem dritten Ansatz, also der Verlagerung von Funktionalität. Dies wird durch die Verwendung von \emph{\dproxies} erreicht. Allgemein ist ein Proxy ein Stellvertreter, der eine Aufgabe anstelle einer Instanz durchführt, die er vertritt. Ein {\dproxy} hat die Aufgabe, ein (limitiertes) Gerät im Netzwerk zu vertreten: Er wird auf einem entfernten, {\idr} leistungsfähigeren Gerät (Proxy-Host) ausgeführt und hat im Prinzip die Funktion eines Treibers (siehe Abbildung~\ref{fig:Proxykonzept}). Er übernimmt die Anbindung an die Middleware und kommuniziert mit dem Gerät über ein schlankes, auf die Fähigkeiten des Gerätes zugeschnittenes Protokoll. Das Protokoll zwischen Proxy und limitiertem Gerät kann vollkommen proprietär sein, da es zur Middleware hin durch den Proxy gekapselt und somit im System nicht sichtbar wird.

\mybox{Die Instanz, die die Lebenszyklusverwaltung der Proxies durchführt, wird im Folgenden \emph{Application Manager (AM)} genannt. Als Bezeichnung für ein limitiertes Gerät, das durch einen Proxy vertreten wird, wird im Folgenden der Begriff \emph{\trans} (in Anlehnung an den Sindrion-Transceiver) verwendet.}

\sidenote{Sindrion Control} Das im Sindrion-System verwendete binäre Protokoll zwischen Proxy und {\strans} wird \emph{Sindrion Control} genannt \cite{st06_control}. Es setzt direkt auf einer TCP-Verbindung auf und stellt einfache, auf die Funktionen des {\strans} zugeschnittene Kommandos bereit. Ein vergleichbares Verfahren kommt auch im Rahmen der \emph{Jini Surrogate Architecture} zum Einsatz \cite{surrogate_spec}.

\sidenote{Beispielszenarium} Abbildung \ref{fig:Beispielszenarium} stellt ein Beispielszenarium mit {\dproxies} dar: Die limitierten Geräte (\trans) können in einem einfachen Beispiel Lichtschalter und Lampen sein. Sie werden von ihren Proxies im Middleware-System vertreten. Wird der Schalter betätigt, so erfolgt die Kommunikation zwischen Schalter und Proxy bzw. Lampe und Proxy über jeweils private, schlanke Protokolle (wie Sindrion Control), während die beiden Proxies über das Middleware-Protokoll ({\zb} UPnP) kommunizieren. Eine native Middleware-basierte Applikation wie eine intelligente Haussteuerung, kann den Dienst der Lampe ebenfalls nutzen. Die Umsetzung auf das schlanke Protokoll der Lampe ist dabei vollkommen transparent.

%\vspace{.5cm}

\begin{figure}[htbp]
  \hspace{-.6cm}
  \includegraphics[width=16cm,angle=0]{fig/Proxykonzept.png}
  \setzeBreite
  \caption[Der Proxy vertritt das limitierte Gerät.]{Der Proxy vertritt das limitierte Gerät im Middleware-basierten Netzwerk.}
  \label{fig:Proxykonzept}
\end{figure}

\begin{sidewaysfigure}[htbp]
  \begin{center}
    \hspace{-1cm}
    \includegraphics[width=19cm,angle=0]{fig/Gesamtszenarium_Teil1_Alternative.pdf}
    \setzeBreite
    \caption{Beispielszenarium.}
    \label{fig:Beispielszenarium}
  \end{center}
\end{sidewaysfigure}

% ----------------------------------------------------------------------------
\section{Allgemeine Systemanforderungen}
\label{sec:Allgemeine_Anforderungen}

\sidenote{Einleitung} Im Folgenden werden typische allgemeine Anforderungen an {\uc}-Sys\-te\-me \cite{ed01_challenges, sa01_challanges} diskutiert. Es wird dabei gesondert darauf eingegangen wie diese Anforderungen trotz oder gerade \emph{aufgrund} der Anwendung des Proxy-Konzeptes erfüllt werden können.

\minisec{Selbstkonfiguration und prompte Interoperabilität}

{\uc}-Systeme müssen in der Lage sein, sich selbst ohne Zutun eines Systemadministrators zu konfigurieren. Für Proxy-basierte Systeme bedeutet das insbesondere, dass ein Proxy transparent für den Nutzer gestartet werden muss, wenn ein {\trans} dem System beitritt und beendet, wenn der {\trans} nicht mehr zur Verfügung steht. Sofern der Code des Proxys auf dem Host des {\am}s noch nicht vorhanden ist, muss er automatisch dort bereitgestellt werden.

\sidenote{Prompte Interoperabilität} Geräte, die unterschiedlichen Standards entsprechen, sollten in der Lage sein, \emph{Stan\-dard-übergreifend} zu interagieren. Das heißt, Geräte sollten auch "`fremde"' Standards unterstützen. Solch \emph{prompte Interoperabilität} kann durch die Verwendung Proxy-basierter Systeme unterstützt werden, da ein Proxy durchaus mehrere Schnittstellen zu unterschiedlichen Middleware-Standards besitzen kann. So ist es denkbar, dass ein Proxy die Funktionen seines {\trans}s gleichzeitig auf einen UPnP- und einen Jini-Dienst abbildet oder ein {\am} mehrere Typen von {\trans}n, die unterschiedlichen Discovery-Protokollen entsprechen, unterstützt.

\minisec{Ökonomischer Umgang mit Systemressourcen}

\sidenote{1 AM bei N Proxies} Um Systemressourcen nicht unnötig zu verbrauchen, sollte ein einzelner {\am} in der Lage sein, Proxies für möglichst viele {\trans} auszuführen. Neben der Bereitstellung entsprechender Verwaltungsfunktionalität zur Ausführung mehrerer Proxies ist zu berücksichtigen, dass die Ausführung eines Proxys in einem eigenständigen Prozess im Allgemeinen mehr Arbeitsspeicher benötigt, als in einem Thread, der im Prozess des {\am}s ausgeführt wird. %Aus diesem Grund bietet sich die Verwendung von Laufzeitumgebungen, wie die \emph{Java Virtual Machine} an, die \emph{dynamisches Linken} beherrschen und damit Code zur Laufzeit nachladen können.

\sidenote{Weitere Funktionen} Weiterhin kann der Proxy Funktionen des {\trans}s übernehmen, die über die Middle\-wa\-re-Anbindung hinaus gehen: So kann der Proxy rechenintensive Aufgaben wie die Aufbereitung der vom {\trans} gelieferten Rohdaten übernehmen. Als Beispiel sei eine Bildverarbeitung genannt, die nicht auf einer Kamera, sondern auf dem zugehörigen Proxy durchgeführt wird. Ferner kann der Proxy in vielen Anwendungsfällen Anfragen von Clients eigenständig beantworten, während sich das limitierte Gerät im Ruhezustand befindet, um Energie zu sparen. So ist {\zb} denkbar, dass das limitierte Gerät seinen Proxy periodisch mit Messdaten versorgt und zwischendurch in den Standby-Modus wechselt, während der Proxy jederzeit auf Anfrage von Clients den zuletzt aktualisierten Wert liefert. Ein alternativer Ansatz ist, das limitierte Gerät bis auf rudimentäre Kommunikationsfähigkeiten herunter zu fahren, sodass das Gerät auch \emph{asynchron} von seinem Proxy benachrichtigt werden kann, wie es beim {\strans} der Fall ist (siehe Anhang \ref{sec:Anhang_Sindrion_Transceiver}).

\sidenote{Wo installiert man sowas?} Sowohl die {\dproxies} selbst, als auch die Application Manager benötigen Ressourcen und müssen an geeigneter Stelle im System ausgeführt werden. Grundsätzlich ist die Verwendung herkömmlicher PCs möglich, um {\am} und {\dproxies} auszuführen. Allerdings macht es Sinn, auch andere bereits im System vorhandene Geräte für die Ausführung von Proxies zu verwenden. Beispiele für derartige Geräte sind \emph{Residential Gateways}, \emph{WIFI-Accesspoints} oder \emph{SetTop Boxen}.

\minisec{Zuverlässigkeit}

Zuverlässigkeit spielt in verteilten Systemen allgemein eine zentrale Rolle, da durch die Verzahnung der verteilten Komponenten bei einem Ausfall schnell Teilbereiche oder gar das gesamte System betroffen sein können. Dieser Effekt wird bei Anwendung des Proxy-Konzeptes noch verstärkt: Da ein limitiertes Gerät und sein Proxy ein Seriensystem bilden (siehe Kapitel~\ref{sec:Grundlagen_Fehlertoleranz}), reicht der Ausfall einer der beiden Komponenten, um den Ausfall des gesamten Dienstes zu erwirken. Werden mehrere Proxies auf einem einzelnen Host ausgeführt, so sind von einem Ausfall des Hosts gleich mehrere Proxies betroffen. Allgemein müssen Zuverlässigkeitsanforderungen bereits beim Systemdesign berücksichtigt werden -- so ist eine automatische Lebenszyklusverwaltung bereits ein Zuverlässigkeitsmerkmal, da beendete Proxies bei Bedarf automatisch neu gestartet werden. Zusätzlich kann die Zuverlässigkeit des Systems durch den Einsatz dedizierter Fehlertoleranzmechanismen, wie sie im zweiten Teil dieser Arbeit betrachtet werden, erhöht werden. Letztendlich ist anzustreben, dass die Zuverlässigkeit eines Proxy-basierten Systems der eines Standalone-Systems nicht nachsteht.

\minisec{Vertretbarer Implementierungsaufwand}

Bei Anwendung von Proxies ist aufgrund der Verzahnung von Proxy und {\trans} ein erhöhter Implementierungsaufwand im Vergleich zur Realisierung von Standalone-Geräten zu erwarten. Der erhöhte Implementierungsaufwand kann allerdings durch geeignete Entwicklungsumgebungen sowie Codegenerierungsverfahren \cite{ma00_code, sc06_eiblue, ba07_soa} kompensiert werden.

\minisec{Standard-Konformität}

Die verwendeten Technologien und Komponenten sollten möglichst Standard-konform sein oder zumindest keine Inkompatibilitäten mit Standard-konformen Komponenten hervorrufen. Für Proxy-basierte Systeme heißt das, dass Schnittstellen, die im Gesamtsystem sichtbar sind, entweder gängigen Standards entsprechen oder zumindest möglichst nah an gängige Standards angelehnt sein sollten.

% ****************************************************************************
\chapter{Lebenszyklusverwaltung für {\dproxies}}
\label{sec:Lebenszyklusverwaltung}

\sidenote{Aufgaben des {\am}s} {\dproxies} können nur dann effizient eingesetzt werden, wenn ihre Lebenszyklen automatisch und transparent verwaltet werden. Diese Aufgabe wird durch den {\am} erfüllt und gliedert sich in vier wesentliche Schritte, die in den folgenden Abschnitten näher erläutert werden:

\begin{enumerate}

\item \sfb Discovery der {\trans} \normalfont\\ Der {\am} muss in der Lage sein, {\trans} im System zu entdecken, für die noch kein Proxy ausgeführt wird.

\item \sfb Aushandlung der Proxy-Ausführung \normalfont\\ Es muss bestimmt werden, welcher {\am} den Proxy des {\trans}s ausführt.

\item \sfb Bereitstellung des Proxy-Codes \normalfont\\ Der Code des Proxys muss von einer Quelle bezogen werden.

\item \sfb Ausführen bzw. Beenden der Proxies \normalfont\\ Der Proxy muss automatisch gestartet werden bzw. beendet, wenn der {\trans} nicht mehr zur Verfügung steht.

\end{enumerate}

\sidenote{Anforderungen an den {\trans}} Daraus ergeben sich spezielle Anforderungen, die {\trans} erfüllen müssen, um an einer Lebenszyklusverwaltung für {\dproxies} teilnehmen zu können. Neben der grundlegenden Fähigkeit zur Kommunikation mit anderen Geräten sind dies:

\begin{itemize}

\item \sfb Unterstützung eines gemeinsamen Discovery-Protokolls \normalfont\\ Damit der {\trans} von den {\am}n entdeckt werden kann, muss er an einem Discovery-Protokoll teilnehmen können, das auch von den {\am}n unterstützt wird.

\item \sfb Übermittlung der URL des Proxy-Codes \normalfont\\ Da der Proxy von dem {\trans} selbst bereit gestellt werden soll, muss der {\trans} Kenntnis haben, unter welcher URL der Code des zugehörigen Proxys bezogen werden kann. Ferner muss er in der Lage sein, den {\am}n den URL mitzuteilen.

\item \sfb Unterstützung  eines vom Proxy verwendeten Bind-Protokolls \normalfont\\ Sobald der zugehörige Proxy gestartet ist, bindet er sich über ein eigenes Protokoll an den {\trans}. Dieses Protokoll kann privat sein, muss jedoch vom {\trans} und seinem Proxy unterstützt werden.

\end{itemize}

\sidenote{Pairing} Um einem {\trans} eindeutig einen Proxy zuordnen zu können, ist ein \emph{Pairing-Mechanismus} erforderlich, wie er in Abbildung \ref{fig:Aktivitätsdiagramm_Transceiver} dargestellt ist. Ist der {\trans} im Zustand \emph{paired}, signalisiert er, dass er an einen Proxy gebunden ist und damit kein neuer Proxy gestartet werden darf. Der {\trans} wechselt in den Zustand \emph{paired}, sobald sein Proxy ausgeführt wird und eine Verbindung zu ihm aufbaut. Sobald der Proxy beendet wird, muss der {\trans} wieder in den Zustand \emph{unpaired} wechseln und signalisiert damit, dass er den Start eines Proxys wünscht. \sidenote{Heartbeat} Eine wichtige Voraussetzung für den ordnungsgemäßen Ablauf ist, dass der Proxy sich beim Beenden bei seinem {\trans} abmeldet. Für den Fall, dass er dies versäumt, muss der {\trans} die Aktivität des Proxys überwachen (\emph{Heartbeat-Messages}) und bei Inaktivität die Verbindung lösen und in den Zustand \emph{unpaired} übergehen.

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=7cm,angle=0]{fig/diagramme/Aktivitätsdiagramm_Transceiver.pdf}
    \setzeBreite
    \caption{Pairing-Vorgang aus Sicht des Transceivers.}
    \label{fig:Aktivitätsdiagramm_Transceiver}
  \end{center}
\end{figure}

% ----------------------------------------------------------------------------
\section{Discovery der {\trans}}
\label{sec:Discovery_limitierter_Geräte}

\sidenote{Anforderungen} {\am} und {\trans} müssen ein gemeinsames Discovery-Protokoll verwenden, damit die {\trans} von den {\am}n entdeckt werden können. Dabei ist es erforderlich, dass das verwendete Discovery-Protokoll die {\trans} nicht überfordert. Entsprechend den in Abschnitt~\ref{sec:Allgemeine_Anforderungen} gestellten Anforderungen ist es weiterhin wünschenswert, ein Standard-konformes Discovery-Protokoll einzusetzen. Die im Folgenden genannten Standards für Discovery sind bzgl. des Einsatzes im betrachteten System denkbar \cite{be00_comparison}. Eine Übersicht ist darüber hinaus in Tab. \ref{tab:Discovery-Protokolle} gegeben (siehe auch Abschnitt~\ref{sec:Thematisches_Umfeld}).

\begin{itemize}

\item \sfb Jini Multicast Request Protocol \normalfont\\ Das von der Jini-Technologie verwendete Multicast Request Protocol ermöglicht das Finden eine \emph{Jini Lookup Services} \cite{su06_discovery}. Das eigentliche Service Discovery bzw. die Anmeldung eines Dienstes wird anschließend über diesen Lookup Service abgewickelt. Zum Anmelden eines Dienstes lädt der Dienstanbieter ein {\sog} \emph{Proxy-Dienstobjekt} auf den Lookup Server, das nach Abgleich mit einem Template vom Dienstnehmer bezogen werden kann.

\item \sfb Simple Service Discovery Protcol (SSDP) \normalfont\\ SSDP ist das von UPnP verwendete Discovery-Protokoll \cite{upnp_spec}. Es setzt auf HTTPU {\bzw} HTTPMU (siehe Kapitel \ref{sec:Universal_Plug_and_Play}) auf, je nachdem, ob ein Gerät sich im Netz bekannt macht (\emph{Notify}) oder auf eine Suchanfrage (\emph{Find}) reagiert.

\item \sfb Peer Discovery Protocol \normalfont\\ Das von JXTA verwendete Peer Discovery Protocol \cite{su06_jxta} definiert XML-basierte \emph{Discovery Query Messages} und \emph{Discovery Response Messages}. Ähnlich wie bei UPnP werden Advertisements verwendet, um Geräte im Netzwerk bekannt zu machen.

\item \sfb Service Location Protocol (SLP) \normalfont\\ SLP ist ein Discovery-Protokoll, das ähnlich wie das Jini Multicast Request Protocol auf einem dreistufigen Konzept basiert und zentrale Lookup-Dienste, sog \emph{Service Agents} voraussetzt.

\item \sfb Web Service Discovery \normalfont\\ Web Service Discovery ist ein auf SOAP bzw. SOAP-over-UDP basierendes Discovery Protokoll \cite{mi05_discovery}. Es wird im Rahmen von DPWS verwendet und besitzt Ähnlichkeiten zu dem von UPnP verwendeten SSDP.

\end{itemize}

%\vspace{.5cm}

\begin{table}[htbp]
\begin{center}
\begin{tabularx}{15cm}{p{3cm}XXXXX}
  \toprule
  \rowcolor{dunkelgrau}
  ~ & \textbf{Jini} & \textbf{SSDP} & \textbf{JXTA} & \textbf{SLP} & \textbf{DPWS}\\
  \midrule
  \rowcolor{hellgrau1}
  Netzwerktransport &  unabh. & TCP/IP & unabh. & unabh. &  TCP/IP\\
  \rowcolor{hellgrau2}
  Programmier\-sprache & Java & unabh. & unabh. & unabh. & unabh.\\
  \rowcolor{hellgrau1}
  Verwendung zentraler Komp. & ja & nein & teilw. & ja & nein\\
  \rowcolor{hellgrau2}
  Eignung für limitierte Geräte & -- & \checkmark & \checkmark & \checkmark & \checkmark \\
  \bottomrule
\end{tabularx}
\setzeBreite
\caption{Gegenüberstellung der Discovery-Protokolle.}
\label{tab:Discovery-Protokolle}
\end{center}
\end{table}

\enlargethispage{-.5cm}

\sidenote{Evaluierung der Protokolle} Das Jini Multicast Request Protocol sowie SLP setzen die Verfügbarkeit von zentralen Komponenten in Form von Lookup Servern bzw. Directory Agents voraus. Dies stellt bzgl. des Discovery-Vorgangs limitierter Geräte prinzipiell kein Problem dar, da diese Funktion von den {\am}n übernommen werden kann. Allerdings setzt Jini die Verwendung von Java/RMI voraus\footnote{Die Referenzimplementierung der Firma Sun verwendet zum Anmelden eines Dienstes an den Lookup Server das RMI-Protokoll.}, was das Multicast Request Protocol für limitierte Geräte ungeeignet macht. Sofern ein TCP/IP-Stack (erforderlich für SSDP/DPWS) verfügbar ist, sind die anderen Protokolle prinzipiell für die Verwendung auf limitierten Geräten geeignet. Da UPnP jedoch bereits als Referenztechnologie dient, wurde im Rahmen der vorliegenden Arbeit SSDP als Discovery-Protokoll ausgewählt.

\begin{sloppypar}

\vspace{-3ex} \piccaption{Für den Discoveryvorgang relevante Schichten des UPnP-Stacks. \label{fig:UPnP-Stack_Disco}} \parpic(8cm,6.3cm)[r][c]{\includegraphics[width=8cm]{fig/UPnP-Stack_Disco.pdf}} \sidenote{Für Discovery benötigte UPnP-Protokolle} Wie aus Abbildung \ref{fig:UPnP-Stack_Disco} deutlich wird, werden für eine ausschließliche Unterstützung von UPnP-Dis\-co\-ve\-ry die Protokolle SOAP und Teile von GENA, sowie die darunterliegenden Protokolle HTTP {\bzw} TCP nicht benötigt (vgl. Abbildung \ref{fig:UPnP-Stack}). Damit entfällt die aufwendige Verarbeitung von XML-Daten. Da lediglich ein UDP/IP-Stack benötigt wird, kann die notwendige Funktionalität für den Discovery-Vor\-gang im {\trans} bereitgestellt werden, ohne die Ressourcen des Gerätes über Maßen zu strapazieren.\footnote{Es existieren eine Reihe schlanker UDP/IP-Stacks (siehe Abschnitt \ref{sec:Problemanalyse}), die für die Verwendung in einem {\trans} geeignet sind.} Um Discovery zu unterstützen, muss ein limitiertes Gerät damit lediglich \emph{SSDP Notify} Nachrichten (Advertisements) versenden, wie in Listing \ref{lst:SSDP-Notify} dargestellt. Ein solches Advertisement ist nicht XML-basiert und kann in Teilen vorgefertigt im Speicher des {\trans}s vorgehalten werden. Es muss daher nicht dynamisch (Ressourcen-intensiv) erzeugt werden. Lediglich individuelle Angaben wie die IP-Adresse des Gerätes müssen an entsprechender Stelle (Zeile 8 im Listing) in den vorbereiteten Code-Block eingesetzt werden.

\end{sloppypar}

\pagebreak

\lstinputlisting[caption=UPnP-Advertisement.,basicstyle=\footnotesize, breaklines=true, breakatwhitespace=false, label=lst:SSDP-Notify]{fig/listings/Advertisement}

\sidenote{Notwendigkeit eines Erkennungsmerkmals} Ein UPnP-Gerät, das keinerlei Funktionalität für Control und Event Notification bereit stellt, wird \emph{UPnP Basic Device} genannt \cite{upnp_spec}. Damit stellt der {\trans} ein UPnP Basic Device dar. Allerdings muss ein {\am} in der Lage sein, {\trans}, die durch Proxies vertreten werden sollen, von herkömmlichen UPnP Basic Devices zu unterscheiden. Hierzu ist ein Erkennungsmerkmal notwendig. Im Beispiel des Sindrion-Systems liegt dieses Erkennungsmerkmal in der Benennung der UPnP Presentation Page in der Device Description, die den Dateinamen \emph{SindrionTX.html} besitzt. Ein weiteres Merkmal ist das Vorhandensein der Datei \emph{Sindrion.zip}, die die Sindrion-spezifischen Beschreibungs\-dateien ({\su}) enthält. Details zu den Erkennungsmerkmalen befinden sich in Anhang~\ref{sec:Anhang_Zustandsautomaten}.

% ----------------------------------------------------------------------------
\section{Aushandlung der Proxy-Ausführung}
\label{sec:Aushandlung_Proxy-Ausfuehrung}

\sidenote{Einleitung} Zu einem Zeitpunkt darf stets nur ein aktiver Proxy pro {\trans} vorhanden sein, da ansonsten nicht eindeutig ist, welcher Proxy für den {\trans} zuständig ist. In diesem Abschnitt werden geeignete Verfahren diskutiert, wie die Zuständigkeiten für den Start eines Proxys ausgehandelt werden können.

\enlargethispage{-.5cm}

\sidenote{Einfachster Ansatz} Im einfachsten Ansatz initiiert jeder {\am} den Start eines Proxys, sobald er einen neuen {\trans} entdeckt (\emph{Proxy-Race}). Der Nachteil dieser Vorgehensweise ist die unnötige Beanspruchung von Ressourcen, wenn mehrere Proxy-Instanzen von unterschiedlichen {\am}n parallel gestartet werden, jedoch nur eine Instanz schließlich eine Bindung mit dem {\trans} eingehen kann. Dies ist insbesondere ein Problem, wenn mehrere {\am} gleichzeitig den Code des Proxys direkt vom eingebetteten Webserver des {\trans}s beziehen.

\sidenote{Reservierung} Um zu vermeiden, dass mehrere {\am} gleichzeitig versuchen, einen Proxy zu starten und damit unnötige Systembelastung verursachen, können die {\am} einen {\trans} {\zb} nach dem \emph{First-Come-First-Serve-Prinzip} reservieren: Ein {\am} sendet ein Signal zur Sperrung an den {\trans}, sobald er ihn entdeckt hat. Der {\am}, der sich zuerst bei dem {\trans} meldet, bekommt den Zuschlag und darf den Proxy starten. Parallel startet der {\trans} einen Timer und löst die Sperrung nach einem Timeout auf, falls sich kein Proxy meldet, um ein Pairing erneut zuzulassen.

\sidenote{Load-Balancing} Alternativ kann die Zuweisung des für den Start eines Proxys zuständigen {\am}s entsprechend der jeweiligen Situation erfolgen: So ist {\zb} eine Zuweisung in Abhängigkeit der verfügbaren Ressourcen des {\am} denkbar, um ein \emph{Load-Balancing} im System zu realisieren. Für den Aushandlungsvorgang sind \emph{Bidding-Protokolle} \cite{gu03_bidding, sc97_bidding} ein gangbarer Weg. Listing \ref{lst:Bidding-Algorithmus} zeigt den Algorithmus eines einfachen Bidding-Verfahrens in Pseudo-Code. Eine Voraussetzung ist, dass ein {\am} in der Lage ist, die verfügbaren Systemressourcen seines Hosts, wie Energiereserven, verfügbarer Arbeits- und Festspeicher, sowie aktuelle Prozessorlast, zu ermitteln (\su).

\lstinputlisting[caption=Einfacher Bidding-Algorithmus., mathescape, breaklines=true, breakatwhitespace=true, keywords={procedure, save, for, all, do, remote, call, max, min, while, if, then, else, return, wait, until, or, not}, keywordstyle=\color{black}\bfseries\underbar, basicstyle=\footnotesize, label=lst:Bidding-Algorithmus] {fig/listings/Bidding-Algorithmus}

\sidenote{Beschreibung des Algorithmus} Entsprechend dem Algorithmus sendet jeder {\am} seinen aktuellen Lastwert an alle anderen {\am}. Dieser Lastwert wird als \emph{Gebot} für die Ausführung eines {\trans}s $T$ betrachtet, wobei das Gebot mit dem geringsten Wert gewinnt. Jeder {\am} prüft, ob sein Gebot alle anderen Gebote unterbietet oder gleichwertig ist. Ist dies der Fall oder wurden keine Gebote von anderen {\am}n empfangen, sendet er eine Pairing-Anforderung an den {\trans}. Falls mehrere {\am} das gleiche Angebot abgegeben haben, so werden sie alle versuchen, den {\trans} zu reservieren. In diesem Fall greift die {\og} Regel, wonach lediglich die erste Pairing-Anforderung nach dem First-Come-First-Serve-Prinzip angenommen wird. Beobachtet der {\am} anschließend keine Bindung des {\trans}s, wird der gesamte Vorgang wiederholt.

\sidenote{Ermittlung der Last} Der aktuelle Lastwert spiegelt die Menge an verfügbaren Ressourcen auf dem Host des {\am}s wider. Diese Ressourcen sind der verfügbare Arbeits- und Festspeicher, Energiereserven, sowie die momentane Prozessorauslastung und die verfügbare Übertragungsbandbreite der Netzwerkschnittstelle. Der Lastwert sagt etwas darüber aus, wie gut ein {\am} in der Lage ist, einen weiteren Proxy auszuführen. Die Schwierigkeit ist hier, Lastwerte auf ein vergleichbares Maß zu normieren. Bei Anwendung des {\og} einfachen Aushandlungsverfahrens hat sich allerdings gezeigt, dass eine Einstufung in wenige Bereiche wie \emph{Low}, \emph{Medium} und \emph{High} ausreicht, um {\am} entsprechend ihrer Lastsituation zu klassifizieren \cite{lu96_adaptive, zh87_load}. Schließlich geht es bei den Aushandlungsverfahren im Wesentlichen darum, {\am}, die ihrer eigenen Einschätzung nach ausgelastet sind, entsprechend auszuschließen.

\sidenote{Einstufung Batteriebetriebener Geräte} Generell empfiehlt es sich, Geräte, die nicht über eine stationäre Energieversorgung verfügen, für die Ausführung von Proxies als nur \emph{bedingt geeignet} einzustufen, um Hosts mit unbeschränkten Energiereserven den Vortritt zu lassen. Als Erweiterung ist denkbar, dass limitierte Geräte die Anforderungen ihres Proxys beschreiben. So kann ein limitiertes Gerät direkt mitteilen, dass der Proxy rechenintensive Operationen ausführt und damit entsprechende Prozessorleistung verlangt.

\sidenote{Wie wird gemessen?} Die eigentliche Messung der verfügbaren Ressourcen gestaltet sich wegen der verwendeten Laufzeitumgebungen allerdings als problematisch. Der Grund liegt darin, dass Laufzeitumgebungen wie die \emph{Java Virtual Machine} oder das \emph{.Net Runtime Environment} Applikationen vom Betriebssystem abschotten und nur begrenzt Möglichkeiten bieten, den lokalen Systemstatus abzufragen. Dies trifft vor allem auf die Java Virtual Machine zu, da entsprechend der Plattformunabhängigkeit von Java die Abstraktion des darunterliegenden Systems ausgeprägter ist, als es bei der .Net Laufzeitumgebung der Fall ist. Unter Berücksichtigung dieser Einschränkungen bieten sich folgende Ansätze für die Abfrage von Systeminformationen an:

\begin{enumerate}

\item \sfb Nutzung von Monitoring-Schnittstellen der Laufzeitumgebung \normalfont\\ Die Laufzeitumgebungen bieten zum Teil Monitoring-Schnittstellen, um in begrenztem Umfang Statusinformationen der Hostplattform abzufragen.

\item \sfb Nutzung des Native Interface \normalfont\\ Sofern die Laufzeitumgebung Zugriff auf native Systembibliotheken bietet ({\zb} \emph{Java Native Interface (JNI)}), können prinzipiell sämtliche Informationen abgefragt werden, die auch vom Betriebssystem ermittelt werden können. Allerdings ist diese Lösung mit einem erhöhten Implementierungsaufwand verbunden, da native Komponenten entsprechend bereitgestellt werden müssen.

\item \sfb Nutzung impliziter Indikatoren \normalfont\\ Kommen die ersten beiden genannte Ansätze nicht in Frage, so können in manchen Fällen "`implizite Indikatoren"' verwendet werden, um auf den Status des Systems zu schließen. So kann {\zb} anhand des Zeitraums, den ein Thread vom Scheduler Rechenzeit zugewiesen bekommt, darauf geschlossen werden, wie stark das System ausgelastet ist \cite{to02_observation}.\footnote{Dies ist jedoch eine relativ ungenaue Methode, die zudem auf ein Einmessen der Last im Ruhezustand angewiesen ist.}

\end{enumerate}

% ----------------------------------------------------------------------------
\section{Bereitstellung des Proxy-Codes}
\label{sec:Bereitstellung_Proxy-Code}

\sidenote{Sindrion Descriptions} Damit der Code eines Proxys vom {\am} automatisch bezogen werden kann, müssen Informationen darüber geliefert werden, woher der Code zu beziehen ist. Dies kann {\zb} durch die Angabe eines URLs geschehen. Zu diesem Zweck wurde das Modell der UPnP Descriptions durch sog. \emph{Sindrion Descriptions} erweitert \cite{st03_sindrion}. Die Sindrion Description ist in ihrer Notation an die UPnP Descriptions angelehnt. Sie gibt an, in welchen Archiven sich die Komponenten von Proxy, Specific Control Point (SCP) und Sindrion-Applet (siehe Kapitel~\ref{sec:Einleitung}) befinden. Ein Beispiel einer Sindrion Description befindet sich in Anhang \ref{sec:Anhang_Description_Beispiele}.

\sidenote{Webserver} Die Komponenten des Proxys können zum einen vom {\trans} selbst herunter geladen werden, zum anderen ist es denkbar, dass die Description auf einen entfernten HTTP-Server (Webserver) verweist. Das Ablegen des Codes auf einem entfernten HTTP-Server würde den {\trans} entlasten, da im {\trans} kein entsprechender Speicherplatz bereitgestellt werden müsste. Hinzu kommt, dass der Download eines Proxys direkt vom {\trans} je nach Datenrate entsprechend viel Zeit in Anspruch nehmen kann: Selbst wenn die volle Bandbreite von 50 kbit/s des Sindrion-Transceivers (siehe Anhang \ref{sec:Anhang_Sindrion_Transceiver}) zur Verfügung stünde, würden immer noch knapp 20 s für den Download eines 100 kB Proxy anfallen. Bei einer Netto-Datenrate von 30 kbit/s, würden bereits knapp 30 s für den Download des Codes anfallen (siehe Abbildung~\ref{fig:Diagramm_Proxy_Downloadzeit}). Allerdings ist bei Verwendung eines entfernten HTTP-Servers Internet-Konnektivität des {\am}s erforderlich, sofern der HTTP-Server sich nicht im lokalen Netzwerk befindet.

\begin{sloppypar}

\vspace{-.5ex}\piccaption{Download-Dauer des Proxys vom Transceiver.\label{fig:Diagramm_Proxy_Downloadzeit}} \parpic[r]{\includegraphics[width=7.5cm]{fig/auswertung/Proxy_Downloadzeit.pdf}} \sidenote{Lokales Repository} Neben dem einfachen Ansatz, den Code vom HTTP-Server stets direkt in den Speicher des {\am} zu laden, wurde im Rahmen des Sindrion-Pro\-jek\-tes vorgesehen, Code in einem lokalen \emph{Code-Repository} auf jedem {\am} abzulegen und im Sinne eines Caches vorzuhalten. Somit kann der Code des Proxys {\ggf} direkt aus dem jeweilig lokalen Repository bezogen werden, anstatt ihn über die im Vergleich zum Zugriff auf das Repository schmalban\-dige Netzwerkanbindung des {\trans}s zu beziehen.

\enlargethispage{-1cm}

Jeder {\am} kann sein eigenes Repository anderen {\am}n zur Verfügung stellen. Umgekehrt können {\am}, die den Code eines Proxys nicht in ihrem lokalen Repository vorfinden, ihn {\ggf} vom Repository eines anderen {\am}s herunter laden. Um jeweils ihr lokales Repository zu exportieren, müssen die {\am} einen Service zur Veröffentlichung ihres Repositorys anbieten.

\end{sloppypar}

\noindent Der Ablauf des Beziehens von Code sieht wie in Abbildung \ref{fig:Proxy-Bezugsreihenfolge} dargestellt aus:

\begin{enumerate}

\item Ein {\am} prüft, ob der Code des Proxys bereits lokal verfügbar ist. Falls ja, lädt er ihn aus seinem eigenen Repository.

\item Ist der Code nicht lokal verfügbar, prüft der {\am} die Repositories anderer in Reichweite befindlicher {\am}.

\item Ist der Code auch dort nicht verfügbar, wird der Code vom {\trans} direkt heruntergeladen.

\end{enumerate}

\sidenote{Versionierung} Um die Möglichkeit zu schaffen, trotz einer Verteilung des Codes in den Repositories die Implementierungen von Komponenten zu pflegen, wurde im Rahmen des Sindrion-Projektes eine Versionierung eingeführt. So wird jeweils eine \emph{Haupt-} und \emph{Nebenversionsnummer} in den Sindrion Descriptions (siehe Anhang \ref{sec:Anhang_Description_Beispiele}) zu jeder einzelnen Komponente vergeben. Haben zwei Komponenten die selbe Hauptversionsnummer, jedoch unterschiedliche Nebenversionsnummern, so ist die Komponente mit der höheren Nebenversionnummer zu der anderen abwärtskompatibel. Komponenten mit unterschiedlichen Hauptversionsnummern sind nicht notwendigerweise zueinander kompatibel.

Wird der Code von einem anderen {\am} oder direkt vom {\trans} bezogen, wird er in das lokale Repository eingepflegt und mit einem Zeitstempel versehen. Vorhandene Komponenten mit gleicher Haupt- jedoch kleinerer Nebenversionsnummer werden dabei überschrieben. Vorhandene Komponenten mit unterschiedlichen Hauptversionsnummern werden entsprechend verwahrt. Jedesmal, wenn eine Code-Komponente aus dem lokalen Repository verwendet wird, wird der zugehörige Zeitstempel aktualisiert. Somit können anhand der Zeitstempel Elemente des Repositorys nach dem LRU-Verfahren\footnote{LRU: Least Recently Used} entfernt werden, um die Größe des Repositorys zu beschränken.

\vspace{.75cm}

\begin{figure}[htbp]
  \begin{center}
    \includegraphics[width=12cm,angle=0]{fig/Bezugsreihenfolge.png}
    \setzeBreite
    \caption{Bezugsreihenfolge des Proxy-Codes.}
    \label{fig:Proxy-Bezugsreihenfolge}
  \end{center}
\end{figure}

% ----------------------------------------------------------------------------
\section{Ausführen und Beenden der Proxies}
\label{sec:Ausführen_und_Beenden_der_Proxies}

\sidenote{Voraussetzungen} Sobald der Code des Proxys auf der lokalen Plattform verfügbar ist, kann er ausgeführt werden. Da ein {\am} selbst auf unterschiedlichen Betriebssystemen ausgeführt werden kann, spielt  Plattformunabhängigkeit bei der Ausführung des Proxys eine zentrale Rolle. Daher bieten sich insbesondere Laufzeitumgebungen wie die \emph{Java Virtual Machine (JVM)} oder auch die \emph{.Net Common Language Runtime} zur Ausführung von Proxies an. Ferner ist die Fähigkeit zum \emph{dynamischen Binden} von Code wichtig, wenn ein Proxy zur Laufzeit in eine bereits bestehende virtuelle Maschine geladen wird. Allgemein kann die Ausführung des Proxy-Codes auf zwei Arten erfolgen:

\enlargethispage{.5cm}

\begin{itemize}

\item \sfb Ausführung als Thread \normalfont\\ Bei einer Ausführung als Thread wird das Objekt, das die Initialisierungsmethoden des Proxys enthält, von einem \emph{Classloader} in die selbe virtuelle Maschine geladen, die auch den {\am} ausführt. Der Vorteil dieser Vorgehensweise liegt in der kurzen Startzeit des Proxys sowie im vergleichsweise geringen Ressourcenverbrauch. Allerdings birgt dieser Ansatz auch potentielle Risiken, da ein fehlerhafter Proxy bei Ausführung als Thread nicht einfach beendet werden kann.\footnote{Die Methoden \texttt{Thread.stop()} {\bzw} \texttt{Thread.abort()} zum Abbrechen laufender Threads unter Java {\bzw} .Net arbeiten unzuverlässig und gelten daher als \emph{deprecated}.}

\item \sfb Ausführung als Prozess \normalfont\\ Bei einer Ausführung als Prozess wird der Proxy in einer separaten virtuellen Maschine (VM) gestartet. Diese VM wird direkt aus der virtuellen Maschine des Application Managers heraus erzeugt und bekommt die Klassen des Proxys über einen \emph{Classpath Parameter} übergeben. Der Vorteil dieser Vorgehensweise liegt in der strikten Trennung zwischen Application Manager und Proxies. So kann der {\am} bei Bedarf den Prozess des Proxys -- im Unterschied zur oben beschriebenen Ausführung als Thread -- einfach beenden. Von Nachteil sind der erhöhte Ressourcenbedarf und die aufwendigere Interaktion mit dem Proxy, da eine Kommunikation zwischen {\am} und Proxy nunmehr über die Grenzen virtueller Maschinen, {\zb} über RPC-Mechanismen wie Java RMI erfolgen muss.

\end{itemize}

\sidenote{Startzeit} Abbildung \ref{fig:Diagramm_Proxy_Startzeit} zeigt die durchschnittlichen Startzeiten eines Proxys, der beispielhaft den Dienst eines \emph{UPnP Binary Light} bereit stellt. Wird der Proxy als Thread gestartet, so fallen durchschnittlich ca. 1,5 s Gesamtzeit für den Start an. Wie in der Abbildung dargestellt, werden ca. 0,5 s für die Anmeldung des UPnP-Dienstes benötigt. Wird der Proxy als Prozess (also in einer eigenen virtuellen Maschine) gestartet, so erhöht sich der Zeitaufwand nochmals um ca. 0,5 s für den Start der separaten VM.\footnote{Für die Messungen wurde die VM der Java Standard Edition 6 verwendet.} Hierbei wird allerdings davon ausgegangen, dass der Code der VM sich bereits im Memory-Cache der Maschine befand. Auch bzgl. des Ressourcenbedarfs zeigen sich große Unterschiede bei den beiden Startvarianten, wie in Abbildung \ref{fig:Diagramm_Proxy_RAM-Bedarf} dargestellt: Während ein Proxy, der als Thread in der virtuellen Maschine des {\am}s ausgeführt wird, lediglich rund 4 MB Arbeitsspeichder benötigt, fallen bei Ausführung in einer separaten VM über 20 MB an erforderlichem Arbeitsspeicher an.

\vspace{.5cm}

\begin{figure}[htbp]
  \begin{center}
    \subfigure[Startzeit eines Proxys.]
    {
      \label{fig:Diagramm_Proxy_Startzeit}
      \includegraphics[width=7cm]{fig/auswertung/Proxy_Startzeit.pdf}
    }
    \hspace{.25cm}
    \subfigure[Arbeitsspeicherbedarf eines Proxys.]
    {
      \label{fig:Diagramm_Proxy_RAM-Bedarf}
      \includegraphics[width=7cm]{fig/auswertung/Proxy_RAM-Bedarf.pdf}
    }
    \setzeBreite
    \caption[Startzeit und Ressourcenbedarf bei Ausführung eines Proxys.]{Startzeit und Ressourcenbedarf bei Ausführung eines Proxys als Thread und in einer separaten virtuellen Maschine.}
  \end{center}
\end{figure}

% ----------------------------------------------------------------------------
\section{Beispielablauf}
\label{sec:Beispielablauf}

Im Folgenden wird beispielhaft die Ausführung eines Proxys anhand eines Setups bestehend aus einem {\trans} und zwei {\am}n beschrieben. Dabei wird das Sindrion-System als konkretes Beispiel herangezogen. Der entsprechende Ablauf ist in Abbildung~\ref{fig:Sequenzdiagramm_Proxy_Start} illustriert.

\begin{enumerate}

\item Sobald der Sindrion-Transceiver mit Energie versorgt wird, bezieht er eine IP-Adresse über DHCP bzw. über Auto IP.

\item Der Transceiver sendet Advertisements über Multicast-Nachrichten, die von den {\am}n empfangen werden.

\item Die {\am} laden die UPnP Device Description herunter und schließen aus dem URL der Presentation Page, dass es sich bei dem entdeckten UPnP Basic Device um einen Sindrion-Transceiver handelt.

\item Jeder der beiden {\am} sendet eine Sperranforderung an den {\trans}. Der {\trans} gibt dem {\am}, der zuerst die Sperranforderung gesendet hat, den Zuschlag und teilt dem anderen {\am} mit, dass er bereits gesperrt wurde.

\item Der {\am}, der den Zuschlag bekommen hat, lädt die Sindrion Des\-crip\-tion-Datei vom Transceiver herunter und wertet sie aus. Hierdurch erfährt er, welche Dateien in welchen Versionen er zur Ausführung des Proxys beziehen muss.

\item Der {\am} sucht den Proxy-Code zuerst in seinem lokalen Code-Repository, liegt der Code dort nicht, vor fragt er bei dem anderen {\am} an, ob er den Code in seinem Repository hat. Ist das auch nicht der Fall, lädt der er den Code direkt vom Transceiver herunter.

\item Der {\am} führt den Proxy aus -- entweder als Thread oder in einer separaten Java Virtual Machine. Sobald der Proxy gestartet ist, bindet sich sich dieser mit dem Transceiver und macht sich über eigene Advertisements im System bekannt.

\end{enumerate}

\begin{figure}[htbp]
  %\hspace{-.6cm}
  \begin{center}
    \includegraphics[width=15cm,angle=0]{fig/diagramme/Sequenzdiagramm_Proxy_Start}
    \setzeBreite
    \caption{Sequenzdiagramm der Proxy-Ausführung.}
    \label{fig:Sequenzdiagramm_Proxy_Start}
  \end{center}
\end{figure}

% ----------------------------------------------------------------------------
\section{Der Sindrion {\am}}
\label{sec:Sindrion_AM}

\sidenote{Einleitung} Die in den bisherigen Abschnitten beschriebenen Konzepte und Verfahren wurden im Rahmen der vorliegenden Arbeit in der Implementierung eines {\am}s für das Sindrion-Projekt umgesetzt. Ein besonderer Wert wurde dabei auf hohe Konfigurierbarkeit sowie eine möglichst nahtlose Integration in das Betriebssystem gelegt. Im folgenden wird kurz auf einige Merkmale der entstandenen Software eingegangen. Eine detaillierte Beschreibung der Architektur des Sindrion {\am}s befindet sich in Anhang~\ref{sec:Anhang_Architektur_des_AMs}.

\sidenote{Plattform\-unterstützung} Implementiert wurde der Sindrion {\am} unter Verwendung der Java Standard Edition 6 und lässt sich damit auf gängigen Plattformen wie Microsoft Windows oder auch Linux ausführen. Neben einer Ausführung als eigenständige Applikation ist die Integration als Bundle in ein OSGi-Framework möglich. Als UPnP-Stack kam der Java-basierte \emph{Infineon UPnP/1.0}, der von Infineon Technologies zur Verfügung gestellt wurde, zum Einsatz.

\piccaption{Tray-Integration.\label{fig:Tray}} \parpic[r]{\includegraphics[width=5cm]{fig/screenshot/Tray.png}} \sidenote{Verhalten und Systemintegration} Nach dem Start läuft das Programm im Hintergrund und reagiert automatisch, sobald es {\strans} im Netzwerk entdeckt. Neben dem vollautomatischen Modus ist auch ein manueller Modus konfigurierbar. Bei Verwendung der Win\-dows-Platt\-form fügt sich der {\am} in Sys\-tem-konforme Benutzerschnittstellen wie die \emph{Systemsteuerung} oder das \emph{System Tray} ein (Abbildung \ref{fig:Tray}). Alle grafischen Benutzerschnittstellen sind, wie in Abbildung~\ref{fig:Sindrion_GUIs} dargestellt, an das \emph{Look and Feel} der Oberfläche von Windows XP angelehnt, um dem Benutzer ein vertrautes Arbeitsumfeld zu bieten. Die beiden wesentlichen GUI-Komponenten des Sindrion {\am}s sind:

\begin{itemize}

\item \sfb Der Sindrion Explorer \normalfont\\ Der Sindrion Explorer ist ein an den Windows-Explorer angelehntes Kontrollfenster, das im System vorhandene {\strans} sowie herkömmliche UPnP-Geräte anzeigt. Er erlaubt zum einen den manuellen Start von Proxies, als auch eine einfache regelbasierte Konfiguration, für welche Transceiver Proxies automatisch auszuführen sind.

\item \sfb Das Sindrion Application Center \normalfont\\ Über das Application Center lässt sich das Verhalten des Application Managers konfigurieren. Dies betrifft {\zb} die automatische Ausführung von Proxies sowie die Art der Ausführung (Thread oder Prozess). Weiterhin lässt sich über das Application Center das Code Repository des Application Managers bei Bedarf leeren.

\end{itemize}

\sidenote{Grundlage für weiteres Vor\-gehen} Die Implementierung des Sindrion {\am}s diente im Rahmen der vorliegenden Arbeit als Grundlage für weitere Untersuchungen. So wurden Messungen am realen System unter Verwendung dieser Software durchgeführt.

\vspace{1cm}

\begin{figure}[htbp]
  \begin{center}
    %\hspace{-.75cm}
    \includegraphics[width=14cm,angle=0]{fig/screenshot/Sindrion_GUIs_classic.png}
    \setzeBreite
    \caption{Grafische Sindrion-Benutzerschnittstellen.}
    \label{fig:Sindrion_GUIs}
  \end{center}
\end{figure}
