Forschungsbericht. Projekt BAMOS. Prof. Dr. Ralf Bruns. Fachhochschule Hannover

Transkript

1 Projekt BAMOS Forschungsbericht Prof. Dr. Ralf Bruns Fachhochschule Hannover Fachhochschule Hannover Fachbereich Informatik Ricklinger Stadtweg Hannover Tel.: (0511)

2 Vorwort Dieser Bericht beschreibt das Forschungsprojekt BAMOS (Basisarchitektur für mobile Anwendungen in spontanen Netzen), das am Fachbereich Informatik der Fachhochschule Hannover unter der Leitung von Prof. Dr. Jürgen Dunkel und Prof. Dr. Ralf Bruns durchgeführt wurde. Als Industriepartner war die Firma nepatec GmbH (Hannover) am Projekt beteiligt. Das Projektvorhaben wurde mit Fördermitteln der Arbeitsgruppe Innovative Projekte (AGIP) beim Ministerium für Wissenschaft und Kultur des Landes Niedersachsen unterstützt (F.A.- Nr ). Wesentliche Arbeiten in diesem Projekt entstanden während des Forschungssemesters von Prof. Dr. R. Bruns, das durch die Forschungskommission der Fachhochschule Hannover im Sommersemester 2005 befürwortet wurde. Forschungsbericht BAMOS - 2 -

3 Inhaltsverzeichnis 1. Projektkontext Projektergebnisse Basisarchitektur Überblick Service-Beschreibungen...6 Spezifikation der Benutzungsoberfläche mit XForms...7 Aufbau von XForms Ablaufbeschreibungen Generierung mobiler Anwendungen mittels MDA Modellierung...10 Das Metamodell...10 Modellierung der Abläufe...11 Modellierung von Views and Interaktionen Generierung Anwendungsszenario Hardware und Software-Infrastruktur Beschreibung des Szenario Erzielte Ergebnisse Veröffentlichungen Vorträge Beiträge in Zeitschriften und Konferenzen Bachelor-Arbeit...22 Forschungsbericht BAMOS - 3 -

4 1. Projektkontext Sowohl der Verbreitungsgrad als auch die technische Leistungsfähigkeit mobiler Endgeräte (z.b. Personal Digital Assistants, Smartphones, Mobiltelefone) haben innerhalb weniger Jahre eine rasante Entwicklungsdynamik gezeigt. Im Gegensatz dazu weist die Entwicklung mobiler Anwendungen für diese Geräteklasse nach wie vor zahlreiche Defizite auf und stellt die professionelle Software-Entwicklung vor neue Herausforderungen. Heutzutage sind mobile Geräte allgegenwärtig und unterliegen einer quasi permanenten Verfügbarkeit. Die Leistungsfähigkeit der Geräte ist inzwischen so hoch, dass sie neben ihren Standardfunktionen wie Telefonieren und Kalenderverwaltung enormes Potential für fortgeschrittene Anwendungen aufweisen. Die Verbindungsfähigkeiten in lokale Netze über Bluetooth oder WLAN ermöglichen eine ganz neue Verwendungsart für mobile Geräte. Eine neue Qualität von mobilen Informationsdiensten eröffnet sich mobilen Geräten durch die technischen Möglichkeiten der spontanen Vernetzung. Bei einer spontanen Vernetzung können sich mobile Endgeräte einen in Reichweite liegenden Zugriffspunkt suchen, um sich in ein lokales Netz einzubinden. Die Datenübertragung erfolgt hierbei drahtlos. Eine spontane Vernetzung ermöglicht das Anbieten lokaler und damit orts- bzw. situationsgerechter Informationsdienste, bspw. Fahrplanauskünfte oder lokale Veranstaltungshinweise. Darüber hinaus können die im gesamten World Wide Web verfügbaren Dienste genutzt werden. Insgesamt wäre es wünschenswert, mobile Geräte in verschiedensten Umgebungen nutzen zu können, um lokalisierte Dienste in Anspruch zu nehmen. Im Rahmen des Projekts Bamos (Basisarchitektur für mobile Anwendungen in spontanen Netzen) wurde eine Basisarchitektur für mobile Anwendungen in spontanen Netzen konzipiert und prototypisch realisiert. Das Projekt wurde in enger Kooperation des Fachbereichs Informatik der Fachhochschule Hannover mit dem Industriepartner nepatec GmbH (Hannover) durchgeführt. Die Basisarchitektur unterstützt die Entwicklung von mobilen Anwendungen durch die Bereitstellung von Software-Komponenten, die die folgenden Anforderungen und Aufgaben realisieren: Plattformunabhängigkeit Die Entwicklung professioneller Software für Mobilgeräte ist geprägt durch fehlende bzw. nichtkompatible Standards, konkurrierende Hardware- und Betriebssystemplattformen und unterschiedliche Übertragungstechnologien wie Bluetooth, Wireless LAN, GPRS und UMTS. Die BAMOS-Plattform kapselt spezielle Details der software- und hardwaretechnischen Eigenschaften der mobilen Plattform sowie der drahtlosen Kommunikation transparent und stellt standardisierte Schnittstellen bereit. Der Software- Entwickler kann sich somit auf die fachlichen Fragestellungen konzentrieren, ohne sich mit den technischen Besonderheiten der mobilen Plattform auseinandersetzen zu müssen. Spontane Vernetzung Die mobilen Geräte sind in der Lage, einen in Reichweite liegenden Netz-Zugriffspunkt zu finden, und sich über diesen in ein lokales Netz einzubinden (Verbindungsaufbau). Die Datenübertragung erfolgt stets drahtlos und bietet mithilfe von Technologien wie Bluetooth oder Wireless LAN einen kostenfreien Zugriff mit hohen Übertragungsraten. In der Regel sind dem Endgerät das genutzte Netz sowie dessen Topologie und auch die angebotenen Dienste nicht bekannt. Deshalb spricht man von spontaner oder adhoc- Vernetzung (Spontaneous Networking). Lokalisieren von Diensten Nach erfolgreicher Einbindung in ein unbekanntes Netz kann das Mobilgerät alle angebotenen Dienste auffinden und anzeigen (Service Detection). Somit kann der Benutzer einen gewünschten Dienst auswählen. Verändert sich die lokale Umgebung, i.d.r. durch Veränderung des Standortes des mobilen Gerätes, melden sich Forschungsbericht BAMOS - 4 -

5 neuverfügbare Dienste automatisch beim mobilen Geräte an, während sich nicht mehr verfügbare Dienste abmelden. Zugriff auf Dienste Nach Auswahl eines Dienstes wird auf dem Mobilgerät eine an den ausgewählten Dienst angepasste Benutzerschnittstelle generiert, die es ermöglicht Daten für den genutzten Dienst einzugeben, diesen auszuführen und dessen Ergebnisse anzuzeigen (Service Execution). Anbieten von Diensten Damit einem Mobilgerät die Interaktion mit einem unbekannten Dienst möglich ist, wurde eine standardisierte Beschreibung eines Dienstes entwickelt (Service Deployment). Diese Beschreibung umfasst alle Informationen, die das mobile Gerät benötigt, um den Dienst anzubieten. Dazu gehört eine genaue Spezifikation des angebotenen Dienstes, sowie eine Beschreibung der Benutzungsoberfläche und des Dialogablaufs. 2. Projektergebnisse Die im Projekt entwickelte Basisarchitektur unterstützt die Entwicklung mobiler Anwendungen durch die Bereitstellung von zwei Software-Komponenten. Die eine Komponente ist ein Adhoc-Client, der vergleichbar mit einem Internet-Browser jedem mobilen Endgerät den Zugriff auf beliebige Informationsdienste in spontanen Netzen ermöglicht. Die andere Komponente ist ein Service Broker, der vergleichbar mit einem Web-Server in jedem spontanen Netz als Schnittstelle zwischen dem Adhoc-Client und den lokalen Diensten bzw. Web Services fungiert. Die BAMOS-Plattform ermöglicht es mobilen Geräten, verschiedenste unbekannte Dienste in unterschiedlichen lokalen Netzen zu nutzen. Der Adhoc-Client auf dem mobilen Gerät ist generisch konzipiert und besitzt keinerlei Informationen über spezifische Dienste. Die Dienste (bzw. ihre Beschreibungen) werden vom Adhoc-Client zur Laufzeit nachgeladen und dann dem Benutzer grafisch-aufbereitet präsentiert. Die Basis für dieses generische Konzept bildet die Beschreibung des Dialogablauf und der grafischen Präsentation für einen Dienst Basisarchitektur Überblick Das Projekt BAMOS hat eine Software-Architektur entworfen und entwickelt, in der mobile Geräte beliebige ortsgebundene Dienste nutzen können (siehe Abbildung 1). In dieser Architektur gibt es drei Hauptkomponenten, die unterschiedliche Aufgaben wahrnehmen: 1. Adhoc-Client Der Adhoc-Client läuft als Java-Anwendung auf dem mobilen Endgerät und hat die Aufgabe, die verfügbaren Dienste für den Benutzer zu visualisieren und mit dem Service Broker über das drahtlose Netz zu kommunizieren. Technologisch wurde der Adhoc- Client mit J2ME (Java 2 Micro Edition) und MIDP 2.0 (Mobile Information Device Profile) implementiert. Die Komponente verwaltet die verfügbaren lokalen drahtlosen Netzwerke und verbindet sich spontan mit gefundenen Service Brokern. Dies geschieht unabhängig von der eingesetzten Übertragungstechnologie (Bluetooth, Wireless LAN, GPRS und UMTS). Im Rahmen des Projekts wurde zunächst der Verbindungsaufbau über Bluetooth implementiert. Der Adhoc-Client identifiziert alle in seiner lokalen Umgebung angebotenen Dienste (Service Detection) und lädt die Dienste vom Service Broker. Mittels einer dynamisch generierten Benutzungsoberfläche werden die geladenen Dienste dargestellt und die Interaktion mit den Diensten ermöglicht (Service Execution). Nachdem der Benutzer Forschungsbericht BAMOS - 5 -

6 Service-Anfragen spezifiziert hat, liest der Adhoc-Client diese Eingaben aus und schickt diese an den Service Broker zurück. Service Detection Adhoc Client Connect Load Service Service Broker Service Call Register Service Service Provider local service or Web Service Wireless Adhoc Network Wired Network (local and/or Internet) Service- Directory Abbildung 1: BAMOS-Basisarchitektur 2. Service Broker Der Service Broker ist der Mittelpunkt der BAMOS-Architektur. Er bietet selbst keine Dienste an, sondern unterhält ein Service-Repository mit Beschreibungen von allen verfügbaren Diensten und agiert als Vermittler zwischen Adhoc-Client und den unterschiedlichen Service Providern. Alle verfügbaren Dienste wurden von den Service Providern am Service Broker registriert. Da der Service Broker einen Zugang aus dem drahtlosen Netz bietet, kann der Adhoc-Client mit dem Service Broker eine temporäre Verbindung aufbauen. Der Broker liest das Service-Repository aus und präsentiert dem Adhoc-Client die verfügbaren Dienste. Anhand einer Ablaufsteuerung sorgt er für die korrekte Ausführung der Dienste. Dafür nimmt er die Anfragen des Adhoc-Clients entgegen, leitet diese an den Service Provider weiter, wählt die Bildschirmansicht für den nächsten Dialogschritt und schickt die Antwortparameter des Service Providers zusammen mit der Beschreibung der Bildschirmansicht an den Client zurück. Der Service Broker bildet das Bindeglied zwischen drahtlosem und drahtgebundenem Netz (mit unterschiedlichen Netztechnologien). Der Service Broker enthält ein Verzeichnis (Service Directory) zum Publizieren und Auffinden der fachlichen Dienste, die durch eine XML-basierte Beschreibungssprache komplett beschrieben werden (Service Deployment). Der Service Broker liefert alle erforderlichen technischen Informationen damit der Adhoc-Client eine service-spezifische Benutzerschnittstelle erzeugen kann. Er leitet Anforderungen des Adhoc-Clients an fachliche Services weiter und bereitet die Antworten für den Client auf. Die grundlegende technologische Entwurfsentscheidung fiel mit der Wahl des W3C-Standards XForms als Service- Beschreibungssprache und Nachrichtenformat für die Kommunikation. 3. Service Provider Ein Service Provider bietet fachliche Dienste an und steht gemeinsam mit dem Service Broker in einem drahtgebundenen Netz. Damit die Dienste auch von mobilen Geräten genutzt werden können, registriert der Service Provider diese beim Service Broker. Dies können einerseits ortsbezogene Dienste sein, andererseits öffentliche Dienste aus dem World Wide Web (z.b. Web Services). Danach steht er für Anfragen des Service Broker (weitergeleitet von den Adhoc-Clients) bereit Service-Beschreibungen Die von einem mobilen Endgerät genutzten und auf dem Service Broker abgelegten Dienste müssen so beschrieben werden, dass: Forschungsbericht BAMOS - 6 -

7 1. aus der Beschreibung auf dem mobilen Endgerät eine passende Benutzungsoberfläche dynamisch generiert werden kann und 2. die zur Dienstnutzung erforderlichen Interaktionen festgelegt sind (Ablaufsteuerung). Die Ablaufbeschreibung eines Dienstes verbleibt auf dem Server und wird von einer Ablaufsteuerung interpretiert. Diese Ablaufsteuerung wählt die passende Ablaufbeschreibung aus. Diese Beschreibung definiert die Abfolge von Dialogschritten, in der der Benutzer mit dem Dienst interagieren kann und bestimmt den jeweils nächsten Dialogschritt. Der Vorteil bei diesem Ansatz liegt darin, dass keine Änderungen auf dem mobilen Gerät vorgenommen werden müssen, wenn neue Dienste aufkommen oder sich bekannte Dienste ändern. Eine XML-basierte Spezifikation von Oberflächen und Abläufen bietet sich an, weil sie gut zur Laufzeit eingelesen und daraus dann vom Adhoc-Client eine entsprechende Anwendung erzeugt werden kann. Allerdings verbleibt das Problem, die komplexen XML-Beschreibungen für Ablauf und Oberfläche zu erstellen. Hier können aber generative Ansätze wie die OMG/Model Driven Architecture (MDA) Abhilfe schaffen: Auf Basis von UML-Modellen werden MDA-Werkzeuge benutzt, um die sehr abstrakten XML-Beschreibungen zu generieren. Mit diesem Ansatz lässt sich die mobile Applikationen modellieren und anschließend fast vollständig generieren, d.h. es muss kein Code geschrieben werden, um neue Dienste anzubinden. Spezifikation der Benutzungsoberfläche mit XForms Der Adhoc-Client ist unabhängig von jeglicher Fachlichkeit konzipiert, muss aber dennoch die Interaktion des Benutzers mit fachlichen Diensten ermöglichen. Dafür benötigt der Client eine Beschreibung der Benutzungsoberflächen für einen fachlichen Dienst, mit denen der Benutzer interagieren kann. Diese Oberflächenbeschreibungen stellt der Service Broker zur Verfügung und der Client kann darauf zugreifen. Die grundlegende technologische Entwurfsentscheidung fiel mit der Wahl des W3C-Standards XForms als Service- Beschreibungssprache und Nachrichtenformat für die Kommunikation. Der Vorteil von XForms liegt in der Korrelation zu MIDP, unserer Basistechnologie für die Implementierung des Adhoc-Clients. Die ursprüngliche Intention von XForms-Formularen ist es, in Zukunft die heute üblichen Web-Formulare in XHTML zu ersetzen. XForms ist eine XML-Sprache und bietet den klassischen XHTML-Formularen gegenüber eine Reihe von Neuerungen (s.u.). Da XForms als W3C Recommendation vorliegt, können wir auf einen offenen Standard aufsetzen, der auch in Zukunft relevant sein wird. Das J2ME-Profil MIDP ermöglicht es dem Entwickler, eine relativ simpel strukturierte Benutzungsoberflächen zu schreiben, welche mit einfachen Eingabe- und Interaktionsmöglichkeiten auskommen. XForms kann MIDP-Elemente, wie z.b. Input-Felder und andere MIDP-Konstrukte, sehr gut abbilden. Es fällt auf, dass eine MIDP- Oberfläche einem Web-Formular sehr ähnelt: Elemente wie Eingabefelder, Radio-Buttons oder Listen bieten ähnliche Eingabemöglichkeiten. Auch die Interaktionsmöglichkeiten des Benutzers sind in vielen Anwendungsfällen wie in Web-Formularen auf die Bestätigung ( Submission ) der gemachten Eingaben beschränkt. Deshalb bietet sich die Benutzung von XForms an. Aufbau von XForms Im Gegensatz zu einem herkömmlichen XHTML-Formular erfolgt in einem XForms- Dokument eine Trennung von Model und View. Es besteht daher aus zwei Teilen: Innerhalb des model-tags befindet sich die eigentliche Information, die dem Benutzer angezeigt wird und deren Inhalt er ändern kann. Diese Modellinformation kann aus beliebigem XML bestehen. In dem einfachen Beispiel in Abbildung 2 enthält es Angaben zu Vor- und Nachname einer Person. Im submission-tag steht, was mit dem Modell passieren soll, Forschungsbericht BAMOS - 7 -

8 wenn es ausgefüllt und abgeschickt wird. Den Einsatz von mehreren Modellen in einem Dokument sieht XForms ebenfalls vor. Neben dem Modell spezifizieren weitere Elemente die Präsentation des Modells und die Interaktionsmöglichkeiten mit diesem. Dazu bietet XForms eine Reihe von Ein- und Ausgabeelementen, die im Wesentlichen denen aus herkömmlichen Web-Formularen gleichen, wenn sie auch anders notiert werden. Über XPath-Ausdrücke in den ref-attributen verweist jede Darstellungskomponente auf sein Element aus dem Modell. Im Beispiel ermöglichen zwei Eingabefelder die Ansicht und Anpassung der Angaben zu Vor- und Nachnamen der Person. Das submit-element spezifiziert den View für eine Submission aus dem Modell, welche typischerweise über einen Button dargestellt wird, im Beispiel trägt dieser die Aufschrift Absenden. Drückt ein Benutzer auf den Knopf und löst damit ein Submit aus, werden seine Eingaben an die entsprechenden Stellen in das Modell eingefügt und dieses Modell (alles was innerhalb des instance-tags steht) anhand der Angaben im submission-tag verarbeitet. Im typischen Einsatz im Web-Umfeld schickt der Browser das Modell an einen Web-Server. Innerhalb unseres Einsatzfeldes wird das ausgefüllte Modell aber an den Service Broker, z.b. über Bluetooth, übertragen. Abbildung 2: Aufbau eines XForms-Dokuments 2.3 Ablaufbeschreibungen Neben der Beschreibung der Oberflächen in XForms muss der Service Broker wissen, welche XForms-Dokumente auf welche Submits folgen, d.h. die Abfolge der Dialogschritte, und wie die Service Provider einzubinden sind. Dafür existiert im Service Broker eine Ablaufsteuerungskomponente, welche anhand einer Ablaufbeschreibung arbeitet. Auf Grundlage dieser Ablaufbeschreibung nimmt die Ablaufsteuerung eine XForms-Submission entgegen, identifiziert anhand dessen den auszuführenden Dienst, extrahiert die Parameter für die fachliche Funktion aus den übertragenen Daten und ruft den Service Provider auf. Das darauf folgende XForms-Template wird bestimmt und, mit den Ausgaben der fachlichen Funktion gefüllt, an die View-Komponente zurückgegeben. Diese parst das neue XForms- Dokument und stellt es dar. Für die Beschreibung des Prozesses wurde eine einfache XML-Sprache entworfen, die unsere Anforderungen ideal abbildet, aber nicht zu generisch oder mit unnötigen Konstrukten überladen ist. Um zu verstehen, wie diese Beschreibung aufgebaut ist, müssen wir wieder eine Detailstufe tiefer gehen und uns ansehen, wie in BAMOS ein Dienst definiert ist und aus welchen Bestandteilen er besteht. Abbildung 3 zeigt den detaillierten Aufbau eines Dienstes. Forschungsbericht BAMOS - 8 -

9 In BAMOS besteht ein Dienst aus einer Abfolge von Interaktionen, welche zusammen Nutzen für den Anwender bringen. Ein Dienst kann ein eng umgrenzter einfacher Dienst (z.b. nur eine Info), aber auch eine Zusammenfassung mehrerer Dienste (Mensa-Service und Haltestellenfahrplan unter dem Deckmantel FHService ) sein. Jede Interaktion beinhaltet einen Screen (ein XForms-Template für eine Oberfläche), der dem Benutzer gezeigt wird und mit dem der Benutzer interagieren kann. Dieses Template kann initial mit Informationen gefüllt werden, die sich aus vorhergehenden Interaktionen ergeben. Aber zu einer Interaktion gehört auch, dass der Benutzer ein Submit absetzen kann, woraufhin seine Eingaben zu Parametern einer Dienst-Methode werden, die aufgerufen wird und deren Rückgabewert zur Ausgabe dieser Interaktion und zur Eingabe der nächsten Interaktion wird. Innerhalb der aktuellen Interaktion wird entschieden, welches die Folge-Interaktion ist. Abhängig von den gemachten Eingaben des Benutzers können sich unterschiedliche Interaktionen an eine erledigte Interaktion anschließen. Service Call from SuperService Interaction Interaction Interaction Interaction Interaction Parameter FH: o Mensaplan o Üstra select Parameter XForms- Template Method of ServiceStub Abbildung 3: Service-Komposition mit Interaktionen Dieses Service-Konzept wird in XML kodiert. Die Abbildung 4 zeigt exemplarisch die XML- Beschreibung für eine Interaktion eines Dienstes. Das Element service bildet dabei den Rahmen und beinhaltet mehrere interaction-elemente. Diese beinhalten wiederum mit dem Element xform Informationen über das zugehörige XForms-Template und mit method über die aufzurufende fachliche Methode einer Service-Implementierung inkl. der Abbildung von Eingabe- und Ausgabe-Attributen. Die Elemente next bzw. nextdefault definieren Informationen über die Folge-Interaktion und definieren somit die Reihenfolge der Interaktionen für einen Dienst. Forschungsbericht BAMOS - 9 -

10 <bm:service id="fhservice" caption="fh-service"> <bm:class name="de.fhhannover.fhservice" />... <bm:interaction id="motd"> <bm:xform src="motd.xml"> </bm:xform> <bm:method name="selectfb"> <bm:param path="/motd/choice" id="0"/> <bm:outparam name="motd" id="0"> </bm:outparam> </bm:method> <bm:nextdefault target="motd-info"/> </bm:interaction>... </bm:service> Abbildung 4: Service-Interaktionen in der XML-basierten Workflow-Sprache 3. Generierung mobiler Anwendungen mittels MDA Die Code-Generierung mittels MDA (Model Driven Architecture) erfolgt auf Basis einer geeigneten domänenspezifischen Modellierungssprache (DSL domain specification language). Im Projektkontext bilden die auf den mobilen Endgeräten ablaufenden Anwendungen die zu modellierende Domäne Modellierung Als Basis der DSL wird im Projekt die UML (Unified Modeling Language) benutzt, weil UML sich als Standardmodellierungssprache für objektorientierte Software-Entwicklung etabliert hat und darüber hinaus die Grundlage für gängige MDA-Werkzeuge darstellt. Die Ablaufbeschreibungen werden in Form von UML-Aktivitätsdiagrammen dargestellt, Detailinformationen werden in UML-Klassendiagrammen modelliert. Das Metamodell Die UML muss um geeignete domänenspezifsche Modellelemente erweitert werden, bspw. zur Beschreibung der Abläufe oder der im Mobiltelefon angezeigten Screens. In MDA wird dazu ein Metamodell benötigt, welches den Sprachumfang der Modellierung festlegt. Für die dynamischen Teile (den groben Ablauf) eignet sich besonders gut ein UML- Aktivitätsdiagramm, welches für unsere Zwecke in seiner Standardform ausreicht. Deshalb ist für dieses Modell eine Erweiterung nicht notwendig (außer um Constraints). Für die statischen Bestandteile (die Interaktionen) eignen sich besonders gut Klassendiagramme, welche aber in ihrer Standardform nicht genügend Semantik mitbringen, um Dienste, Interaktionen, Dienste-Implementierungen, XForms-Elemente usw. zu unterscheiden. Deshalb erweitern wir im UML-Metamodell das Modellelement Klasse und Beziehung. Diese neuen Elemente werden im Folgenden zur Beschreibung von Diensten und Interaktionen benutzt. Abbildung 5 zeigt dieses Metamodell. Forschungsbericht BAMOS

11 Class Association initmethod implclass service interaction contains method xfelement input select select1 output Abbildung 5: Das Metamodell Um die genauen Abhängigkeiten zwischen den neu definierten Elementen formal zu spezifizieren, sind Constraints nötig, welche dann Teil des Metamodells werden. Diese Abhängigkeiten kann man nicht einfach in UML modellieren. Modellierung der Abläufe Für den groben Ablauf eines Dienstes sind normale Aktivitätsdiagramme geeignet, wie beispielhaft in Abbildung 6 dargestellt. In diesem Diagramm werden die Abfolgen der Interaktionen dargestellt, die einen Dienst realisieren. Über Guards an den Transitionen wird festgelegt, unter welchen Umständen welche Transition für die Folge-Interaktion zu verfolgen ist. In dem Beispiel in Abbildung 6 können auf die Interaktion fhstart unterschiedliche Interaktionen folgen. In die Entscheidungsraute führt eine Transition mit der Action /fhstart/choice hinein und aus der Raute heraus mehrere Transitionen mit unterschiedlichen Guards. Dadurch wird festgelegt, dass der Wert in der XForms- Submission in /fhstart/choice den Ausschlag gibt über die Weiterleitung. Sollte keiner der Guard-Werte passen, wird die Default-Transition beschritten. In der Form wird der konkrete Ablauf eines Dienstes modelliert, ohne im Detail festzulegen, wie die einzelnen Interaktionen konkret aussehen. [default] [default] fhstart [default] [default] /fhstart/choice [mensa] [motd] cafeteria [default] cafeteriaday [cafeteria] tram motd [default] motd-info Abbildung 6: Modellierung der Abläufe durch Aktivitätsdiagramme Forschungsbericht BAMOS

12 Modellierung von Views and Interaktionen In dem Aktivitätsdiagramm wurde der grobe Ablauf modelliert, nicht jedoch, wie jede einzelne Interaktion aussieht. Deshalb wählen wir ein erweitertes Klassendiagramm, um die Details eines Dienstes mit seinen Interaktionen abzubilden. Mit Stereotypen werden dabei Klassen semantisch angereichert und somit neue Typen für Service, Interaktion usw. erschaffen. Über Abhängigkeiten werden die einzelnen Typen in Beziehung gesetzt. Abbildung 7 zeigt dieses Diagramm exemplarisch für eine Interaktion. Damit existieren für einen Dienst mehrere dieser Diagramme, und zwar für jede Interaktion genau eins. In dem Beispiel-Diagramm wird folgendes modelliert: Die Service-Klasse (implclass), welche den Zugriffspunkt auf einen Service Provider darstellt, wird an den Dienst (service) gekoppelt und die aufzurufende Methode (method) per contains- Beziehung an die implclass gehängt. An dem Dienst hängt die zu spezifizierende Interaktion (interaction), die wiederum auf die fachliche Methode verweist und mit dem Wurzelelement eines XForms-Modells (xfelement) verbunden ist. Dieses Wurzelelement beinhaltet mehrere Modell-Elemente (xfelement), welche mit einem zusätzlichem Stereotyp die Art des Interaktionselements definieren (z.b. output oder select1). Über die Attribute dieser Elemente werden die Interaktionselemente initialisiert. Die Reihenfolge der Elemente aus dem Screen wird über das order-constraint an der Beziehung zwischen Wurzelelement und Unterelementen festgelegt. Das Mapping zwischen Interaktionselementen und Eingabeparameter für die fachliche Methode wird über eine Abhängigkeit mit Constraint geregelt. In dem Beispiel besagt die 0 an der Abhängigkeit, dass das ausgewählte Element aus dem select1-element choice zum 1. Eingabeparameter der Methode selectfb wird. Somit ist die gesamte Interaktion beschrieben. Weitere Feinheiten (die aus diesem Beispiel nicht hervorgehen) werden hier nicht näher betrachtet. <<service>> fhservice -caption : String = FH-Service <<implclass>> de.fhhannover.fhservice {0=motd} <<contains>> motd -submitlabel : String = Ok! <<method>> selectfb <<xfelement>> motd {0} <<contains>> {order=0} <<xfelement>> <<output>> advice -value : String = Please.. <<contains>> {order=1} <<xfelement>> <<select1>> choice -label : String = MOTDs -labels : List = {Computer... -values: List = {cs,ec,et,ic} Abbildung 7: Modell für eine Beispiel-Interaktion Forschungsbericht BAMOS

13 [default] [default] cafeteria cafeteriaday [default] [mensa] [cafeter i a] fhstart tram /fhstar t/c hoic e [motd] {0} motd [defaul t] motd-info [default] [default] 3.2. Generierung Nachdem die Applikation bzw. der Dienst mit ihrem Ablauf und den Interaktionen modelliert ist, können die Beschreibungen generiert werden, welche zur Laufzeit der Applikation benötigt werden. Dies sind zum einen die Beschreibungen der Oberflächen in XForms, aus denen vom mobilen Gerät zur Laufzeit Oberflächen generiert werden. Zum anderen wird die Ablaufbeschreibung generiert, mit deren Hilfe der Service Broker zur Laufzeit zwischen Adhoc-Client und Service Provider vermittelt. Abbildung 8 zeigt genau diese Transformation. PIM1 PIM2 <xml> <xml> <xml> XForms- <xml> Template XForms- Template XForms- Template XForms- Template PIM-to-PIM- Transformation <xml> workflowdescription Abbildung 8: Transformation zwischen PIMs Aus den Beispielmodellen aus Abbildung 6 und 7, welche einen Teil eines Dienstes modellieren, wird somit ein XForms-Template für die Interaktion und ein Teil der Ablaufbeschreibung generiert. Wie das Generierungsergebnis aus diesen Modellen aussieht, zeigen die Abbildungen 4 und Abbildung 9. <bamos xmlns:xf=" <xf:model> <xf:instance> <motd> <advice>please choose the Institute!</advice> <choice /> </motd> </xf:instance> <xf:submission xf:id="bspform" /> </xf:model> <xf:output xf:ref="/motd/advice"> <xf:label /> </xf:output> <xf:select1 xf:ref="/motd/choice"> <xf:label>motds</xf:label> <xf:item> <xf:label>computer Science</xf:label> <xf:value>cs</xf:value> </xf:item>... </xf:select1> <xf:submit xf:submission="bspform"> <xf:label>ok!</xf:label> </xf:submit> </bamos> Abbildung 9: Generiertes XForms-Termplate Forschungsbericht BAMOS

14 Es wurden Beschreibungen generiert, die zur Laufzeit benötigt werden. Dazu werden diese im Repository des Service Brokers abgelegt. Es müssen also keine Änderungen am Adhoc- Client vorgenommen werden. Der Service Broker verarbeitet die Ablaufbeschreibung und erstellt dadurch ein Objekt-Geflecht, welches jeden Dienst repräsentiert und die Ausführung des jeweiligen Dienstes ermöglicht. Die eigentliche Fachlichkeit des Dienstes (also der Service Provider) wurde nicht generiert, sondern wird nur aufgerufen. Der Service Broker schickt die XForms-Beschreibung zu einer Interaktion zum Adhoc-Client, wenn der Benutzer zur entsprechenden Interaktion wechselt. Der Adhoc-Client liest diese Beschreibung aus und erstellt daraus eine MIDP-Oberfläche mit Formular, Eingabe- und Ausgabeelementen sowie Commands. Was die Komponenten der Architektur mit welchen generierten Artefakten tun, stellt zusammenfassend die Abbildung 10 dar. PIM2 <xml> <xml> <xml> XForms- <xml> Template XForms- Template XForms- Template XForms- Template <xml> workflowdescription Mobile Client generation at runtime Service Broker Runtime-environment MIDP-Objects: -Forms -Input-/Output-fields -Commands Java-Objects: -implement workflow for every service Abbildung 10: Generierungsprozess zur Laufzeit Damit ist ein Framework geschaffen, welches es ermöglicht, beliebige Service Provider in die Architektur anzubinden, ohne Änderungen am Adhoc-Client vornehmen zu müssen. Somit werden mithilfe von MDA Dienste für mobile Geräte verfügbar gemacht. Wenn die Anbindung von Diensten beschreibbar ist, können diese Beschreibungen modelliert und generiert werden. Dieses Vorgehen hat mehrere Vorteile: - Wenn Beschreibungen den Ablauf von Diensten festlegen, muss die Ablaufsteuerung auf dem Service Broker nicht programmatisch geändert werden, wenn neue Dienste angebunden werden sollen oder sich angebundene Dienste ändern. - Wenn zudem die Oberflächen für den Benutzer am mobilen Gerät mit XForms beschrieben werden, können diese Beschreibungen zur Laufzeit auf das mobile Gerät übertragen werden, so dass die Applikation auf dem mobilen Gerät absolut unabhängig von jeglichen Fachlichkeiten existieren kann. So bedürfen neue oder geänderte Dienste auch keiner Änderung am mobilen Gerät. Dies ermöglicht eine sehr gute Erweiterbarkeit und Einsetzbarkeit in verschiedensten Szenarien. Da diese Beschreibungen in XML vorliegen und damit unhandlich zu erstellen sind, ist die Modellierung und Generierung dieser Beschreibungen der nächste logische Schritt. Mit Hilfe von MDA können diese Beschreibungen dann einfach und intuitiv erstellt werden, so dass ohne detaillierte Kenntnisse der XML-Syntax neue Service Provider angebunden werden können und eine maximale Erweiterbarkeit erreicht wird. Forschungsbericht BAMOS

15 4. Anwendungsszenario Die Tragfähigkeit der entwickelten Basisarchitektur wurde im Projekt anhand des folgenden Anwendungsszenarios nachgewiesen Hardware und Software-Infrastruktur Mobile Endgeräte - Als mobile Endgeräte wurden Mobiltelefone vom Typ Nokia 6600, Siemens S65 oder SonyEricson P910i mit integrierten Java-Bluetooth-Stack (JABWT) und PDAs vom Typ Hewlett Packard IPAQ hx47000 mit Bluetooth-Stack-Implementierung von Avetana eingesetzt. - Auf jedem mobilen Endgerät läuft der generische im Projekt implementierte Adhoc-Client. Der Adhoc-Client ist in der Lage, die auf dem Server abgelegten Dienste- Beschreibungen entgegenzunehmen, anzuzeigen und die zur Dienstnutzung erforderlichen Informationen an den Server zu senden. Server mit Service Broker: - Der Service Broker wurde auf einem Notebook mit integriertem Bluetooth implementiert. - Auf dem Server läuft der in Java implementierte Service Broker. Insgesamt sind im beschriebenen Anwendungsszenario drei einfache Dienste beispielhaft implementiert: 1. Mensaplan Es werden die am aktuellen Tag angebotenen Mensagerichte angezeigt. Der Dienst wurde implementiert, indem der Server die entsprechende Webseite des Studentenwerks aufruft und die Information ausliest. 2. Uestra-Fahrplan Es werden die auf die aktuelle Uhrzeit bezogenen nächsten Abfahrtzeiten der Straßenbahn an der FH-Haltestelle angezeigt. Der Dienst wurde implementiert, indem der Server die entsprechende Webseite der Hannoverschen Verkehrsbetriebe Uestra aufruft und die Information ausliest. 3. Message-of-the-day Es wird zufällig ein Tages-Motto aus einer Menge von gespeicherten Zitaten uns Aussprüchen zurückgeben. - Jeder Service ist beschrieben (a) durch eine entsprechende XForms (siehe Abschnitt 2.2.), die den auf dem mobilen Endgerät angezeigten Screen und die verarbeitenden Daten spezifiziert sowie (b) durch die in XML-Format definierte Ablaufbeschreibung (siehe Abschnitt 2.3), die den Informationsfluss und die Auswahl der anzuzeigenden Screens festlegt. Sämtliche dieser komplexen XML-Spezifikationen können mithilfe von Model Driven Architecture aus semantisch angereicherten UML-Modellen generiert werden Beschreibung des Szenario Sobald ein mobiles Endgerät in die Reichweite des Bluetooth-Netzes des Servers kommt, verbindet es sich spontan mit dem Service Broker, zeigt die zur Verfügung stehenden Dienste an und ermöglicht dem Nutzer einen ausgewählten Dienst zu verwenden. Im Einzelnen finden die folgenden Schritte statt: 1. Spontane Vernetzung Auf dem mobilen Endgerät ist der als J2ME-Java-Programm implementierte Adhoc-Client gestartet. Sobald sich das mobile Endgerät (Telefon oder PDA) in Reichweite des Server-Bluetooth-Netzes befindet, wird automatisch via Bluetooth eine Verbindung zum Service Broker aufgebaut. Forschungsbericht BAMOS

16 2. Service Broker schickt Startseite Der Service Broker schickt nun eine XForms-Startseite an das mobile Endgerät (Abbildung 11): Adhoc Client Service Broker Services: Service overview XForms XForms- Generation o FH-Service o Wetter select XForms- Submit FH-Service chosen Submission- Procession FH-Service XForms Abbildung 11: Austausch von XForms zwischen Adhoc-Client und Service Broker Der Aufbau des XForms-Formats ist komplex und wird in Abbildung 12 angezeigt. Abbildung 12: An Mobilgerät übertragene XForms-Startseite Forschungsbericht BAMOS

17 3. Mobilgerät zeigt Startseite an Das Mobilgerät zeigt nun die Startseite mit Diensteanbietern an, indem der Adhoc-Client die vom Server empfangene XForms-Seite rendert und die angebotenen Diensteanbieter anzeigt (Abbildung 13): Abbildung 13: Screen der angebotenen Dienste 4. Dienstanbieter-Auswahl wird an Server geschickt Im mobilen Endgerät wird nun eine Auswahl eines Dienstanbieters getroffen und nach Drücken des Submit-Buttons die Auswahlentscheidung an den Server gesendet (Abb. 14). Im Beispiel sollen die vom FH-Service angebotenen Dienste angezeigt werden. Abbildung 14: XForms-Submit mit Auswahl des Dienstanbieters an Service Broker 5. Angebotene Dienste werden an Mobilgerät geschickt Der Server wählt anhand der Ablaufbeschreibung die nächste XForms und schickt die entsprechende Übersicht der vom Dienstanbieter angebotenen Dienste an das Forschungsbericht BAMOS

18 Mobilgerät (Abbildung 15). Abbildung 15: Service Broker schickt XForms an Mobilgeräts 6. Mobilgerät wählt einen Dienst Vom Adhoc-Client wird die XForms-Seite ge-rendert und der Nutzer wählt auf dem entsprechenden Screen den gewünschten Dienst (hier uestra). Seine Wahl wird als XForms-Dokument an den Service Broker geschickt (Abb. 16 und 17). Abbildung 16: Screen für Auswahl der Dienste Forschungsbericht BAMOS

19 Abbildung 17: XForms-Submit mit Dienstauswahl 7. Service-Broker schickt Dienst-XForms an Mobilgerät Der Service Broker nimmt die Auswahl in Empfang, wählt anhand der Ablaufbeschreibung des Dienstes die an das Mobilgerät zu schickende XForms aus (Abbildung 18), die dann schließlich am Mobilgerät die gewünschten Informationen anzeigt (Abbildung 19). Forschungsbericht BAMOS

20 Abbildung 18: XForms des Dienstes Abbildung 19: Angezeigter Dienst auf dem mobilen Endgerät Forschungsbericht BAMOS