Feedbackschnittstelle
Eine weitere Funktion der Informationsauswertung ist es, eine Schnittstelle für Feedback zu bieten. Feedback kann bei Kontextdimensionen, welche ein adaptives und überwachtes Verfahren zur Auswertung benötigen, be-nutzt werden, um den Prozess zur Adaption mit neuen Angaben zu versorgen. Hierzu kann ein Nutzer über unter-schiedliche Wege Feedback geben (wie in Abschnitt 3.2.4 näher erläutert wird). Die Informationsauswertung bietet hierfür den Anknüpfungspunkt und bestimmt (je nach Instanziierung), wie das Feedback verarbeitet wird.
3.2.4 Kontextnutzung, Benutzer und Feedback
Die Anwendung, welche schließlich auf den Kontext zurück greift, wird als kontextberücksichtigende Anwendung (engl. Context-aware Application) bezeichnet. Bei den Szenarien aus Abschnitt 2.2, greift die Telefoniesoftware auf den Kontext zurück und nimmt somit die Rolle der kontextberücksichtigenden Anwendung ein. Es existieren eine Reihe weiterer Anwendungsmöglichkeiten, welche in Abschnitt 7 aufgeführt werden.
Feedback wird im Zusammenhang mit einer adaptiven, überwachten Auswertungsmethode relevant. Mit Feed-back wird die Antwort beziehungsweise die Reaktion des Benutzers auf das Resultat der Kontextbestimmung be-zeichnet. Das Feedback enthält neben der Anfrage, auf die sich das Feedback bezieht, auch das in diesem Zusam-menhang erwünschte Resultat. Somit kann das Feedback auch als ein Ausschnitt der Vorstellungen eines Benutzers betrachtet werden. Die Problematik in diesem Bereich entsteht im Zusammenhang mit der vierten Anforderung aus Abschnitt 2.3: der Minimierung des Konfigurationsaufwandes seitens des Benutzers. Feedback vom Benutzer zu benötigen, bedeutet mehr Aufwand zu erzeugen. Da das System jedoch auf Feedback angewiesen ist, sollte dieser Aufwand so gering wie möglich gehalten werden. Daher ist es ein weiteres Ziel an dieser Stelle möglichst einfach zu nutzende Schnittstellen für den Benutzer anzubieten. Je nach Zusammenhang zwischen dem Feedback und dem Nutzerkonzept, welches vom bestehenden Modell beschrieben wird, kann zwischen mehreren Arten von Feedback unterschieden werden:
• Negatives Feedback: Wenn die Entscheidung des Systems nicht dem Konzept des Benutzers entspricht, kann man mittels Feedback korrigierend auf das Modell einwirken. Dieses Feedback widerspricht somit dem Nutzerkonzept, welches von dem aktuell bestehenden Modell beschrieben wird und wird somit alsnegatives Feedbackbezeichnet.
• Positives Feedback:Entspricht das Feedback dem Nutzerkonzept, welches das bestehende Modell beschreibt, wird dies in dieser Arbeit alspositives Feedbackbezeichnet. Positives Feedback ist nicht zwangsläufig notwen-dig, um ein Modell anzupassen, es kann jedoch genutzt werden, um das Modell zu festigen.
• Falsches Feedback: Feedback, welches nicht dem eigentlichen Konzept des Benutzers entspricht, wird als falsches Feedbackbezeichnet. Falsches Feedback kann beispielsweise durch ein Versehen seitens des Benutzers entstehen, oder ebenso wenn ein automatisierter Prozess zur Erzeugung von Feedback genutzt wird. Falsches Feedback führt möglicherweise zu einem Fehlverhalten des Modells und sollte daher weitgehend vermieden werden.
Je nach Kontextdimension und Anwendung entstehen unterschiedliche Möglichkeiten, Feedback vom Benutzer zu beziehen. In einigen Bereichen ist es von Vorteil, eine solcheFeedback-Schnittstelledirekt in die Anwendung zu integrieren oder als zusätzliche Komponente auf das Endgerät zu installieren. Eine solche Komponente wird im Rahmen dieser Arbeit auch alsFeedbackagentbezeichnet.
Ein wesentliches Unterscheidungsmerkmal zwischen den Ansätzen für einen Feedbackagent ist die Art und der Zeitpunkt der Generierung des Feedbacks (siehe auch Abschnitt 3.2.4). Wird das Feedback aus einer bestimmten Si-tuation heraus gegeben (Implizites Feedback), können direkt die Merkmale, die diese SiSi-tuation beschreiben genutzt werden. Wird das Feedback erst im Nachhinein gegeben, so bezieht sich das Feedback auf Merkmale einer zeitlich zurückliegenden Situation (Explizites Feedback). Für das explizite Feedback müssen die Merkmale zurückliegender Entscheidungen in einer Historie gehalten und für den Benutzer zur Entscheidungsfindung einsehbar sein. Diese Variante erfordert jedoch deutlich mehr Aufwand und eine Oberfläche, über die es dem Benutzer möglichst einfach gemacht wird, die Merkmale der jeweiligen Situation zu betrachten und selbst eine Entscheidung zu treffen.
arbeitung von Informationsquellen häufig auf derjenigen Plattform integriert werden, auf der diese Information verfügbar ist. Ein Feedbackagent sollte so umgesetzt werden, dass es dem Benutzer möglichst einfach ist, Feedback zu geben. Dies bedeutet das ein Feedbackagent idealerweise auch für Endgeräte angepasst und umgesetzt wird, welche der Benutzer mit sich führt.
Wiederum andere Komponenten, wie beispielsweise solche zur Registrierung und Suche über Informationsquel-len, müssen derart integriert werden, dass sie Zugang zu den Informationsquellen haben (beispielsweise sich im gleichen lokalen Netz befinden). Komponenten zur Auswertung und Nutzung von Informationen können dagegen auf zentralen Systemen zum Einsatz kommen.
Daher muss die Architektur die Umsetzung der jeweiligen Komponenten auf den benötigten Plattformen und die Kommunikation zwischen den Komponenten ermöglichen.
Sensoren als Dienste
Es gibt zwei grundlegende Möglichkeiten externe Elemente unterschiedlicher Art in ein System zu integrieren.
Entweder das System erhält die Fähigkeit mit jedem einzelnen Element zu kommunizieren, wozu möglicherweise eine Vielzahl von Varianten der Kommunikation umgesetzt werden müssen, oder beide nutzen eine einheitliche Schnittstelle zur Kommunikation. Die zweite Variante verspricht letztlich einen flexibleren Einsatz, da nachträglich auch weitere Arten von Sensoren angebunden werden können.
Der Ansatz einer einheitlichen Schnittstelle zur Anbindung eines Elements in einen Gesamtprozess, findet sich ebenfalls im Bereich der Netzdienste wieder. Sensoren können prinzipiell als Dienste betrachtet werden. Im Unter-schied zu dem normalen Verständnis eines Netzdienstes, führen Sensoren jedoch im Allgemeinen keine (komple-xen) Operationen durch, sondern liefern lediglich auf Anfrage Zustandsinformationen oder bilden Eingabeparame-ter auf AusgabeparameEingabeparame-ter ab. Die einfache Beschaffenheit eines Sensor-Dienstes führt im Vergleich zu normalen Netzdiensten zu einer Vereinfachung der Beschreibung der Schnittstelle und deren Funktionalitäten. Durch diese Eigenschaft werden Mechanismen im Bereich der Auffindung relevanter Sensoren möglich, welche im Bereich der Suche nach relevanten Netzdiensten nicht geeignet sind (siehe Abschnitt 4.6.2). Um bereits existierende Informati-onsquellen zu integrieren, müssen diese gegebenenfalls gekapselt und/oder um die entsprechenden Schnittstellen und deren Beschreibung erweitert werden.
Dienstorientierte Architektur
Die einzelnen Aufgabenbereiche des angestrebten Systems lassen sich gut voneinander trennen. Eine Einteilung und Umsetzung dieser Aufgabenbereiche in Form von Diensten ermöglicht es, ein komplexes System in einzelne Komponenten mit dedizierten Aufgaben und Rollen zu unterteilen. Diese Aufteilung in einzelne Komponenten wiederum bietet ebenso den Vorteil, klare Schnittstellen zwischen den einzelnen Diensten zu erhalten.
Eine dienstorientierte Architektur (Service-oriented-Architecture - SoA) hat auch einen erheblichen Einfluss auf die Skalierbarkeit eines Systems. In einer solchen Architektur können Dienste auf unterschiedlichen Plattformen untergebracht oder repliziert werden, um Lasten und Aufgaben zu verteilen. Eine dienstorientierte Architektur kommt somit den Anforderungen (5) und (6) aus Abschnitt 2.3 (Minimierung der Kostenundoffenes System) ent-gegen.
Plattform
Wie zu Beginn dieses Abschnittes erläutert, ist ein Ziel der Architektur auf möglichst unterschiedlichen Syste-men zum Einsatz zu komSyste-men. Um bei möglichst vielen SysteSyste-men auf denselben Programmcode zurückgreifen zu können, bieten sich vor allem plattformunabhängige Programmiersprachen an, welche in der Regel auf der jewei-ligen Plattform durch einen Interpreter ausgeführt werden. In diesem Bereich ist Java (neben Alternativen wie beispielsweise Ruby oder Python) eine sehr weit entwickelte Programmiersprache mit vielen Funktionalitäten.
Mittels Java Anwendungen können neben Computern auch eine Reihe von einfacheren Plattformen adressiert werden. Java Code kann inzwischen auch auf vielen Routern, Smartphones oder leistungsfähigen Sensorplattfor-men genutzt werden. Für PlattforSensorplattfor-men auf denen die Ausführung von Java Code nicht möglichen ist, muss die Möglichkeit bestehen, ebenso an das System angebunden zu werden. Dieses Problem kann über einen Ansatz zur einheitlichen, plattformübergreifenden Form der Kommunikation adressiert werden.
Middleware
Das Gesamtsystem hat zum einen die Aufgabe eine Plattform zu bieten, die es ermöglicht, Informationsquellen aller Art auf einer einheitlichen Ebene zu adressieren und zu nutzen. Auf dieser Ebene sollen zum anderen Dienste verschiedenster Art diese Informationen auswerten und nutzen können. Eine solche Plattform kann auch als
Midd-34 3.3 Architekturelemente
leware bezeichnet werden. In Abbildung 3.4 ist allgemein dargestellt, was unter einer Middleware zu verstehen ist.
Anwendung
Middleware
Betriebssystem
Hardware Physical
Data Link Network Transport
Session Presentation
Application
Generische Architektur ISO-OSI
Referenz-Modell
Kontextnutzung
Informationsgewinnung Middleware zur Kontextnutzung Kontextberücksichtigende
Anwendung
Windows / Linux / TinyOS / WindowsMobile / ...
PCs / Mobiltelefone / Eingebettete Systeme /
Sensoren / ...
Komm. zwischen Diensten
Abbildung 3.4:Middleware - Einordnung der gewählten Architektur
Auf der linken Seite der Darstellung ist das ISO-OSI Referenz-Modell aufgezeigt [SN04]. Die Form Middlewa-re, wie sie in dieser Arbeit betrachtet wird, kann auf den Ebenen Sessionund Presentation des ISO-OSI Modells eingeordnet werden. Die Middleware bildet eine Ebene zwischen Anwendung und dem unterliegenden System (wie im mittleren Teil der Darstellung gezeigt wird). Somit bietet eine Middleware eine einheitliche Schnittstelle zur Kommunikation zwischen verschiedenen Anwendungen. In der Literatur werden eine Reihe von Ansätzen für Middleware aufgezeigt [MCE02]. Da der Begriff Middleware relativ vielseitig belegt ist, wird im Folgenden die in dieser Arbeit angestrebte Form der Middleware genauer beschrieben.
Je nach Ebene in welcher das Gesamtsystem betrachtet wird, kann das System mit einer der folgenden Kategorien für Middleware beschrieben werden (siehe rechte Seite der Abbildung):
• Kommunikations-Middleware: Auf der Ebene derInformationsgewinnunggeht es um die Verbreitung von Zuständen von Sensoren. Hier muss eine Kommunikation über verschiedene Plattformen hinweg möglich sein. Auf dieser Ebene können auch weiter reichende Ansätze wie Nachrichten- oder Ereignisbasierte Midd-leware oder verteilte Datenbanken zum Einsatz kommen.
• Objektorientierte Middleware: Auf der Ebene der Dienste geht es um die Bereitstellung von Funktionen wie beispielsweise dem Sensorverzeichnis. DieKommunikation zwischen den verteilten Dienstensoll möglichst einfach und transparent möglich sein. Hierzu können entfernte Dienste als (Proxy-) Objekte im lokalen System eingebunden werden.
• Kontextbasierte Middleware: Auf der Ebene der Kontextnutzung geht es darum den Anwendungen eine allgemein nutzbare Schnittstelle zur Integration des Kontextes in den Programmablauf zu ermöglichen. In vielen dieser Ansätze wird mit dem BegriffKontextjedoch meist nur die Menge erfasster oder gegebenenfalls aggregierter Kontextinformationen bezeichnet. Eine Klassifizierung in höherwertige Kontextklassen, wie sie in dieser Arbeit angestrebt wird, zählt meist nicht zu den Funktionen einer solchen Middleware.
Kommunikation
Das Anwendungsszenario (wie in Abschnitt 2.2 beschrieben) erfordert, dass die Kommunikation zwischen un-terschiedlichen Diensten und Sensoren auch über heterogene Netzwerke und Systeme hinweg möglich ist. Es gibt eine Reihe von Ansätzen, um unterschiedliche Dienste miteinander zu verbinden. Hierzu zählen zum einen An-sätze, welche Kommunikations-Middleware nutzen. Zum anderen können sich die unterschiedlichen Dienste auch eine gemeinsame Sprache zum Informationsaustausch nutzen. Die zentrale Eigenschaft aller Ansätze ist, dass die Dienste eine Schnittstelle geboten bekommen, über welche sie transparentmiteinander kommunizieren können.
3 Konzept und Architektur 35
Eine transparente Kommunikation zwischen Diensten bedeutet, dass Dienste nur eine abstrahierte Sicht auf die darunter liegende Kommunikation erhalten und auf entfernte Dienste wie auf lokale Objekte zugreifen können.
Konnektor
Ein Architekturelement, welches eine transparente Kommunikation zwischen Diensten ermöglicht ist ein soge-nannter Konnektor. Ein Konnektor bildet eine Abstraktionsschicht zwischen dem Dienst und der Kommunikation.
Hierzu bietet ein Konnektor auf der Seite der Dienste eine einheitliche Schnittstelle zur Kommunikation zwischen den Diensten.
Je nach Bedarf oder zugrunde liegendem System und Netzwerk können unterschiedliche Konnektoren eingesetzt werden. Ob ein Konnektor dabei auf eine Middleware zurück greift oder eine gemeinsame Sprache zum Informa-tionsaustausch nutzt, ist für den Dienst, welcher ihn verwendet, nicht relevant. Details zu der Anwendung und Umsetzung von Konnektoren finden sich in Abschnitt 6.1.1.
Auffindung von Diensten
Ziel der Auffindung von Dienstes ist es, möglichst ohne konkretes Vorwissen andere Dienste zu lokalisieren. In der Regel liefert die Lokalisation eines Dienstes eine eindeutige Adresse zurück, über welche der Dienst angesprochen werden kann. Als Format für solche Adressen kommen häufigUniform Resource Identifier(URI) zum Einsatz.
Es gibt in der Regel zwei grundsätzliche Varianten, wie Dienste lokalisiert werden. Entweder ein Dienst registriert sich bei einer vorab bekannten, zentralen Instanz (Vermittler, Broker, Registrar) oder es wird im Netzwerk nach dem jeweiligen Dienst gesucht. Eine solche Suche kann sich unterschiedlich gestalten. Neben einigen Ansätzen für die Suche innerhalb von Peer-to-Peer Systemen werden von der suchenden Instanz in der Regel Broad- oder Multicastnachrichten im Netzwerk versendet, worauf die betreffenden Dienste antworten.
Die Peer-to-Peer basierten Ansätze, sind zwar prinzipiell geeignet, wurden jedoch bisher, unter anderem wegen dem angestrebten Einsatz innerhalb von Unternehmen ausgelassen. Unternehmensnetze bieten meist eine in der Größe limitierte und relativ feste Infrastruktur, was den Einsatz zentralisierter Ansätze vereinfacht. Der Einsatz einer vermittlerbasierten Auffindung von Diensten eignet sich gerade in Bereichen in denen Dienste angebunden werden sollen, welche sich außerhalb derReichweitevon Broad- oder Multicastnachrichten befinden, wie beispiels-weise außerhalb eines lokalen Netzwerkes. Andererseits bieten Systeme, welche die lokal verfügbaren Dienste auffinden, die Möglichkeit der Nutzung von Diensten, ohne das Vorwissen der Adresse eines Vermittlers. Dieses er-höht den Komfort und minimiert den Aufwand der Einrichtung eines Systems und kommt somit der Anforderungen zur Aufwandsminimierung aus Abschnitt 2.3 entgegen. Wie diese Aufgabe im Rahmen dieser Arbeit angegangen wird, ist in Abschnitt 4.2.2 beschrieben.
Beschreibung
Aus Abschnitt 2.3 geht hervor, dass bei der Informationsgewinnung auf externe Informationsquellen zurückge-griffen werden soll, ohne vorab deren Schnittstellen zu kennen. Hierdurch ist es möglich, ein offenes System zu bieten, um auch zur Laufzeit noch neue, unbekannte Sensoren hinzufügen zu können. Hierdurch entstehen aber zusätzliche Aufgaben:
• Schnittstellen: Methoden des Sensors müssen bestimmt werden können.
• Relevanz: Zugehörigkeit eines Sensors ist relevant, um zu bestimmen, für welche Anfragen ein Sensor herangezogen wird.
• Datentyp: Die Daten, welche der Sensor liefert müssen klassifiziert werden, um sie zu geeignet (ihrer Bedeutung nach) zu verarbeiten.
• Metainformationen: Weitere Informationen, beispielsweise über die Gültigkeit oder Genauigkeit des Sen-sorwertes können helfen, die Informationen optimal zu nutzen.
Die Beschreibung eines Dienstes oder eines Sensor nutzt hierzu folgende Komponenten:
• Beschreibung der Schnittstellen: Die Beschreibung der Schnittstelle ist notwendig, um dem Anfragen Dienst die Möglichkeit zu bieten zu ermitteln, über welche Funktionen und Methoden ein anderer Dienst oder Sensor verfügt, ohne ihn zu vorab zu kennen. Die Beschreibung der Schnittstellen listet die verfügbaren Methoden, sowie deren Ein- und Ausgabeparameter auf. Aus technischer Sicht reichen diese Informationen aus, um eine Anfrage an den entfernten Dienst zu stellen. Es existiert eine Reihe von Ansätzen aus dem Bereich derWebservices, welche sich hierfür anbieten1.
1 http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626/
36 3.3 Architekturelemente
• Semantische Beschreibungsmerkmale: Die Beschreibung der Schnittstelle reicht nicht aus, um zu ent-scheiden, für welche Anfrage ein Sensor relevante Informationen anbietet. Ebenso geht aus einer einfachen Beschreibung der Schnittstellen nicht hervor, wie ein Rückgabeparameter zu interpretieren ist oder welche Informationen als Eingabeparameter geeignet sind. Hierzu werden zusätzliche Informationen benötigt, wel-che Rückschlüsse auf die Relevanz eines Sensors und die Bedeutung der Daten ermögliwel-chen - sogenannte semantische Beschreibungsmerkmale.
• Ontologien: Ontologien ermöglichen es Beziehungen zwischen Elementen zu definieren. Setzt man sie in Kombination mit semantischen Beschreibungsmerkmalen ein, bieten sie die Möglichkeit Dienste und deren Daten zueinander in Relation zu stellen. Hierzu verweisen semantische Beschreibungsmerkmale in der Regel auf Elemente innerhalb einer Ontologie. Innerhalb einer Ontologie werden Beziehungen häufig in Form einer Subjekt-Prädikat-Objekt Beziehung dargestellt. Durch Verknüpfung vieler solcher Subjekt-Prädikat-Objekt Beziehungen lassen sich komplexe Beziehungsstrukturen abbilden. Solche Strukturen können je nach Um-setzung beispielsweise Baumstrukturen oder gerichtete Graphen ergeben.
• Weitere Meta-Informationen:Neben den Beschreibungselementen zur Bestimmung der Bedeutung des Sen-sors oder seiner Daten, werden Informationen benötigt, um die Verarbeitungsweise zu definieren. Beispiels-weise kann je nach Sensor die Gültigkeit, die Genauigkeit, die Auflösung oder das Format der Daten variie-ren. Diese Informationen werden benötigt, um Elemente wie Puffer, Vorverarbeitung oder Konvertierung zu steuern.
3.4 Qualitätsbetrachtungen