Sensor Data Stream Processing in Health Monitoring
Werbung
Research Collection Report Mobilität und Informationssysteme Workshop des GI-Arbeitskreises "Mobile Datenbanken und Informationssysteme", 16./17. Oktober 2003, Zürich Author(s): Türker, Can Publication Date: 2003 Permanent Link: https://doi.org/10.3929/ethz-a-006714707 Rights / License: In Copyright - Non-Commercial Use Permitted This page was generated automatically upon download from the ETH Zurich Research Collection. For more information please consult the Terms of use. ETH Library Departement Informatik Institut für Informationssysteme ____________________________________________________________ Mobilität und Informationssysteme Workshop des GI-Arbeitskreises „Mobile Datenbanken und Informationssysteme“ 16./17. Oktober 2003, Zürich Can Türker (Hrsg.) Technical Report #422, 2003 Oktober 2003 ETH Zürich Departement Informatik Institut für Informationssysteme Dr. C. Türker Address: C. Türker, ETH Zürich, Institut für Informationssysteme, ETH Zentrum, CH-8092 Zürich, Switzerland, [email protected] This report is available via http://www.inf.ethz.ch/publications/ or ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/ © 2003 Departement Informatik, ETH Zürich Programmkomitee Jürgen Bittner Christoph Gollmick Hagen Höpfner Birgitta König-Ries Klaus Küspert Holger Meyer Günther Specht Can Türker SQL GmbH, Dresden Universität Jena Universität Magdeburg Universität Karlsruhe Universität Jena Universität Rostock Universität Ulm ETH Zürich Externe Gutachter Thomas Müller Universität Jena Lokale Organisation Can Türker Antoinette Galler ETH Zürich ETH Zürich Vorwort Der fünfte Workshop des GI-Arbeitskreises Mobile Datenbanken und Informationssyste” me“ findet unter dem Titel Mobilität und Informationssysteme“ am 16./17. Oktober 2003 ” in Zürich statt. Wie seine Vorgänger soll auch dieser Workshop Vertreter von Hochschulen, Produkthersteller und Anwender mobiler Datenbanken und Informationssysteme zusammenführen und ihnen die Möglichkeit bieten, ihre Beiträge im Kreis fachlich interessierter Kollegen zu diskutieren. Dabei sollen sowohl Grundlagenfragen als auch Aufgabenstellungen aus Anwendungs- und Technologiebereichen erörtert werden. Der vorliegende Bericht enthält die Beiträge zu diesen Workshop. Insgesamt wurden sechs Lang- und zwei Kurzbeiträge angenommen. Diese Workshop-Beiträge spiegeln ein breites Spektrum des Gebietes Mobile Datenbanken und Informationssysteme“ wider und ” bieten interessante Ansatzpunkte für spannende Diskussionen. Hinzu kommt ein eingeladener Beitrag von Prof. Dr. Heiko Schuldt von der Privaten Universität für Medizinische Informatik und Technik Tirol (UMIT). Abschließend bedanke ich mich bei allen, die direkt oder indirekt mitgeholfen haben, den Grundstein zum Gelingen dieses Workshops zu legen. Mein Dank gilt insbesondere den Autoren für ihre Einreichungen, den Programmkomiteemitgliedern und externen Gutachtern für die Begutachtung und Auswahl der eingereichten Beiträge, und Prof. Dr. Heiko Schuldt für die Annahme der Einladung zu einem Vortrag. Last but not least geht ein spezieller Dank an Antoinette Galler für Ihre Unterstützung bei der lokalen Organisation. Zürich, Oktober 2003 Can Türker Inhaltsverzeichnis Heiko Schuldt, Gert Brettlecker Sensor Data Stream Processing in Health Monitoring Felix Alcala, Jöran Beel, Arne Frenkel, Bela Gipp, Johannes Lülf, Hagen Höpfner Ortung von mobilen Geräten für die Realisierung lokationsbasierter Diensten Karsten Baumgarten, Christoph Gollmick Konzeption eines interaktiven mobilen Reiseinformationssystem Martin Breunig, Rainer Malaka, Wolfgang Reinhardt, Joachim Wiesel Vision mobiler Geodienste (Kurzbeitrag) Michael Cammert, Christoph Heinz, Jürgen Krämer, Bernhard Seeger Datenströme im Kontext des Verkehrsmanagements Peter Dornbusch, Martin Huber User-Toolkits zur dienstbasierten Entwicklung mobiler Applikationen Thomas Königsmann Konzeption geräteübergreifender Anwendungen Bela Mutschler, Günther Specht Implementierungskonzepte und Anwendungsentwicklung kommerzieller mobiler Datenbanksysteme: Ein Vergleich Christian Weigand Implementierung eines medizinischen Kommunikationsstandards auf einem PDA unter Linux (Kurzbeitrag) Sensor Data Stream Processing in Health Monitoring Heiko Schuldt Gert Brettlecker University for Health Informatics and Technology Tyrol (UMIT) Innrain 98, A–6020 Innsbruck, Austria {heiko.schuldt, gert.brettlecker}@umit.at Abstract: Health monitoring and e-Inclusion significantly increase the quality of healthcare since they allow patients to live at home while nevertheless receiving treatment and care immediately, when needed. However, health monitoring and e-Inclusion also impose several challenges to the underlying information infrastructure. These challenges are stemming from data streams that are generated by smart sensors attached to the patients and to their augmented environment. Essentially, these streams need to be processed with near real-time constraints. In addition, also the mobility of users and patients has severe consequences on the information infrastructure. Disconnections and reconnections have to be handled transparently to the user/patient and data stream processing has to be dynamically adapted to the actual processing resources. Health Monitoring Health monitoring aims at dynamically gathering, managing, processing, and storing physiological data usually provided by smart sensors. Most importantly, it allows to monitor the health status of patients in an online fashion. By dynamically processing sensor data, physicians and care personnel are able to immediately react to critical, pathological changes or even to anticipate such changes. Therefore, health monitoring is considered to significantly enhance the quality of patients’ lives and to increase overall quality of care, even in out-of-hospital conditions. The latter is particularly important since chronic ailments such as cardiovascular diseases, hypertension, and diabetes affect a significant number of the western population (a survey of the American Heart Association states that cardiovascular diseases are the leading cause of death in many western countries [AHA01]). According to a recent prognosis for healthcare in the year 2013, the use of direct permanent monitoring of patients’ vital signs, as well as the direct synchronous transfer of this sensory data will significantly increase [HAHK02]. From a technical point of view, health monitoring is a rather novel domain that brings together experts from various fields such as computer engineering, networking, data and information management, and from (biomedical) signal processing. In terms of computer and sensor engineering, health monitoring greatly benefits from recent trends in smart sensors and ubiquitous and wearable computing (e.g., smart shirts [GTW03], ring sensors [ASR+ 03], or smart bandages [NA00]). As a result, a new generation of sensor systems currently emerges that make unobtrusive, non-invasive monitoring applicable to an incre- asing number of patients and diseases. In terms of networking, wireless network connections with both minimal power consumption and transmission power are needed in order to increase the lifetime of sensors and to avoid unnecessary perturbation and side-effects. Experts from biomedical signal processing are providing efficient and effective algorithms for the (pre-) filtering of sensor signals and the processing of these signals that allows to identify critical and/or pathological behavior. From an information systems point of view, an infrastructure is needed that supports continuous querys and continuous processing of data streams. e-Inclusion In our aging society, monitoring is not only required for patients suffering from chronic diseases, but also for elderly and disabled people living in their home environment while nevertheless having the guarantee to receive immediate treatment and care if needed. Elderly people, for instance, may suffer from one or more chronic diseases, therefore requiring a health monitoring infrastructure at home. But in addition, the activity of these people as well as their context have to be monitored. From the perspective of sensor technology, this does not only require wearable sensors but also sensors that are integrated into the home environment (e.g., “intelligent carpets” measuring the position of a person and also their activity, i.e., whether a person is active –moving– or whether he/she has fallen down). These people have to be electronically included (e-Inclusion) in the society by making adequate use of information technology when needed. In this kid of monitoring applications, it is therefore necessary to consider the context of a person. A person without current activity may be fine at night when being located in the bedroom, but when the person does not show any activity at daytime when being located in the floor, an emergency situation is very likely. Consider furthermore people suffering from special age-related impairments and mental diseases like Alzheimer. In this case, even more emphasis has to be put on monitoring the activity of the person together within the current context. A warning has to be generated, for instance, when the person tries to leave the apartment without having switched off the oven. By all these extensions, the number of sensors, data sources, etc., and therefore also the number of data streams that have to be processed will be significantly increased compared to the monitoring of a single disease. This, of course, has severe consequences on the underlying information infrastructure. Infrastructure for Health Monitoring and e-Inclusion Applications for data stream processing are not monolithic but are made out of basic building blocks (e.g., programs for sensor data filtering or processing, noise reduction, access to medical databases or electronic patient records, etc.). Each of these building blocks provides certain services that can be invoked. Application development in this context the- refore requires to seamlessly combine these building blocks into a coherent whole rather than developing programs from scratch. Workflows or processes are a means to combine existing services. In terms of managing and storing data streams, the requirements imposed by health monitoring and e-Inclusion by far exceed the capabilities of existing database systems [GO03]. Similarly, conventional workflow and process support systems are tailored to execute processes at dedicated points in time. Data stream processing, however, require processes to run continuously, similar to continuous query processing. Incoming stream data serves as continuous input to these standing processes. Special requirements are also the storage of streams, or joins between streams in order to combine the data produced by different sensors, etc. The bottom line of these requirements is that existing process support infrastructures have to be extended in order to continuously execute processes and to support further crucial requirements. Driven by the nature of the domain where health monitoring and e-Inclusion is applied to, a stringent requirement is that the underlying information infrastructure running processes and workflows implementing data stream processing is highly dependable since its correct functioning may be potentially life-saving. In here, dependability comes with several flavors. First, the information infrastructure has to be highly available in order to provide dedicated quality of service guarantees, for example in terms of the real-time aspects of the data streams being processed. Critical situations must be detected immediately and alarms have to be raised on the spot; no delay due to overload situations of the infrastructure can be tolerated. Second, the process-based applications have to be built in a way that correct failure handling is guaranteed (e.g., by following the model of transactonal processes [SABS02]). This also means that applications, since they are vital to their users, have to be verified whether they behave correctly, even in failure situations. Third, the infrastructure has to be very flexible. The disease pattern of patients varies over time and the system should allow to tailor processes to the current monitoring needs of an elderly person or a patient. This includes new types of sensors, new types of services, new types of processes, etc., that must be supported. Mobility in Health Monitoring and e-Inclusion A crucial requirement on an infrastructure for data stream processing is to take into account that users and patients, especially when being monitored in an out-of-hospital environment, are usually mobile. Mobility of users and patients poses a set of challenges to the design and development of an information infrastructure for health monitoring. Users and patients do not necessarily have access to the systems environment installed at their home (base station, home network). However, even when being disconnected, data streams produced by the (body) sensors have to be processed by some the mobile device (e.g., a PDA carried by the patient), thereby taking into account the limited CPU and storage resources of these devices. Given these limitations, data (pre-)processing and simple hazard detection have to be applied on these devices instead of full fledged medical, activity, and context monitoring. In addition, synchronization is required whenever a device is connected to the home network. After reconnection, data stream processing should be automatically and smoothly migrated to the fixed network environment, thereby making use of the increased processing power and better network connection. Hyperdatabases for Health Monitoring and e-Inclusion A hyperdatabase (HDB) [SBG+ 00, SSSW02] is an infrastructure that supports the execution of processes on top of distributed components using existing services. The HDB provides transactional guarantees for processes, sophisticated routing strategies to dynamically choose among the available components, and allows to balance the overall load among them. Hence, the HDB provides database-like functionality, but not at the data level but at the level of access to services. Meeting the challenging requirements imposed by health monitoring and e-Inclusion applications as well as by the mobility of users and/or patients requires to significantly extend hyperdatabase environments in several directions. Among other important aspects like data privacy and security, the following problems have to be solved: • support for continuously runnig processes: essentially, streaming processes have to be continuously fed with incoming sensor data. Moreover, the hyperdatabase infrastructure has to be designed in such a way that dedicated quality-of-service guarantees, especially in terms of response times, can be provided. This has to be done in a highly reliable infrastructure. An important requirement is also to provide an easy-to-use graphical interface that can be used by physicians and care personnel to design new or to revise existing patient- and/or disease-specific streaming processes. • support for mobile users and devices: mobility is an inherent characteristic of the users in health monitoring and e-Inclusion applications. The actual monitoring has to be reliably provided way by the underlying in a way that is transparent to the user. In particular, he/she does not have to take care on the connection state and on the way, streaming processes are being executed. Rather, the infrastructure has to dynamically migrate processing tasks between the home infrastructure and the mobile devices depending on the connection status. • support for load balancing: in order to meet the real-time constraints, the system has to automatically and equally distribute the load between all services of the overall system. When, for instance, several components in the home network provide sensor data filtering algorithms, then different streams should be distributed appropriately among these services. Similarly, when failures or bottlenecks are detected, the system should be able to dynamically install new instances of services that can then be used for load balancing purposes. Conclusion The above mentioned extensions to hyperdatabase systems reflect current activities at UMIT. In a joint effort that includes participants from different fields such as information systems, information and software engineering, computer engineering, and biomedical signal processing, but also with external partners from the biosignal processing and telemedicine groups of the Austrian research center in Seibersdorf (ARCS), we are currently developing a comprehensive infrastructure to support health monitoring and e-Inclusion activities. The basis for the information infrastructure is the OSIRIS system (Open Service Infrastructure for Reliable and Integrated process Support) [WSN+ 03] to which we add data stream processing functionality in a reliable, adaptable, and flexible way. Bibliography [AHA01] 2002 Heart and Stroke Statistical Update. American Heart Association. 2001. [ASR+ 03] Asada, H. H., Shaltis, P., Reisner, A., Rhee, S., und Hutchinson, R. C.: Mobile Monitoring with Wearable Photoplethymographic Biosensors. IEEE EMB Magazine. 22(3):28–. 2003. [GO03] Golab, L. und Özsu, M. T.: Issues in Data Stream Management. ACM SIGMOD Record. 32(2). 2003. [GTW03] GTWM – The Georgia Tech Wearable Motherboard: The Intelligent Garment for the 21st Century. http://www.smartshirt.gatech.edu. 2003. [HAHK02] Haux, R., Ammenwerth, E., Herzog, W., und Knaup, P.: Health care in the information society. A prognosis for the year 2013. Int. Journal of Medical Informatics. 66:3–21. 2002. [NA00] NASA’s Jet Propulsion Laboratory California. Wearable Sensor Patches for Physiological Monitoring. http://www.nasatech.com/Briefs/Feb00/NPO20651. html. 2000. [SABS02] Schuldt, H., Alonso, G., Beeri, C., und Schek, H.-J.: Atomicity and Isolation for Transactional Processes. ACM Transactions on Database Systems (TODS). 27(1):63–116. March 2002. [SBG+ 00] Schek, H.-J., Böhm, K., Grabs, T., Röhm, U., Schuldt, H., und Weber, R.: Hyperdatabases. In: Proceedings of the 1st International Conference on Web Information Systems Engineering (WISE’00). S. 14–23. Hong Kong, China. June 2000. IEEE Computer Society Press. [SSSW02] Schek, H.-J., Schuldt, H., Schuler, C., und Weber, R.: Infrastructure for Information Spaces. In: Proceedings of the 6th East-European Conference on Advances in Databases and Information Systems (ADBIS’2002). S. 22–36. Bratislava, Slovakia. September 2002. Springer LNCS, Vol. 2435. [WSN+ 03] Weber, R., Schuler, C., Neukomm, P., Schuldt, H., und Schek, H.-J.: Web Service Composition with O’GRAPE and OSIRIS. In: Proceedings of the 29th International Conference on Very Large Databases (VLDB’03). Berlin, Germany. September 2003. Morgan Kaufman Publishers. Ortung von mobilen Geräten für die Realisierung lokationsbasierter Diensten Felix Alcala [email protected] Jöran Beel [email protected] Johannes Lülf [email protected] Arne Frenkel [email protected] Béla Gipp [email protected] Hagen Höpfner∗ [email protected] Otto-von-Guericke-Universität Magdeburg Postfach 4120, 39016 Magdeburg, Deutschland Abstract: Die Entwicklung im Sektor von mobilen Endgeräten geht eindeutig in die Richtung, immer kompaktere Geräte mit immer mehr Funktionalität anzubieten. Schon heute können z.B. Laptops oder sogar PalmTops mit GPS-Kontrollern kombiniert werden. Die somit verfügbaren genauen Positionsinformationen ermöglichen die Realisierung von unterschiedlichsten lokationsbasierten Diensten. Ziel des in diesem Papier vorgestellten Projektes ist es, die Möglichkeiten derartiger Szenarien zu untersuchen. Dazu wird ein System vorgestellt, welches die ad-hoc Lokalisierung von Nutzern von mobilen Endgeräten mittels mobiler Endgeräte ermöglicht. 1 Einleitung und Motivation Lokationsbasierte Dienste sind einer der aktuellsten und spannensten Schwerpunkte im Bereich mobiler Informationssysteme. Diese Tatsache resultiert nicht zuletzt daraus, dass eine zentrale Eigenschaft der hierbei eingesetzten Endgeräte deren Kompaktheit und Leistungsfähigkeit ist. Nutzer mobiler Endgeräte wie Laptops, PDAs oder Handys können sich unabhängig von Büroräumen und Schreibtischen bewegen und dennoch die Funktionen ihrer Geräte ausschöpfen. In Kombination mit der kabellosen Vernetzung und der Lokalisierung derartiger Geräte ergibt sich aus Sicht der Anbieter von Informationssystemen daraus die Möglichkeit, dem mobilen Kunden Dienste anzubieten, welche auf dessen aktuellen Aufenthaltsort zugeschnitten sind. Die dazu notwendige Bestimmung des Ortes kann im Wesentlichen auf zwei verschiedene Arten [Eri01] erfolgen. Da die am weitesten verbreiteten und flächendeckend verfügbaren Funknetztechnologien (GSM [ETS93], GPRS [ETS98], HSCSD [ETS99]) einen zellulären Charakter aufweisen, kann zum einen über die zur Einwahl notwendigen Basisstationen mittels Triangulation die ungefähre Position eines Gerätes ermittelt werden. Zum anderen besteht die wesentlich genauere Möglichkeit der Positionsbestimmung unter Verwendung des GPS [Kap96]. Beide Verfahren haben Vor- und Nachteile, welche hier aber nicht tiefergehend erläutert werden sollen. ∗ Gefördert durch die DFG unter der Fördernummer SA 782/3-2. Das in dem Beitrag beschriebene Projekt wurde als Grundlage für die Weiterentwicklung des beim Jugend-forscht“-Wettbewerb 2002 präsentierten und prämierten Systems ” GSM-Schutzengel“ [GBAP03] konzipiert. Dieses System dient im Wesentlichen der au” tomatischen Meldung der aktuellen Position eines Kraftfahrers via Handy im Falle eines Unfalls an eine Rettungsstelle. Auf diese Weise kann dem Verunfallten schneller geholfen werden. Der ursprüngliche Ansatz nutzt die Zell-Triangulation zur Positionsbestimmung. Um eine noch genauere Lokalisierung zu ermöglichen wurde im Rahmen der hier vorgestellten Arbeit untersucht, ob und wie sich das GPS eignet, um derartige lokationsbasierte Informationssysteme zu unterstützen. Die Aufgabenstellung wurde im Rahmen eines Softwarepraktikums am Institut für Technische und Betriebliche Informationssysteme der Fakultät für Informatik an der Ottovon-Guericke Universität Magdeburg bearbeitet. Da die vollständige Integration der GPSPositionsbestimmung den Rahmen dieser Veranstaltung gesprengt hätte und der positive Abschluss eines Softwarepraktikums ein lauffähiges System voraussetzt, wurde das in Abschnitt 2 vorgestellte Ersatzszenario implementiert. Die hierbei verwendeten Konzepte lassen sich aber - bei vorhandener Hardware - mit etwas zusätzlichem Aufwand in den GSM-Schutzengel integrieren. 2 Gesamtarchitektur Grob gesagt, war das Ziel des Projektes die Ortung von mobilen Geräten durch mobile Geräte. Bei dem zu ortenden Gerät handelt es sich um ein GPS-fähiges Endgerät, welches über eine Internet-Anbindung verfügt. Es ermittelt permanent seine Position und aktualisiert sie in einer zentralen Datenbank. Für die Abfrage dieser Position aus der Datenbank existieren eine Standard-Desktopanwendung und eine Applikation für Java-fähige Handys. Beide Applikationen ermöglichen die Darstellung der Position des zu ortenden mobilen Gerätes anhand einer Karte. Dazu werden die in der Datenbank gespeicherten Informationen gelesen und in das Kartenmaterial eingeblendet. Neben der Darstellung der Position, welche in unterschiedlichen Detailstufen möglich ist, können auch Informationen zur aktuellen Bewegungsrichtung und Geschwindigkeit angezeigt werden. Um den Missbrauch der verfügbaren Daten zu verhindern, enthält das System auch Mechanismen zur Rechtevergabe. Auf diese Weise kann festgelegt werden, welcher Nutzer welche mobilen Geräte orten darf. Im Folgenden wird die Grob-Architektur des Systems vorgestellt. 2.1 Beteiligte Komponenten Das System (siehe Abbildung 1(a)) besteht aus vier Knoten, zwei Servern und zwei Clients, wobei die Clients in mehreren Instanzen vorliegen. Die Funktionalität der Clients unterteilt sich in die Komponenten Positionsanzeige (ortender Nutzer) und Positionsermittlung (georteter Nutzer). Letztere ist mit einem GPSController verbunden und sendet die aktuelle Position des Gerätes an den Positionsserver. Die Übermittlung geschieht über TCP/IP, was beliebige Anwendungsprotokolle ermöglicht. Ideal ist eine paketbasierte Technik wie GPRS. Um die übertragene Datenmenge möglichst gering zu halten, kann man die Übermittlung in frei definierbaren Zeitintervallen erfolgen lassen sowie Mindestpositionsveränderungen definieren. Der Positionsserver trägt alle übermittelten Positionen in einer Datenbank ein. Gespeichert werden dabei neben der Position auch weitergehende Informationen wie Geschwindigkeit, Datum und Zeit. Die Komponente Positionsanzeige kann dann - entsprechende Rechte vorausgesetzt - diese Informationen für beliebige Nutzer vom Server abfragen. Das zur Anzeige der Position benötigte Kartenmaterial wird vom Kartendienst Map24 [NET03] geladen. Dieser ermöglicht das Anfragen beliebiger Kartenausschnitte innerhalb von Europa über eine entsprechend kodierte URL. Die Karte wird dabei als statisches Bild geliefert. Das Sequenzdiagramm in Abbildung 1(b) verdeutlicht den Ablauf einer Positionsabfrage. TCP/IP SERVER: Position Kartenserver SERVER: Karte Map24 Kartenserver TCP/IP <<Datenbank>> SERVER: Applikation Positionsserver Positionsanzeige Positionsermittlung Positionsdatenbank TCP/IP Aktuelle Position von User x Postion von User x? TCP/IP User x ist bei y Aktuelle Position von User x Postion y CLIENT: Mobil CLIENT: PC PositionsAnzeige PositionsAnzeige PositionsErmittlung (GPS) (a) Verteilungsdiagramm Karte von Position y mit User x? Karte Aktuelle Position von User x (b) Sequenzdiagramm zum Ablauf einer Positionsabfrage Abbildung 1: Gesamtarchitektur Alle Knoten (abgesehen vom Map24-Kartenserver) wurden in Java implementiert. Da kein mobiles Gerät mit GPS-Funktionalität zur Verfügung stand, wurde für die Positionsermittlung auf einen Laptop mit angeschlossenem externem GPS-Controller zurückgegriffen. 2.2 Anforderungen an die Endgeräte Das ortende mobile Endgerät muss Java nach der Connected-Limited-Device-Configuration-Spezifikation (CLDC) [Sun03] unterstützen und eine Internet-Verbindung aufbauen können. Für das ortende nicht-mobile Endgerät gelten die gleichen Voraussetzungen. Jedoch wird hier anstatt der eingeschränkten J2ME (Java 2 Micro Edition) die Java Virtual Machine 1.4 oder höher benötigt, welche einen stark erweiterten Funktionsumfang liefert. An das zu ortende mobile Endgerät werden die folgenden Anforderungen gestellt: Möglichst permanente Anbindung an das Internet: Damit die Positionen des Nutzers die notwendige Aussagekraft besitzen, müssen sie in möglichst kurzen Abständen an den Server übermittelt werden. Hierfür ist eine dauerhafte Internet-Anbindung des Endgerätes, beispielsweise über GPRS, sinnvoll. Bei GPRS wird nicht nach Zeit sondern nach übertragendem Volumen abgerechnet. Da die Positionsdaten nur wenig Übertragungskapazität benötigen, sind die anfallenden Kosten relativ gering. Integration von GPS im Endgerät: Damit das Gerät seine Position ermitteln kann, muss ein GPS-Empfänger integriert sein bzw. Zugriff auf ein externes GPS-Gerät bestehen. Fähigkeit zum Ausführen von Java: Die Übermittlung der Position an den Server erfolgt über ein Java-Programm. Damit das Gerät dadurch nicht blockiert wird, muss es multitasking-fähig sein. Derzeit erfüllen nur wenige Geräte diese Anforderungen. Es existieren zwar GPS-fähige PDAs, diese benötigten jedoch zusätzlich ein Mobiltelefon, um eine Verbindung zum Internet herzustellen. Andererseits gibt es von Benefon1 oder Garmin2 Mobiltelefone mit integriertem GPS-Empfänger. Diese Geräte sind aber nicht java-fähig. Es ist jedoch zu erwarten, dass diese Anforderungen bald von einer zunehmenden Anzahl von Geräten erfüllt werden. So bietet Global Locate bereits heute einen extrem kleinen und stromsparenden GPS-Chipsatz3 an, der in Mobiltelefone integriert werden könnten. Tatsächlich stellte Invair Technologies auf der CeBIT 2003 ein Smartphone 4 vor, das alle Anforderungen erfüllt. Leider war es uns noch nicht möglich ein derartiges Gerät zu testen. 3 Vom Server bereitgestellte Funktionalität Als zentrales Bindeglied zwischen positionssendendem und positionsabfragendem Benutzer fungiert ein in Java implementierter Server. Dieser verwaltet Positions- und Benutzerdaten sowie die Zugriffsrechte in einer relationalen Datenbank und gewährleistet die Konsistenz dieser Daten. So ist beispielsweise eine Umrechnung der Positionsdaten notwendig, da der positionssendende Benutzer die Daten des GPS-Gerätes in einem anderen Format ausliest als sie später für das Kartenmaterial benötigt werden. Aufgrund der Beschränkungen der J2ME ist eine Umrechnung direkt nach dem Auslesen auf dem mobilen Endgerät nicht sinnvoll möglich. Daneben ist es mangels Serializable-Implementation seitens der J2ME nicht möglich ein GPS-DataPiece5 als Objekt zu übertragen. Daher werden die GPS-DataPieces bzw. Positionsdaten vom Client in einen String konvertiert, welcher über eine Socket-Verbindung an den Server geschickt wird. Dieser trägt die Daten nach erfolgreicher Benutzeridentifikation in die Datenbank ein. Die Stringgenerierung für die Kommunikation folgt einer logischen und leicht erweiterbaren Syntax: [action] × [condition] × [user] × [dataID 1] × [dataRecord 1] × · · · × [dataID i] × [dataRecord i] wobei × als (vorher festgelegtes) Trennzeichen fungiert. Beispielsweise liefert getGdp × latest × ownUserData × UsernameToLocalize die letzte Position eines Benutzers zurück. Damit der Server prüfen kann ob die Berechtigung zur Lokalisierung vorliegt, müssen die eigenen Nutzerdaten mit übertragen werden. 1 Modelle: ESC!, Track Pro NT, Track One NT; http://www.benefon.com/products/ 2 http://www.garmin.com/ 3 http://www.globallocate.com/chip 4 FILEWALKER: http://www.invair.de 5 Datenstruktur, set main.shtml in der die GPS-Daten gespeichert werden Das Einfügen von GPS-DataPieces für den Benutzer ownUserData“ kann beispielsweise ” wie folgt realisiert werden: insertGdp××ownUserData×longitude×12.65×latitude×48.15×. . . Auf eine condition kann dabei verzichtet werden, was durch die beiden direkt aufeinander folgenden Trennzeichen dargestellt wird. Momentan erfolgt die Kommunikation im Testsystem unverschlüsselt. Für den Einsatz in einem Produktivsystem ist eine Verschlüsselung insbesondere der personen- und positionsbezogenen Daten zwingend gefordert. Je nach verwendeter Java Virtual Machine kann es diesbezüglich aber auf den mobilen Geräten zu Problemen kommen. Serverseitig ist eine Verschlüsselung der übertragenen Daten hingegen problemlos möglich. 3.1 Datenbank Der Zugriff auf die Datenbank erfolgt ausschließlich über den Server (vgl. Abbildung 2). Zum einen ist es systembedingt (Verwendung von J2ME ohne plattformabhängige Erweiterungen) technisch nicht möglich, direkt von einem mobilen Gerät auf Datenbanken zuzugreifen. Andererseits ist ein direkter clientseitiger Zugriff aus Gründen der Datenflussund Zugriffskontrolle nicht sinnvoll. Der Server greift über die Standardschnittstelle JDBC auf die Datenbank zu, die Teil der Standard-API von J2SE (Java 2 Standard Edition) ist. Die Abfrage der Datenbank erfolgt somit über Standard-SQL-Anweisungen. Telefon longitude Name ... User [0,*] fordert an [0,*] ... latitude altitude GPS−DataPiece Zeit Adresse username speed Abbildung 2: Ausschnitt aus dem ER-Schema: Anfordern von Positionsdaten Die Datenbank besteht im Kern aus 3 Relationen. Zum einen werden positionsbezogene Informationen gespeichert, welche später vom Server und Client als GPS-DataPieceObjekte verwendet werden. Entsprechende Daten sind die genaue Positionsangabe in Longitude, Altitude und Latitude, der Zeitpunkt, die Geschwindigkeit, der zur Position gehörende Benutzername, der Kurs und zudem der Zeitpunkt, zu welchem die Daten in die Datenbank eingefügt wurden. Letzteres kann genutzt werden, um Zeitunterschiede zwischen Auslesen der Daten aus dem GPS-Gerät und dem Einfügen in die Datenbank festzustellen. Als Primärschlüssel wird der eindeutige Benutzername und die Zeit des GPS-DataPieces verwendet. Dies ist insofern sinnvoll, als dass ein und der selbe Benutzer kaum Positionsdaten zu einer identischen Zeit liefern wird - und wenn doch, ganz offensichtlich ein Fehler im System vorliegt. Zudem werden in der Datenbank sämtliche Nutzerdaten gespeichert, wie Benutzername, Vor- und Nachname, Anschrift und natürlich die Mobilfunknummer. Eine letzte Tabelle enthält die Zugriffrechte der einzelnen Benutzer, wobei aus dieser Tabelle auch die Buddylist“ generiert wird, welche dem Benutzer zeigt, wen er lokalisieren ” darf. 3.2 Zugriffskontrolle und Benutzermanagement Allgemeneinen ist davon auszugehen, dass nicht alle Nutzer eines solchen Services jeden beliebigen Nutzer lokalisieren dürfen. Damit nur berechtigte Benutzer Positionen abfragen oder eintragen können, werden bei jedem Kommunikationsvorgang zwischen Client und Server der eigene Benutzername und das Passwort übermittelt. Der Server überprüft stets, ob der jeweilige Benutzer auch die entsprechenden Rechte besitzt. Ist dies nicht der Fall, bricht der Server die Bearbeitung ab und generiert eine Fehlermeldung. Durch das zustandslose Protokoll vermeiden wir ein aufwändiges Sessionmanagement, welches im Mobilfunkbereich durch häufig wechselnde IP-Adressen zusätzlich verkompliziert würde. 4 Client-Applikationen Wie eingangs erwähnt wurde, bestehen die Möglichkeiten, die Ortung von Nutzern mobiler Endgeräte entweder von einem Desktop-PC oder von einem anderen mobilen Endgerät aus zu realisieren. Im Folgenden werden die beiden Client-Anwendungen vorgestellt. 4.1 Mobiltelefon-Client Für die Umsetzung des Prototyps wurden exemplarisch Mobiltelefone als eine Klasse mobiler Endgeräte genutzt. Prinzipiell ist jedoch eine Portierung der Client-Anwendung auf z.B. PDAs oder Smartphones ohne Probleme möglich, solange diese Geräte die in Abschnitt 2 vorgestellten Anforderungen ausreichend erfüllen. Wahl der Programmiersprache: Eine wichtige Anforderung bei der Wahl der Programmiersprache für die auf dem Mobiltelefon laufende Software war die Kompatibilität. Die Software für das Mobiltelefon sollte möglichst ohne größere Anpassungen auf allen gängigen Mobiltelefonen sowie PDAs lauffähig sein. Daher kamen proprietäre Systeme wie z.B. ExEn von In-Fusio6 für diese Entwicklung nicht in Frage. Nahezu alle neu auf dem Markt erscheinenden Handys und PDAs verfügen jedoch inzwischen über eine eingebaute Java Virtual Machine“. Die Java-Spezifikation unterteilt sich in mehrere Varianten, ” die unterschiedliche Zielgeräte abdecken. Neben dem sehr verbreiteten Standard (J2SE) und der Enterprise Edition (J2EE) bietet Sun für kleine Geräte die Java 2 Micro Edition (J2ME) an. Dieser Standard unterteilt sich je nach Anforderungen in weitere Untergruppen. Die Variante, die auf aktuellen Mobiltelefonen zum Einsatz kommt, ist MIDP, das 6 http://www.in-fusio.com/fond game/technologie games.php Mobile Information Device Profile. Diese verwendet die Kilobyte Virtual Machine (KVM) und begnügt sich mit nur 32 bis 512 kb Arbeitsspeicher. Dieses Mobile Information Device Profile bietet unter anderem Netzwerkunterstützung nach dem HTTP 1.1 Standard, eine graphische Benutzeroberfläche, die sich automatisch den Gegebenheiten des verwendeten Gerätes anpasst sowie die Möglichkeit, Daten permanent zu speichern. Für die Kommunikation mit der GPS-Hardware sind die Java APIs für Bluetooth von Interesse. So wäre es möglich, mit der GPS-Einheit zu kommunizieren wenn diese beispielsweise in dem Akku des Mobiltelefons integriert wäre, was wiederum ein einfaches Nachrüsten der Technik erlauben würde. Die geringen Hardwareanforderungen des MIDP führen jedoch zu Einschränkungen, die bei der Softwareentwicklung zu beachten sind. Da z.B. viele MIDP-unterstützende Geräte über keinen Fließkomma-Prozessor verfügen, können keine Variablen vom Typ float oder double verwendet werden. Installation: Die Installation der Software kann auf zwei Arten geschehen. Entweder wird das Gerät mit einem Computer verbunden, um dann die Software auf das Mobiltelefon oder PDA zu kopieren, oder man verwendet das so genannte Over-the-Air Provisioning“. ” Hierbei wird das MIDlet, so heißen Programme, die dem J2ME-Standard entsprechen, von einem Webserver geladen, was durch aktivieren eines Links auf einer WAP-Seite oder über eine normale HTML-Seite erfolgen kann. Zuerst wird nun nur eine .jad-Datei herunter geladen. Diese enthält unter anderem eine Beschreibung des Programms und die Dateigröße der Software. Anschließend kann der Anwender entscheiden, ob er die komplette Software herunterladen möchte. Diese enthält dann die kompilierten Klassen in einer komprimierten .jar-Datei. Programmbedienung: Nach dem Starten der Software erscheint zuerst das Hauptmenü (siehe Abbildung 3(a)). Unter View Map kann die eigene Position oder auch die Position (a) Hauptmenü (b) Zusatzinformationen (c) Kartendarstellung Abbildung 3: Mobiltelefon-Client von anderen Benutzern des Systems auf einer Karte angezeigt werden. Da die meisten modernen Mobiltelefone und PDAs über ein Farbdisplay verfügen, erfolgt die Kartendarstellung (vgl. Abbildung 3(c)) in Farbe. Auf Wunsch kann ein Fadenkreuz eingeblendet werden, welches die exakte Position darstellt. Unter dem Menüpunkt View details wer- den die Längen- und Breitengrade, der Zoomfaktor, die Breite des Kartenausschnitts, die Höhe über dem Meeresspiegel, die Geschwindigkeit, die Richtung, die Anzahl der aktuell empfangenen Satelliten sowie einige weitere Daten (siehe Abbildung 3(b)) angezeigt bzw. eingestellt. View settings beinhaltet weitere Einstellungen, z.B. zur Aktualisierung der Kartendarstellung basierend auf einem Zeitintervall oder einer minimalen Positionsveränderung. Dadurch wird das übertragene Datenvolumen und somit die Kosten der GPRS Datenübertragung reduziert. Der Menüpunkt Change User beinhaltet die Benutzerverwaltung. Wie schon in Kapitel 3.2 erwähnt, dient sie der Zugriffskontrolle und der Benutzerauthentifizierung. Der Menupunkt Change target ermöglicht - entsprechende Berechtigungen vorausgesetzt - das Anzeigen von Daten anderer Nutzer. Unter Server data werden Einstellungen bezüglich des Servers (z.B. Adresse und Port) vorgenommen. Dementsprechend, ermöglicht Map settings das Festlegen spezieller Parameter für den Zugriff auf den Kartenserver. Der vorletzte Menüpunkt Mobile settings umfasst spezielle Anpassung der Software an das verwendete Endgerät. Dazu gehören die Auflösung und die Farbdarstellung. Normalerweise ist dies aber nicht notwendig, da die Software anhand des Gerätes automatisch kalibriert wird. Der letzte Menüpunkt bietet eine umfangreiche Hilfefunktion. 4.2 Desktop-Client Da mobile Endgeräte oftmals beschränkte Darstellungsmöglichkeiten (Displaygröße) besitzen, können sie nicht alle Details der GPS-Daten sinnvoll gleichzeitig darstellen. Um dieses Problem zu lösen wurde zusätzlich zu dem in Abschnitt 4.1 vorgestellten MobiltelefonClient ein Desktop-Client entwickelt. Wahl der Programmiersprache: Der Desktop-Client ist komplett in Java (JSDK 1.4) programmiert, da so die Plattformunabhängigkeit gewahrt bleibt und der Client auf jedem Computer, der über eine entsprechende Java Virtual Maschine“ verfügt, benutzt werden ” kann. Die graphische Benutzeroberfläche ist in Swing realisiert, wodurch eine leichte und weitgehend intuitive Bedienung möglich ist. Funktionalität: Der Desktop-Client (siehe Abbildung 4) ermöglicht es, die Position von mobilen Endgeräten auf einer Karte anzuzeigen. Für den Betrieb der Software ist eine Anbindung an das Internet erforderlich, da sowohl die Positionsinformationen als auch das Kartenmaterial hierüber bezogen werden. Der Zugriff auf die Positionsdaten erfolgt über das in Kapitel 3 vorgestellte string-basierte Protokoll. Der Zugriff auf das Kartenmaterial ist über HTTP realisiert: Eine einfache, aus dem vom Positionsserver erhaltenen Längen- und Breitengrad zusammengesetzte URL genügt, um dynamisch den jeweils benötigten Kartenausschnitt zu erhalten. Auf diese Anfrage wird dann die Karte im GIFFormat zurückgeliefert. Die Positionen der Nutzer werden dabei vom Kartenserver in das Bild eingefügt, was stets eine optimale Lesbarkeit der Beschriftungen sicherstellt. Hierfür müssen zuvor dem Server in einer gesonderten HTTP-Anfrage die jeweils aktuellen und einzuzeichnenden Positionen der Nutzer mitgeteilt werden. Nach dem Programmstart ist eine Authentifizierung des Nutzers anhand des Nutzernamens und des Kennworts notwendig. Nach erfolgreicher Prüfung der Daten durch den Positions- (a) Detailstufe Region“ ” (b) Detailstufe Straße“ ” Abbildung 4: Desktop-Client server wird die so genannte Buddylist“ übertragen und im Client angezeigt. Diese Liste ” enthält alle Nutzer mobiler Endgeräte, die dem Anwender der Software ein Ortungsrecht eingeräumt haben. Über die Buddylist“ erfolgt die Auswahl der Nutzer, die auf der Karte ” eingezeichnet werden. Dabei ist es möglich, beliebig viele Nutzer gleichzeitig anzuzeigen. Der Zoomfaktor wird automatisch so gewählt, dass alle Nutzer im Kartenausschnitt repräsentiert sind. Zusätzlich zu der Position auf der Karte werden zu den ausgewählten Nutzern statistische Daten in einem Kartenreiter angezeigt. Diese Statistik enthält zum einen Angaben über die aktuelle geographische Position (Längen- und Breitengrad sowie die Höhe über Normal Null). Zum anderen werden auch Angaben über die aktuelle Geschwindigkeit, die aktuelle Bewegungsrichtung und über den Zeitpunkt der letzten Messung angezeigt. Diese Angaben sind alle in Textform gegeben. Zur besseren Übersicht werden Richtung und Geschwindigkeit noch durch eine Windrose dargestellt, bei der mit steigender Geschwindigkeit der Richtungszeiger wächst. Das Zoomen der Karte ist über zwei verschiedene Methoden möglich. Zum einen kann einfach stufenweise herein- oder herausgezoomt werden. Zum anderen ist es möglich, über fünf vorgegebene Detailstufen (Straße, Stadt, Region, Land und Europa) auch bequem in größeren Sprüngen zu zoomen. Über ein Wiedergabe-Modul kann der Nutzer zudem sämtliche auf dem Positionsserver gespeicherte Routen von früheren Zeitpunkten wiedergeben. Hierzu wird die Route vom Server übertragen und in einer gewählten Geschwindigkeit abgespielt. Die Zuordnung der Positionen zu einer Route wird über einen Routennamen geregelt, die der Sender der Position festlegen kann. Alle Positionen mit dem gleichen Routennamen werden dann zu einer Route zusammengefasst. In den Programm-Einstellungen lassen sich Deutsch und Englisch als Programmsprache wählen. Außerdem ist es möglich einen Standard-Nutzer anzulegen, damit die Anmeldung beim Start des Programms vereinfacht wird. 5 Zusammenfassung und Ausblick Die Ortung von mobilen Endgeräten ist eine zwingende Voraussetzung für die Realisierung lokationsbasierter Dienste. Im Rahmen des vorgestellten Projektes wurde ein System entwickelt, das es ermöglicht, die Position eines mit GPS ausgestatteten mobilen Endgerätes zu bestimmen. Dazu wurden neben einem Server, der Positions- und Nutzerinformationen verwaltet, zwei Client-Anwendungen implementiert. Durch diese ist der Zugriff auf die Daten von einem Mobiltelefon bzw. einem Desktop-PC möglich. In dem Papier wurde die Gesamtarchitekur präsentiert und einige Aspekte der Implementierung sowie der Anwendung des Systems erläutert. Bei dem vorgestellten System handelt es sich um einen Prototyp, der noch zahlreiche Punkte für zukünftige Arbeiten offen lässt. Darunter sind u.a. (1) Skalierbarkeit des Servers bei einer großen Anzahl von Nutzern und (2) verschlüsselte Kommunikation zwischen den beteiligten Komponenten. Neben den technischen Fragen, sind Anwendungen ein zentraler Punkt für Anschlussfragestellungen. Wie eingangs erwähnt, soll und wird in erster Linie die Genauigkeit der Lokalisierung des GSM-Schutzengels“ durch die GPS-Ortung ” verbessert werden. Danksagung: Unser Dank gilt der Infineon Technologies AG, der NETSOLUT GmbH sowie der SOS r. AG, welche die Entwicklung durch Geld und Sachmittel unterstützt haben. Literatur [Eri01] Ericson. Ortsbezogene Mobilfunkdienste - Location Based Services, October 2001. http://www.ericsson.de/downloads/pressenews/HintergrundpapierLBS.pdf. [ETS93] ETSI. European digital cellular telecommunications system; Attachment requirements for Global System for Mobile communications (GSM) mobile stations. Technical basis for regulation, European Telecomunications Standards Institute, Sophia Antipolis Cedex, November 1993. [ETS98] ETSI. Digital cellular telecommunications system (Phase 2+) (GSM); G eneral Packet Radio Service (GPRS); Service description; Stage 1 (GSM 02.60 version 6.1.1). European standard (communication series), European Telecomunications Standards Institute, Sophia Antipolis Cedex, November 1998. [ETS99] ETSI. Digital cellular telecommunications system (Phase 2+); Attachment requirements for Global System for Mobile communications (GSM); High Speed Circuit Switched Data (HSCSD) multislot mobile stations; Access (GSM 13.34 version 5.0.3). European standard (communication series), European Telecomunications Standards Institute, Sophia Antipolis Cedex, March 1999. [GBAP03] B. Gipp, J. Beel, F. Alcala, and L. Petersen. Der GSM-Schutzengel... Internetseite, 2003. http://www.gsm-schutzengel.de. [Kap96] E. D. Kaplan. Understanding GPS : Principles and Applications. Artech House Telecommunications Library. Artech House, March 1996. [NET03] NETSOLUT GmbH. Map24 - Online Routenplaner und interaktive Karten für Europa. Internetseite, 2003. http://www.map24.de. [Sun03] Sun Microsystems, Inc. J2ME - Java 2 Platform, Micro Edition. Internetseite, 2003. http://java.sun.com/j2me/. Konzeption eines interaktiven mobilen Reiseinformationssystem Karsten Baumgarten und Christoph Gollmick Friedrich-Schiller-Universität Jena, Institut für Informatik Ernst-Abbe-Platz 2, 07743 Jena {ishino,gollmick}@informatik.uni-jena.de Kurzfassung: Im Bereich der datenbankgestützten Informationssysteme eröffnet sich durch die Mobilität der Nutzer ein weites Spektrum an interessanten neuen Anwendungsmöglichkeiten. Im vorliegenden Beitrag wird das Konzept eines datenbankgestützten interaktiven mobilen Reiseinformationssystems vorgestellt, das den (mobilen) Nutzer bei der Erfassung und Wartung seines Datenbestandes mit einbezieht. 1 Einführung Mit der Entwicklung leistungsfähiger mobiler Geräte und drahtloser Kommunikationsverfahren entstand ein vollkommen neues Anwenderprofil - der mobile Nutzer. Damit begann zugleich auch die Suche nach attraktiven Anwendungen für diese Zielgruppe. Zu den wichtigsten Anwendungsmöglichkeiten gehören die datenbankgestützten Informationssysteme. Zwei Beispiele dafür sind eine Anwendung für den Katastrophenschutz [AZ03], bei der u. a. Helfer vor Ort mit mobilen Geräten Informationen sammeln und über eine Datenbank anderen Nutzern zur Verfügung stellen oder eine Anwendung für Service-Techniker, die vor Ort Zusatzinformationen wie Schaltpläne oder Bedienungsanleitungen für ihren Auftrag aus einer Datenbank herunterladen. Wir stellen hier das Konzept des datenbankgestützten interaktiven mobilen Reiseinformationssystems H ERMES vor [Bau03]. Im Unterschied zu klassischen Touristenführern sind die mobilen Nutzer aktiv an der Erfassung der Daten und Wartung der Datenbank beteiligt. In diesem Beitrag werden neben einer allgemeinen Beschreibung von H ERMES die angebotenen Informationen und das daraus resultierende Datenmodell angegeben. Anhand eines Beispiels werden wir abschließend die Arbeitsweise mit dem Reiseinformationssystem verdeutlichen. 2 Überblick Das Reiseinformationssystem soll seinen Nutzern (u. a.) Informationen über Ortschaften und darin befindliche Sehenswürdigkeiten, Hotels und gastronomische Einrichtungen zur Verfügung stellen. Damit soll es die Nutzer in zwei Hinsichten unterstützen. Zum einen als Informationsquelle für die Reiseplanung, zum anderen als eine Art „elektronischer Reisebegleiter“, der einen Nutzer an Ort und Stelle mit Informationen zum derzeitigen Aufenthaltsort versorgen kann. Im Unterschied zu klassischen Touristenführern werden die dafür notwendigen Informationen jedoch nur zu einem kleinen Teil zentral bereit gestellt. Vielmehr werden die Nutzer am Aufbau und an der Pflege des Datenbestandes beteiligt. Sie sollen die Informationen vor Ort sammeln, auf ihren mobilen Geräten zwischenspeichern und letztlich dem H ERMES-Server zur Verfügung stellen. Neben den Basisinformationen können die Nutzer auch durch das Verfassen von Reiseberichten und der Definition interessanter Reiserouten (innerhalb einer Ortschaft oder auch zwischen verschiedenen Orten) das Informationsangebot ergänzen. Weiterhin verfügt H ERMES über ein einfaches Bewertungssystem. Die Nutzer können damit bestimmte Merkmale einer Ortschaft, eines Restaurants, o.ä. durch die Vergabe von Noten bewerten. Zusammenfassend beinhaltet die Mitwirkung der Nutzer am Aufbau des Informationsangebotes die folgenden Vor- und Nachteile: + Die Attraktivität des Reiseinformationssystems für die Nutzer (und damit auch seine Akzeptanz) werden gefördert, denn jeder kann durch seinen eigenen Beitrag zu einem „Teil des Projektes“ werden. + Da das Informationsangebot zu einem großen Teil durch die Nutzer selbst erstellt wird kann man davon ausgehen, daß es auch deren Interessen entspricht. Somit erreicht man einen Relevanzgrad für die angebotenen Informationen, der mit ausschließlich zentral zur Verfügung gestellten Daten kaum möglich wäre. + Der erhebliche Aufwand für die Beschaffung der Informationen wird (größtenteils) auf die Nutzer verteilt. Durch die Dezentralisierung wird der Beschaffungsaufwand für den Anbieter des Informationsdienstes minimiert. + Es wird ein hoher Grad an Vollständigkeit und Aktualität der angebotenen Informationen erreicht, − . . . eine hohe Zahl von motivierten und ausreichend geographisch verteilten Nutzern voraussetzt. − Von den Nutzern erstellte Informationen sind möglicherweise fehlerhaft oder unvollständig. Sie müssen deshalb auf inhaltliche Richtigkeit und Vollständigkeit überprüft werden. Das ist nur schwer automatisierbar, muß also u.U. manuell auf Seiten des Anbieters erfolgen. 2.1 Nutzergruppen Um den Nachteil manueller Korrekturen auf Anbieterseite zu vermeiden, können wir die Nutzer in den Korrekturprozeß einbeziehen. Angelehnt an die Struktur vieler Newsgroups und Foren im Internet werden die Nutzer dazu in zwei verschiedene Klassen unterteilt. Das sind zum einen die „normalen“ Nutzer der Anwendung, zum anderen so genannte „Superuser“ oder Administratoren, deren wichtigste Funktion die manuelle Überprüfung der durch andere Nutzer eingebrachten Daten ist. 2.2 Phasen der Nutzung Durch hohe Kosten und eingeschränkte Verfügbarkeit drahtloser Kommunikationsmöglichkeiten ergibt sich die Anforderung, die notwendige Online-Zeit mobiler Geräte bei der Benutzung von H ERMES so kurz wie möglich zu halten. Wir legen deshalb der Arbeit mit der H ERMES-Client-Anwendung den in Abbildung 1 skizzierten Ablauf zugrunde. Replikat(re)definition unverbundene Tätigkeit Reintegration Rückübertragung Synchronisation Abbildung 1: Zeitweise unverbundenes Arbeiten mit einem mobilen Client Über die Anwendung spezifiziert der mobile Nutzer zunächst die Daten, mit denen er später im unverbundenen Zustand arbeiten will (Replikatdefinition, z. B. Städteinformationen, interessante Reiseberichte). Gleichzeitig werden dabei die gewünschten Verwendungsrechte für den unverbundenen Zustand (nur lesender Zugriff, lesender/schreibender Zugriff) festgelegt. Nach der eventuell notwendigen Reintegration vorher lokal durchgeführter Änderungen werden die angeforderten neuen Daten plus Aktualisierungen bereits vorhandener Daten auf den mobilen Client übertragen (Rückübertragung). Es folgt die Phase der Unverbundenheit, in der replizierte Daten durch die Nutzer gelesen und bearbeitet werden können. Mit einer erneuten Replikatdefinition oder der Synchronisation der Daten wird der Zyklus fortgesetzt. 2.3 Unverbundenes Arbeiten Die Grundlage des zeitweisen unverbundenen Arbeitens ist ein Dienst zur Replikation, also zur konsistenten Verwaltung von lokalen Kopien der Daten, die im zentralen Datenbanksystem gespeichert sind [HHB96]. Dies setzt das Vorhandensein eines geeigneten Client-Datenbanksystems voraus, wovon wir im Folgenden ausgehen wollen, da es bereits eine Reihe etablierter Datenbanklösungen namhafter Hersteller für den replizierenden mobilen Datenbankzugriff gibt [Fan00]. Für die Umsetzung von H ERMES reichen die bisher gebotenen Fähigkeiten aber nicht aus. Benötigt werden zusätzlich: • eine nutzer- bzw. anwendungsgesteuerte Replikation von Daten • verbesserte automatische Konfliktbehandlungsmethoden und Unterstützung der Nutzer bei der Konfliktlösung • eine flexible Nutzerverwaltung und inhaltsbasierte Zugriffsrechte • eine skalierbare Infrastruktur für eine große Nutzerzahl Zur Realisierung des unverbundenen Arbeitens bei H ERMES und verwandten Anwendungen wurde ein Dienst zur nutzerdefinierten Replikation (NR) relationaler Datenbankinhalte entwickelt, der auf einer vorhandenen mobilen Client/Server-Datenbankumgebung aufsetzt [Gol03, Lie03]. Unter anderem stellt die NR dem Anwendungsprogrammierer eine an SQL angelehnte deskriptive Schnittstelle zur dynamischen Anforderung und Anpassung von Replikaten und die Konfliktbehandlung zur Verfügung. Wie das funktioniert, sehen wir in Abschnitt 6. 2.4 Zugrundeliegende Infrastruktur Mobiler Client H ERMES-Client lokales Server Replikations− / Synchronisations− anforderung Daten/Updates Replication Proxy asynchrone Server Datensätze zentrales DBS DBS externe Quelle Abbildung 2: Architektur eines datenbankunterstützten mobilen Informationssystems Als datenbankgestütztes Informationssystem basiert H ERMES auf einer Client/Server-Architektur, erweitert um die Möglichkeit des unverbundenen Arbeitens auf einem lokalen DBS des Client. Die von H ERMES verwendete und in [Mül03] spezifizierte Architektur ist in Abbildung 2 dargestellt. Sie besteht aus einem zentralen Datenbankserver, einem oder mehreren mobilen Clients und mindestens einem zwischengeschalteten sogenannten Replication Proxy Server (RPS). Auf dem zentralen Datenbankserver ist das gesamte Informationsangebot von H ERMES gespeichert. Der RPS speichert die, von einem Replikationsadministrator für die Replikation freigegebenen, Daten nochmals lokal und stellt sie den mobilen Clients für die Replikation zur Verfügung. Er übernimmt innerhalb der Architektur zusätzlich die folgenden Aufgaben: • Abwicklung der drahtlosen Kommunikation mit den mobilen Clients • Verwaltung der mobilen Nutzer und inhaltsbasierter Zugriffsrechte • Verarbeitung der Replikations- und Synchronisationsanfragen der mobilen Clients • Behandlung von Änderungskonflikten In die Architektur können gegebenenfalls externe Quellen aufgenommen werden, wie es auch in Abbildung 2 der Fall ist. Der RPS kann von ihnen beispielsweise statistische Angaben zu den Ortschaften oder geographischen Daten beziehen (z.B. für eine automatische Ortsbestimmung). 3 Funktionalität 3.1 Funktionen des H ERMES-Client Das Kernelement der Anwendung auf dem mobilen Client ist der Auswahlkatalog. Er besteht aus einer graphischen Oberfläche, die dem Nutzer verschiedene Funktionen zugänglich macht. Dazu gehört u. a. eine Übersicht über das im System und davon bereits lokal vorhandene Informationsangebot. Es wird also z.B. angezeigt, das die Öffnungszeiten von Restaurants in einer Ortschaft zum Informationsbestand von H ERMES gehören. Bereits lokal vorhandene Daten (von früheren Replikationsprozessen) werden besonders gekennzeichnet. Der Nutzer kann so erkennen, welche Daten bereits zum Lesen oder Bearbeiten zur Verfügung stehen. Mit Hilfe des Auswahlkatalogs kann der Anwender Daten zur Replikation auswählen. Die Anwender von H ERMES benötigen normalerweise keine vollständige Kopie des zentralen Informationsbestandes. In der Regel werden nur solche Daten vom Server angefordert, die während des Aufenthalts in den geplanten Reisezielen auch tatsächlich benötigt werden. Möglicherweise zunächst auch nur einen Teil davon, mit der Option später weitere hinzukommen zu lassen, wenn die bereits vorhandenen Daten unzureichend sind. Die Aktualisierung replizierter Daten gehört ebenfalls zu den grundlegenden Funktionen der Anwendung auf dem mobilen Client. Dabei werden bereits replizierte Daten mit den aktuellen Versionen der H ERMES-Datenbank verglichen und ggf. auf Veranlassung des Nutzers aktualisiert. Bei der Synchronisierung können eine Reihe von Konflikten auftreten, die sich aus dem parallelen Arbeiten von H ERMES-Nutzern mit den selben Daten ergeben. Hier sind den Daten und der Situation angepaßte Konfliktbehandlungsmethoden einzusetzen. Sowohl die Replikatauswahl als auch die Synchronisation inklusive Konfliktbehandlung werden über entsprechende Dienste der nutzerdefinierten Replikation durchgeführt. Das bereits angesprochene Bewertungssystem soll dem Nutzer zunächst einen schnellen Überblick über die Qualität eines ausgewählten Reiseziels ermöglichen. Weiterhin wird damit eine gezielte Suche nach bestimmten Ortschaften ermöglicht, indem der Nutzer entsprechende Kriterien für Mindestnoten bestimmter Eigenschaften des Ortes angibt. 3.2 Funktionen des RPS als H ERMES-Server Für die Realisierung des interaktiven Reiseinformationssystems muß der RPS neben der nutzerdefinierten Replikation einige zusätzliche Funktionen bereitstellen. Dazu gehören Zusatzinformationen über die von einem Nutzer angeforderten Daten, wie Angaben zum Umfang und der voraussichtlichen Übertragungsdauer. Auch sind Angaben über eine ge- schätzte Gültigkeitsdauer (bei auf dem Server bekannter Änderungshäufigkeit) angeforderter Daten hilfreich, um der Anwendung zu ermöglichen den Nutzer auf eine eventuell notwendige Synchronisation hinzuweisen. 4 Informationsangebot Eine wesentliche Zielstellung des Reiseinformationssystems ist ein möglichst umfassendes Angebot an Informationen, die für einen Nutzer während seiner Reiseplanung bzw. während des Aufenthalts an einem Reiseziel von Bedeutung sind. Bei der Erarbeitung von H ERMES als Beispielszenario haben wir uns auf einige wesentliche, im Folgenden beschriebene Informationen beschränkt. Das Angebot kann jedoch für einen späteren praktischen Einsatz sehr leicht erweitert werden. 4.1 Informationsquellen Die Idee des interaktiven Reiseinformationssystems lebt von der Mitwirkung der Nutzer beim Aufbau und der Pflege des Datenbestandes. Einige Teilbereiche des Informationsangebotes sind davon jedoch ausgenommen. So werden durch H ERMES alle Daten zu den Regionen (z. B. Bundesländer oder auch Landschaftsbezeichnungen) sowie die grundlegenden Informationen für alle Ortschaften bereit gestellt. Diese Daten, im Folgenden als Basisdaten bezeichnet, sind durch die Nutzer grundsätzlich nicht änderbar. Sie können leicht aus externen Quellen bezogen und praktisch ohne weitere inhaltliche Prüfung in den zentralen Datenbestand integriert werden. Der größte Teil des Informationsangebotes basiert auf nutzerdefinierten Daten. Dazu gehören u. a. Daten zu den Gebäuden (z. B. Sehenswürdigkeiten, Hotels) einer Ortschaft und natürlich die Reiseberichte. Prinzipiell könnte der Anbieter des Reiseinformationssystems alle Basisdaten bereitstellen, das System „sich selbst überlassen“ und alle Änderungen/Erweiterungen des Datenbestandes seinen Nutzern überlassen. Vor allem in der Startphase, in der H ERMES nur wenige Nutzer hat, ist dieses Vorgehen aber ungünstig, weil nur wenige Informationen durch die Nutzer erstellt werden und das System deshalb nur sehr langsam ein umfangreiches Angebot aufbaut. Aus diesem Grund sollten nutzerdefinierte Daten nicht ausschließlich durch die Nutzer erstellt, sondern auch durch den Anbieter ständig ergänzt und erweitert werden. 4.2 Informationsgruppen Gruppe Zusammensetzung Allgemeine Daten Statistische Daten Historische Informationen Bewertungen Name, PLZ Einwohnerzahl Historie Besuchswert, Kulturangebot Abbildung 3: Informationsgruppen für Ortschaften Damit ein Anwender bei seiner Informationsauswahl aus dem H ERMES-Katalog nicht jedes einzelne Attribut einer Informationskategorie (z. B. Ortschaft) betrachten muß, dann über die Notwendigkeit des Kopierens in die eigene Datenbank entscheiden und schließlich auch noch mögliche Abhängigkeiten zwischen den Teilinformationen beachten muß, gliedern wir die Gesamtinformation für eine Informationskategorie aus dem Informationsangebot in eine Menge von Informationsgruppen. Diese fassen jeweils semantisch zusammengehörende Attribute zusammen, wobei die Aufteilung einer Informationskategorie in ihre Gruppen vollständig und disjunkt erfolgt. Die Nutzer können ihre benötigten Informationen dann durch eine Auswahl aus den verschiedenen Informationsgruppen zusammenstellen. Abbildung 3 zeigt am Beispiel der Kategorie „Ortschaft“ die Aufteilung in Informationsgruppen. 5 Datenbankentwurf Die Speicherung der H ERMES-Daten in der zentralen Datenbank folgt dem relationalen Datenmodell. Das E/R-Diagramm der Datenbank ist in Abbildung 4 angegeben. Es enthält alle Entitäts- und Beziehungstypen, die sich aus dem Informationsangebot von H ERMES ergeben. Die Beziehungen zwischen den einzelnen Entitätstypen sind durchnumeriert, um eine bessere Übersichtlichkeit zu erreichen. Das Schema der Datenbank folgt den allgemeinen Regeln für die Übertragung von E/R-Modellen in Relationenschemata. Zusätzlich wurde bei der Bildung der Tabellen die Einteilung in Informationsgruppen berücksichtigt, indem jede Gruppe in eine separate Tabelle übersetzt wurde. 6 Beispiel und Realisierung Anhand eines Beispiels soll im Folgenden der Arbeitsablauf und die Verwendung der nutzerdefinierten Replikation verdeutlicht werden. Wir stellen einen vollständigen Durchlauf durch den Arbeitsablauf von H ERMES dar, wie er auch bei Verwendung der Anwendung in der Praxis vorkommen könnte. Dabei beschränken wir uns auf die Angabe der für die Replikation wichtigen Anweisungen. Zu den einzelnen Schritten ist jeweils der Verbindungszustand zwischen Client und RPS vermerkt, der für die Durchführung der angegebenen Operation notwendig ist ( online oder offline ). 1. online einmaliges Anlegen einer Replikationssicht 1 für Regionsdaten CREATE REPLICATION VIEW RegionDescription FOR REPLICA DATABASE locHERMES AS SELECT * FROM Region INTO REPLICATION VIEW GROUP RegionsGrp; SYNCHRONIZE REPLICATION VIEW GROUP RegionsGrp OF REPLICA DATABASE locHERMES; 1 Eine Replikationssicht dient bei der NR zur Definition der Daten, die unverbunden verfügbar sein sollen. Abbildung 4: E/R-Modell: Übersicht 6 Kommentar (1,1) (0,*) EssenTrinken 5 (1,1) Saison (0,*) Zimmer 4 Gastronomie 3 (1,1) (1,*) Hotel Oeffnungszeiten (1,1) 9 Reisebericht (0,1) (0,1) 10 (1,7) (0,*) 1 2 KultEinr (p,d) Gebaeude (1,1) (0,*) Ortschaft (1,*) (0,*) Region (0,*) (0,*) (0,*) 11 HistGeb 8 7 Position 1 − umfasst 2 − enthaelt 3 − hat 4 − bietet_an 5 − gibt_aus RouteOrtschaften Position (2,*) (v,d) Route (0,*) SozEinr (2,*) 6 − wird_ergaenzt_durch 7 − besitzt 8 − gehoert_zu 9 − beschreibt_Route 10 − beschreibt_Ort 11 − ist_enthalten_in (1,1) RouteInnerorts 2. offline Auswahl eines Regionstyps durch den Nutzer (aus einer Liste) → Bundesland 3. offline Auswahl eines oder mehrerer Regionsnamen(s) durch den Nutzer → Thüringen 4. online Anfordern der Daten für Regionen und Ortschaften CREATE REPLICATION VIEW City FOR REPLICA DATABASE locHERMES AS SELECT o.Name, o.PLZ, r.Name FROM Ortschaft o, Region_Orte r WHERE o.ONr = r.ONr AND r.Name IN (’Thueringen’) INTO REPLICATION VIEW GROUP CityGrp; SYNCHRONIZE REPLICATION VIEW GROUP CityGrp FOR REPLICA DATABASE locHERMES; 5. offline Auswahl gewünschter Ortschaften durch den Nutzer 6. offline Auswahl benötigter Informationsgruppen (a) Informationsgruppen, die für alle ausgewählten Orte repliziert werden sollen (b) Informationsgruppen für bestimmte Orte (c) wenn benötigt: Anforderung von Änderungsrechten 7. online Replikation der ausgewählten Informationsgruppen → historische Daten von Jena zum Ändern (optimistische Replikation [HHB96]). (a) Anlegen einer Sichtengruppe 2 für die Ortschaft CREATE REPLICATION VIEW GROUP City_A FOR REPLICA DATABASE locHERMES; (b) Anlegen der Replikationssicht für die historischen Daten und Synchronisation CREATE REPLICATION VIEW City_A_History FOR REPLICA DATABASE locHERMES AS SELECT * FROM Ortschaft_Historie WHERE ONr = (SELECT ONr FROM Ortschaft WHERE Name = ’Jena’) INTO REPLICATION VIEW GROUP City_A FOR OFFLINE MODIFICATION; SYNCHRONIZE REPLICATION VIEW GROUP City_A FOR REPLICA DATABASE locHERMES; 8. offline unverbundenes Arbeiten mit den replizierten Daten 2 Replikationssichtengruppen Daten einer Ortschaft. sind für die gemeinsame Synchronisation von Daten verantwortlich, z. B. aller Daten werden bei CREATE REPLICATION VIEW standardmäßig nur für den lesenden Zugriff repliziert. Bei der Replikationssicht City_A_History wurde die Änderbarkeit explizit gefordert. Zu beachten ist hier jedoch, daß der RPS nicht notwendigerweise die Schreibrechte für die Daten gewähren muß (exklusive Änderungsrechte an anderen Nutzer vergeben, fehlende Berechtigung des Nutzers, etc.). Es ist auch möglich Replikationssichten zunächst nur für den lesenden Zugriff zu fordern und erst später über eine ALTER REPLICATION VIEW-Anweisung das Änderungsrecht hinzuzufügen. 7 Zusammenfassung und Ausblick Das erarbeitete und hier vorgestellte Konzept eines interaktiven mobilen Reiseinformationssystems enthält zur Zeit die detailierte Beschreibung des Informationsangebots (Umfang jederzeit erweiterbar), den Datenbankentwurf, Beispieldaten sowie Ablaufschema für die Arbeit mit der Client-Anwendung. Noch zu spezifizieren sind die Nutzerverwaltung sowie eine geeignete (inhaltsbasierte) Rechtevergabe, die für die Realisierung der Bewertung und der Nutzeradministratoren notwendig sind. Beides wird in der zur Zeit laufenden prototypischen Umsetzung eines Replication Proxy Server und H ERMES-Client in Angriff genommen. Literaturverzeichnis [AZ03] R. Leiner A. Zipf. Anforderungen an mobile Geo-Datenbanken für Katastropheninformations- und warnsysteme. In Tagungsband zum Workshop Workshop Scalability, Persistence, Transactions - Database Mechanisms for Mobile Applications, Karlsruhe, Interner Bericht 2003-5. Fakultät für Informatik, Universität Karlsruhe, April 2003. [Bau03] K. Baumgarten. Konzeption und Schemaentwurf eines interaktiven mobilen Reiseinformationssystems. Studienarbeit, Institut für Informatik, Friedrich-Schiller-Universität Jena, Juli 2003. [Fan00] T. Fanghänel. Vergleich und Bewertung kommerzieller mobiler Datenbanksysteme. Studienarbeit, Institut für Informatik, Friedrich-Schiller-Universität Jena, September 2000. [Gol03] C. Gollmick. Nutzerdefinierte Replikation zur Realisierung neuer mobiler Datenbankanwendungen. In Tagungsband der 10. GI-Fachtagung Datenbanksysteme für Business, Technologie und Web (BTW), Leipzig, Band P-26 aus Lecture Notes in Informatics (LNI), Seiten 453–462, Februar 2003. [HHB96] A. Helal, A. Heddaya und B. Bhargava. Replication Techniques in Distributed Systems. Kluwer Academic Publishers, August 1996. [Lie03] M. Liebisch. Synchronisationskonflikte beim mobilen Datenbankzugriff: Vermeidung, Erkennung, Behandlung. Diplomarbeit, Institut für Informatik, Friedrich-Schiller-Universität Jena, Februar 2003. [Mül03] T. Müller. Architektur und Realisierung eines Replication Proxy Server zur unterstützung neuartiger mobiler Datenbankanwendungen. Diplomarbeit, Institut für Informatik, Friedrich-Schiller-Universität Jena, April 2003. Vision mobiler Geodienste* Martin Breunig1, Rainer Malaka2, Wolfgang Reinhardt3, Joachim Wiesel4 1 Forschungszentrum für Geoinformatik und Fernerkundung (FZG) Hochschule Vechta Postfach 1553, D-49364 Vechta E-mail: [email protected] 2 European Media Laboratory GmbH Villa Bosch, Schloss-Wolfsbrunnenweg 33 D-69118 Heidelberg E-mail: [email protected] 3 Universität der Bundeswehr München Arbeitsgemeinschaft Geoinformationssysteme (AGIS) Werner-Heisenberg-Weg 39, D-85577 München E-mail: [email protected] 4 Institut für Photogrammetrie und Fernerkundung (IPF) Universität Karlsruhe Englerstr. 7, D-76128 Karlsruhe E-Mail: [email protected] Abstract: Neben dem Gesundheitswesen und den Navigationssystemen scheinen die Geowissenschaften mit ihren inhärent lokationsabhängigen 2D-, 3D- und „4D“Anwendungen ein ideales Areal für Experimente der mobilen Informationsverarbeitung darzustellen. Die Verbindung des Internets mit mobilen Kommunikationstechnologien eröffnet zudem erstmalig die Perspektive ubiquitärer Zugriffe auf in verschiedensten Institutionen verteilt erhobene und verwaltete Geodatenbestände. Moderne Geodienste können somit zu einer schnellen Verfügbarkeit und steigenden Qualität von Informationen über unsere Umwelt beitragen. Diese Dienste sind so zu gestalten, dass sie in internet-basierten Netzwerken von mobilen Anwendungen genutzt werden können. Neben dem wichtigen Aspekt der Datenverwaltung für Geodienste spielen hier die mobile Erfassung, Visualisierung und Analyse mehrdimensionaler Geodaten eine wesentliche Rolle. In diesem Kurzbeitrag wird die Vision des anwendungsorientierten BMBF-Verbundprojektes „Weiterentwicklung von Geodiensten” im Rahmen des Forschungsschwerpunktes „Geotechnologien: Informationssysteme im Erdmanagement” vorgestellt. Das diesem Artikel zugrundeliegende Vorhaben „Weiterentwicklung von Geodiensten“ (http://www.geoservices.fzg.uni-vechta.de) wird mit Mitteln des Bundesministeriums für Bildung und Forschung unter den Förderkennzeichen 03F0373B et al. gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren. 1 Die Vision Neuartige, mobil verfügbare Geodienste werden Geowissenschaftlern in Zukunft helfen die Erfassung, Modifikation und Visualisierung unterirdischer Planungsvorhaben oder geologischer Formationen direkt im Gelände durchzuführen, unterstützt durch ein leistungsfähiges Geodatenbanksystem und moderne Augmented Reality Methoden [Müll01]. Das Potential und die Anforderungen geowissenschaftlicher Informationssysteme an die Datenbankforschung wurde kürzlich schon in [SABK03] dargestellt. In unserer Vision einer neuen Generation von Geodiensten verfolgen wir die folgenden Ziele: Die mobile Erfassung und das Update von Geodaten durch Sensoren vor Ort sowie die Visualisierung von mit dem Auge nicht sichtbarer von einem Datenbanksystem verwalteter Objekte im geologischen Untergrund. Durch Techniken der Augmented Reality (AR) soll der Geowissenschaftler bzw. Ingenieurgeologe in die Lage versetzt werden, die Planung hydrogeologischer Prozesse und den Zustand von Bauwerken wie Staudämmen einschließlich des geologischen Untergrunds als 3D-Modell zu verfolgen und fortzuführen. Durch ein leistungsfähiges Geodatenbanksystem soll die Abspeicherung und der räumliche Zugriff auf kleine 3D-Teilbereiche problemlos möglich sein und die Ergebnisse von raum- und zeitbezogenen Datenbank-Abfragen (2D/3D/4DAbfragen) mithilfe eines mobilen Augmented Reality Clients visualisiert werden können. Die im Geodatenbanksystem durchgeführte Berechnung der Projektion von Objekten im dreidimensionalen Raum auf die Ebene (Profilschnitte) und deren Visualsierung (2D) kommt dabei dem augenblicklichen Stand der Technik für kleine mobile Endgeräte entgegen. Schließlich soll in einer verteilten Servicearchitektur die Komposition verschiedener Geodienste für die Erfassung, Verwaltung, Visualisierung und Analyse von Geodaten bausteinartig nach Bedarf der jeweiligen Anwendung zugeschnitten werden können. Hierbei gilt es aus Anwendersicht eine für den geowissenschaftlichen Experten möglichst mit wenig Programmieraufwand realisierbare Lösung zu schaffen, in der bereits vorgefertigte Frames für die Visualisierung (2D/3D-Elemente) und die Typen von Datenbankabfragen nur noch an die jeweilige spezielle Anwendung angepasst werden müssen. In unserer Vision sollen die verschiedenen Operationen der Geodienste über eine leistungsfähige Kommunikationsschicht von mobilen Clients angesteuert und leicht durch weitere internet-basierte Dienste ergänzt werden können. Hierbei gilt es die Grenzen bisheriger Standardisierungsbemühungen wie die über http realisierte Web-Services des Open GIS Consortiums [OGC03] zu untersuchen und Alternativen bzw. Erweiterungen aufzuzeigen. Die Entwicklung einer neuen Generation mobiler Geodienste wird sowohl der Datenbankforschung als neues und interessantes Anwendungsgebiet dienen als auch die Geowissenschaften durch neue Möglichkeiten der Informationsverarbeitung darin unterstützen, fachspezifische Fragestellungen zur Förderung einer nachhaltigen Umwelt effizient und qualitativ auf hohem Niveau zu bearbeiten. 2 Anwendungsfelder Der Bedarf an einem mobilen Geodatenmanagement und an der mobilen Datenerfassung ist in allen Geowissenschaften vorhanden ([Bund01] [SABK03]). Anwendungsfelder sind überall dort zu sehen, wo mobile Geräte (z.B. zur Bearbeitung geologischer Strukturen, Bodenqualität, DGM, Planungsvorhaben, rechtlicher Grenzen, Leitungen im Untergrund etc.) die Datenerfassung verbessern können: • Die Übertragung von aktuellen Messwerten in entfernte Datenbanken beispielsweise bei der Hochwasseranalyse dient zum einen einer direkten Nutzbarmachung für Anwender, zum anderen können neue Messwerte direkt weiterverarbeitet und die Ergebnisse dieser Datenprozessierung für die Feldarbeit genutzt werden. Hoch aktuelle Daten stehen jederzeit zur Verfügung und können im Feld direkt abgerufen werden. • In der umgekehrten Richtung stehen dem Anwender beispielsweise für die hydrogeologische Modellierung im freien Feld eine Vielzahl von Daten und Informationen zur Verfügung. Er ist nicht gezwungen, alle eventuell notwendigen Datensätze mit ins Feld zu nehmen, sondern kann vor Ort entscheiden, welche Daten er benötigt. Die Ergebnisse können direkt in die weitere Messpunktwahl mit einfließen, ohne dass der Erfassungsvorgang unterbrochen werden müsste. • Die Integration verschiedener Software in eine Geodateninfrastruktur ermöglicht es schließlich, vor Ort zusätzliche Informationen zu erhalten, ohne dass deren genaue Herkunft bekannt wäre. Ein Anwender bei der geologischen Vermessung, der aufgrund einer äußerst komplexen Geländemorphologie oder fehlender Geländeaufschlüsse Schwierigkeiten hat, die genaue Lage und Ausprägung von einzelnen Schichten zu erfassen, kann im Bedarfsfall seine automatisch erfasste Position gegen einen spezialisierten Dienst schicken, der aus den Datenbanken die entsprechenden Informationen und Kartenausschnitte zusammenstellt und an den Client überträgt. Darüberhinaus sind Nachteile einer mobilen Geodatenverarbeitung zu untersuchen, wie beispielsweise zusätzlich enstehende Übertragungskosten. 3 Kurzbeschreibung der Projektknoten Die Projektknoten aus München, Heidelberg, Karlsruhe und Vechta teilen sich die zu bewältigenden Aufgaben auf dem Weg zur Vision wie folgt auf: • Mobile Erfassung, Aktualisierung, Nutzung/Analyse und Visualisierung von Geodaten (München/Heidelberg); • Online-Darstellung, Bearbeitung und Erfassung von 3D-Datenbeständen auf einem mobilen Endgerät unter Einsatz von „Augmented Reality- AR“ (Karlsruhe); • Definition von standardisierten Schnittstellen für Geodienste (München); • Entwicklung webfähiger GIS-Komponenten für den Zugriff auf raum-zeitliche Objekte in Geodatenbank-Diensten (Vechta). Bei allen Aufgaben wird besonderes Augenmerk auf methodische Untersuchungen gelegt, die dazu dienen die neuen Technologien optimal für hydro- und ingenieurgeologische Arbeitsabläufe zu nutzen. 3.1 Knoten München/Heidelberg: „Entwicklung der mobilen Komponente und der Schnittstellen zu Geodiensten“ Im Rahmen dieses bei der AGIS der Universität der Bundeswehr München und der European Media Laboratory GmbH (EML) in Heidelberg angesiedelten Projektes soll ein Konzept und ein Prototyp für eine mobile Client-Komponente zur Verarbeitung von Geodaten entwickelt werden. Die wesentlichen Punkte dieses Teils sind: • Erstellung eines Konzeptes zur Mobilen Erfassung, wobei die Möglichkeit des Online Zugriffes auf verschiedene Datenserver über mobile Netzwerke und deren Leistungsparameter besonders zu berücksichtigen ist. Dabei soll die Datenkonsistenz bei der Datenkommunikation zwischen Server und mobilem Endgerät untersucht und die Möglichkeit der systemunterstützten Datenerfassung berücksichtigt werden. Insgesamt ist für diese mobile Erfassung ein umfassendes Qualitätsmanagementkonzept zu erarbeiten. • Die Erfassung des Datenmaterials im freien Feld erfolgt unter Nutzung von Messgeräten mit digitalem Ausgang wie auch mit manuell auszuwertenden Messinstrumenten. Das manuelle Auswerten wird durch die automatisch generierten grafischen Oberflächen auf den mobilen Endgeräten unterstützt. Als mögliche Sensoren kommen beispielsweise GPS-Empfänger, Tachymeter, Digitalkameras, Seismographen usw. in Frage. Dabei sollen die erfassten Daten sofort der Anwendung zur Verfügung stehen [Rein01]. Zu diesen Erfassungskomponenten sind Schnittstellen zu definieren. • Definition von Schnittstellen für den On-line Zugriff auf die vom Server bereitgestellten Dienste sowie auf die Daten. Bei der Definition von Schnittstellen sind die entsprechenden internationalen Standards zu berücksichtigen. Die bereits verabschiedeten bzw. in Bearbeitung befindlichen Spezifikationen des OpenGIS Konsortiums [OGC03] zum Datenzugriff und –management (Data Services: Feature Service und Coverage Service), zur Recherche von Geodaten (Catalog Service), zum Datenaustauschformat (GML) und zur Visualisierung von Geodaten (Mapping Service) berücksichtigen die speziellen Anforderungen mobiler Clients bisher nicht, wie etwa die optimale Bereitstellung von Informationen bei geringen Übertragungsraten. Sie sollen im Rahmen dieses Forschungsvorhabens diesbezüglich untersucht bzw. weiterentwickelt werden. Zusätzlich sind die im aktuellen vom OpenGIS Konsortium veranstalteten LBS-testbed bearbeiteten Services (Location Services) sowie die Location Application Servers und Location Data Servers auf ihre praktische Nutzbarkeit im Bereich wissenschaftlicher GeoFragestellungen kritisch zu prüfen und weiterzuentwickeln [CJM00]. 3.2 Knoten Karlsruhe: „Mobiler Augmented Reality GIS-Client” Bei diesem am Institut für Photogrammetrie und Fernerkundung der Universität Karlsruhe angesiedelten Projekt soll ein mobiler GIS-Client zur Erfassung und Aktualisierung von 3D-Daten auf der Basis von Augmented Reality (AR)-Techniken [Müll01] entwickelt werden. Durch AR-Techniken soll die Qualität und Produktivität von GIS-Clienten verbessert werden, indem sie den vorhandenen Datenbestand in der realen Umgebung in das Gesichtsfeld des Nutzers einblenden. Der mobile Betrieb von Datenendgeräten ist heute schon mit relativ geringen Bandbreiten (GSM, HSCD, GPRS bis zu ca. 48kb/s) tägliche Praxis, in Kürze eingeführte Kommunikationsnetze im Weitverkehr (UMTS) werden im mobilen Betrieb einige Hundert Kilobit/s an Übertragungsleistung zulassen und werden deshalb auch für anspruchsvollere Multimediaanwendungen in Echtzeit geeignet sein. Ziel des Projektes ist, Methoden der Augmented Reality (AR), wie sie z.B. im CAD, der Gerätewartung [Müll01] und GIS beschrieben werden, zur Unterstützung und Verbesserung der 3D-Datenerfassung und des Update von 3D-Datenbeständen zu verwenden sowie deren Kosten zu untersuchen. Beispielsweise soll die Orientierung und Navigation des Betrachtungs- und Erfassungssystems im Raum untersucht werden. Dies schließt die Untersuchung von Methoden zur Stabilisierung der Aufnahmeplattform durch Einbeziehen von Features im Raum (z. B. Referenzpunkte) sowie die Entwicklung und Bewertung von Messverfahren in der mobilen Umgebung mit ein (z. B. Laserscanner, digitale Kameras, Rangefinder). 3.3 Knoten Vechta: „Entwicklung von Komponenten-Software für den internet-basierten Zugriff auf Geodatenbank-Dienste“ Ausgehend von ersten Erfahrungen mit mobilen Anwendungen [BrBä02] soll das am FZG der Hochschule Vechta angesiedelte Projekt einen Beitrag zur Entwicklung neuartiger komponentenbasierter [Szyp98] und mobiler Geoinformationssysteme leisten. Durch den Einsatz wiederverwendbarer Software [Szyp98] soll es dem Nutzer ermöglicht werden, sich nach dem „Baukastenprinzip“ für eine vorgegebene Anwendungsklasse ähnlich der Vorgehensweise eines CASE-Tools - seinen eigenen Geodienst aus vorgefertigten Komponenten „zusammenzustecken“, d.h. die jeweils notwendige Funktionalität z.B. als benutzerdefinierte Datentypen oder Zugriffsmethoden eines ServiceFrameworks ähnlich wie bei einem Geo-Toolkit [BBCr97] auszuwählen. Dadurch soll eine der bisherigen Schwächen von Geoinformationssystemen, ihre geschlossene Systemarchitektur mit dem damit verbundenen erschwerten Zugriff auf ihre Daten und Operationen von externen Softwaresystemen aus, beseitigt werden (offengelegte Schnittstellen). Von zentraler Bedeutung bei der Entwicklung ist der effiziente räumliche und zeitliche Zugriff auf Geodaten. Im Projekt sollen daher die Datenbankunterstützung für raum- und zeitbezogene Objekte (3D/4D-Objekte) basierend auf vorherigen Arbeiten [GBEJ00], [BTB+03] sowie der effiziente Zugriff auf Geodatenbank-Dienste über das WWW untersucht werden. Schließlich ist in enger Zusammenarbeit mit den anderen Projektknoten die Überführung einer Menge ausgewählter Operationen in den Prototypen eines plattformunabhängigen mobilen Geodienstes beispielsweise für einen HandheldClient vorgesehen. 4 Ausblick Die im Kurzbeitrag skizzierten und zu lösenden Aufgaben der Projektknoten können nur ein erster Schritt auf dem Weg zur Vision mobiler Geodienste sein. Es erscheint offensichtlich, dass geowissenschaftliche Anwendungen mit ihrem unmittelbaren Ortsbezug ein großes Potenzial für die Entwicklung mobiler Datenbankanwendungen besitzen. Die Zukunft muss zeigen, wie schnell sich diese in kommerziell nutzbare Lösungen umsetzen und einbinden lassen. Hier erscheint der Bereich der Hydro- und Ingenieurgeologie besonders geeignet, da sich hier die Interessen von wettbewerbsorientierten Planungsbüros und der geowissenschaftlichen Forschung treffen. Mobile Datenbankanwendungen in diesem Gebiet erfordern das effiziente Retrieval auf großen Mengen komplexer 3D/4D Geo-Objekte sowie die Abspeicherung und lokale Weiterverarbeitung von Abfrageergebnissen auf mobilen Endgeräten. Literaturverzeichnis [BrBä02] Breunig M., Bär W.: Anforderungen mobiler Routenplaner an Datenbanksysteme. Proceedings of the mobile DB-workshop, GI-Jahrestagung, Dortmund, Sept. 30th – 2. Okt., 2002, pp. 580-584. [Bund01] Große Anfrage von 29 Bundestagsabgeordneten vom 12.4.2001 (Drucksache 14/3214). [BBCr97] Balovnev O., Breung M., Cremers A.B.: From GeoStore to GeoToolKit: the SecondStep.Proceedings of the 5th Intern. Symposiuim on Spatial Databases SSD, Berlin, LNCS No. 1262, Springer, Berlin, S. 223-237. [BTB+03] Breunig M., Türker C., Böhlen H., Dieker S., Güting R.H., Jensen C.S., Relly L., Rigaux P., Schek H.-J., Scholl M.: Architecture and Implementations of SpatioTemporal Database Management Systems. Spatio-Temporal Databases – The Chorochronos Approach. Lecture Notes in Computer Science Vol. 2520, Springer, Heidelberg, 2003, S. 219-264. [GBEJ00] Güting R.H., Böhlen M.H., Erwig M., Jensen C.S., Lorentos N.A., Schneider M., Vazirgiannis M.: A Foundation for Representing and Querying Moving Objects. ACM Transactions on Database Systems, Vol. 25, No. 1, March. [Müll01] Müller S.: Virtual Reality - Augmented Reality. INI-Graphics-Net. Brochure, Fraunhofer - IGD, Darmstadt. [OGC03] OpenGIS Consortium: Geography http://www.opengis.org/techno/specs.htm Markup Language (GML), [Rein01] Reinhardt W.: Concept of a GIS and location based services for mountaineers, Proceedings 4th AGILE Conference, Brno 2001. [Szyp98] Szyperski C.: Component Software - Beyond Object-oriented Programming, Addison Wesley, Essex, England, 411S. [SABK03] Schäben H., Apel M., v.d. Boogaart K.G., Kroner U.: GIS 2D, 3D, 4D, nD – von geographischen zu geowissenschaftlichen Informationssystemen. Hauptbeitrag „Geowissenschaftliche Informationssysteme“. Informatik Spektrum, Band 26, Heft 3, Juni 2003, S. 173-179. Datenströme im Kontext des Verkehrsmanagements∗ Michael Cammert Christoph Heinz Jürgen Krämer Bernhard Seeger Fachbereich Mathematik und Informatik Universität Marburg 35032 Marburg, Deutschland {cammert, heinzch, kraemerj, seeger}@informatik.uni-marburg.de Abstract: Anhand mobiler Objekte im Verkehrsmanagement diskutieren wir die Verarbeitung der dabei entstehenden Datenströme. Wir skizzieren typische Anforderungen an Datenverarbeitungssysteme und begründen, warum traditionelle Datenbankmanagementsysteme im Kontext von Datenströmen weniger geeignet sind. Vielmehr motivieren wir den Einsatz von Datenstrommanagementsystemen, wobei wir einen Überblick über allgemeine Problemstellungen und Ansätze bei der Verarbeitung von Datenströmen geben. Neben prototpyischen Systemen präsentieren wir unser bibliotheksorientiertes Rahmenwerk, mit dem sich Anfragen über Datenströmen adäquat formulieren und ausführen lassen. Im Ausblick erläutern wir die Konstruktion eines allgemeinen Datenstrommanagementsystems aus den Komponenten unseres Rahmenwerks, welches sich in einem weiteren Schritt auf die Anforderungen des Verkehrsmanagements anpassen ließe. 1 Einleitung Die stetig wachsende Belastung des Straßennetzes erfordert eine adäquate Steuerung des Verkehrs. Dazu müssen Verkehrsdaten erfasst, übertragen, analysiert und verwaltet werden, was unter dem Begriff Verkehrsmanagement zusammengefasst wird. Die Daten können sowohl von stationären als auch von mobilen Sensoren geliefert werden. Beispielsweise registrieren stationäre Sensoren an Autobahnbrücken den aktuellen Verkehrsfluss, während mobile Sensoren fahrzeugspezifische Informationen, wie etwa die exakte Position eines Fahrzeugs, übermitteln. Die initialen Ziele des Verkehrsmanagements liegen in einer effizienteren Ausnutzung der bestehenden Kapazität des Straßennetzes und einer Verlagerung der Verkehrsbelastung, um dem wachsenden Verkehrsaufkommen entgegenzukommen. Geeignete Verkehrsmanagementsysteme könnten dazu eine Vielzahl von Daten berücksichtigen, z. B. Routenpläne, Baustellendaten, Floating-Car-Daten oder Wetterprognosen, und so etwa einen Autofahrer bei Staus intelligent umleiten. Eine Studie zu den Wirkungspotentialen des Verkehrsma∗ Diese Arbeit wurde von der Deutschen Forschungsgemeinschaft (DFG) unter Projektnummer SE 553/4-1 gefördert. nagements [Pr99] prognostiziert für das Jahr 2010 eine Steigerung der Streckenkapazität auf den Autobahnen um ca. 10% unter Verwendung geeigneter Steuerungsanlagen. Im Kontext des Verkehrsmanagements fassen wir die Verkehrsteilnehmer als bewegliche Objekte auf. Die zu deren Erfassung verwendeten Sensoren senden ihre Daten autonom, wobei die Updaterate allerdings variieren kann. Hierbei entsteht ein Tradeoff zwischen den Verarbeitungskosten, die durch hohe Updateraten verursacht werden, und der Genauigkeit der aktuellen Verkehrserfassung. Idealerweise ließe sich die Updaterate der beteiligten Fahrzeuge bei Staugefahr erhöhen und im Gegenzug bei wenig befahrenen Streckenabschnitten senken. Die erfassten Sensordaten werden im Allgemeinen in einem Datenbanksystem verwaltet, wodurch sämtliche Updates persistent gespeichert werden. Hieraus resultieren enorme Datenbestände, von denen meist nur ein Bruchteil für aktuelle Analysen herangezogen wird, da eine vollständige Auswertung der archivierten Daten zu aufwändig wäre. Das stellt den Einsatz von Datenbanksystemen zur Verwaltung von Sensordaten generell in Frage. Seit zirka zwei Jahren beschäftigen sich daher einige Forschergruppen mit dem Entwurf von Datenstrommanagementsystemen, die sich speziell für die Analyse und Verarbeitung von Daten eignen, die autonomen Datenquellen entspringen. In diesem Artikel geben wir zunächst einen Überblick über die in diesem Themengebiet grundsätzlich auftretenden Problemstellungen und Ansätze. Danach präsentieren wir PIPES (Public Infrastructure for Processing and Exploring Streams), unser Rahmenwerk zur Verarbeitung von Datenströmen, das auf einer Publish-/Subscribe-Architektur basiert. Der Rest dieses Artikels ist wie folgt strukturiert: In Abschnitt 2 betrachten wir im Kontext des Verkehrsmanagements die Unterschiede zwischen der Datenstromverarbeitung und der traditionellen Vorgehensweise basierend auf Datenbanksystemen. Im Anschluss stellen wir in Abschnitt 3 unser Rahmenwerk PIPES zur Verarbeitung von Datenströmen vor. Abschließend fassen wir die vorgestellten Konzepte zusammen und geben einen Ausblick auf mögliche Anwendungsszenarien. 2 Datenströme und Verkehrsmanagement Im Folgenden skizzieren wir Probleme, die bei einer Datenverarbeitung im Rahmen des Verkehrsmanagements mit einem traditionellen Datenbankmanagementsystem (DBMS) entstehen [WXCJ98] und zeigen, dass ein Datenstrommanagementsystem (DSMS) angemessener wäre. In Abbildung 1 werden die beiden Konzepte gegenübergestellt. 2.1 Anforderungen Zunächst möchten wir zentrale Anforderungen bei der Datenverarbeitung im Kontext des Verkehrsmanagements herausarbeiten. Da permanent verschiedenste Sensordaten erfasst werden, ergeben sich potentiell unendliche Datenströme. Für eine dynamische Steuerung des Verkehrsflusses müssen diese Daten kontinuierlich ausgewertet werden. Daraus resul- tieren einerseits permanente Anfragen, wie z. B. die Berechnung der aktuellen Verkehrsdichte eines Streckenabschnitts, und andererseits zeitlich begrenzte Anfragen, die etwa bei der Betreuung eines Verkehrsteilnehmers auf seiner Route erforderlich sind. Weiterhin muss ein System in der Lage sein, neue Anfragen entgegenzunehmen, adäquat zu integrieren und nach Ablauf wieder zu entfernen. Bei hoher Verkehrsdichte trifft folglich eine größere Zahl von zum Teil ähnlichen Anfragen auf eine stark erhöhte Menge von Sensordaten. Allerdings existieren auch Phasen geringerer Verkehrslast. Ein geeignetes System muss hinsichtlich dieser Laständerungen skalierbar und adaptiv ausgelegt sein. Insbesondere sollte das Zusammenspiel mehrerer Anfragen optimiert werden (MultiAnfragen-Optimierung), weil diese typischerweise lange im System verweilen. Eine generelle Möglichkeit zur Reduktion der Updaterate besteht in der dezentralen Ausführung von Anfragen, falls die Sensoren über genügend Rechenkapazität verfügen [BGS01, CBB+ 03]. Neben der Quantität der Daten spielen ebenso deren Qualität und Verfügbarkeit eine Rolle. So muss ein System auch bei Ausfall oder Fehlfunktion von Sensoren sowie einer Unterbrechung bzw. Überlastung des Kommunikationsnetzwerks weiterhin funktionieren. Eine zusätzliche Anforderung besteht in der effektiven Unterstützung von orts- und zeitabhängigen Anfragen. Darüber hinaus müssen sämtliche Anfragen nahezu in Echtzeit bedient werden, was eine komplette Zwischenspeicherung der Daten für eine spätere Verarbeitung ausschließt. Vielmehr sollten diese direkt bei ihrer Ankunft vom System verarbeitet werden. Wenn die exakte Auswertung der Anfrage aus Komplexitäts- oder Performanzgründen nicht möglich ist, sollen approximative Antworten zur Laufzeit bereitgestellt werden. Weiterhin wird eine einfache und flexible Integration heterogener Datenquellen sowie eine Anbindung an bestehende Systeme angestrebt. Das Speichern historischer Daten in anderen Datenbanken, wie etwa das durchschnittliche Verkehrsaufkommen an einem Freitag Nachmittag, könnte die Auswertung ähnlicher Anfragen unterstützen. Diese vielseitigen Anforderungen an ein System zur Datenstromverarbeitung im Kontext des Verkehrsmanagements verdeutlichen, dass die Faktoren Adaptivität, Flexibilität, Skalierbarkeit sowie die Unterstützung kontinuierlicher Anfragen eine fundamentale Rolle spielen. 2.2 Datenbankmanagementsysteme Wir diskutieren im Folgenden die Eignung von DBMS im Kontext des Verkehrsmanagements. Ein DBMS gestattet ausschließlich Anfragen über den in seiner Datenbank persistent abgespeicherten Daten. Die Elemente eines zu verwaltenden Datenstroms müssen daher zunächst in diese Datenbank eingefügt werden. Anfragen werden somit bezüglich des Datenbestands zu einem festen Zeitpunkt einmalig beantwortet. Dadurch basieren aktuelle Resultate auf fortwährenden Wiederholungen derselben Anfrage. Dies kann sich, ebenso wie das explizite Einfügen eines neu eintreffenden Datenstromelements, als sehr aufwändig erweisen. [TGNO92] Manche Komponenten eines DBMS sind nur sehr bedingt nützlich, wie beispielsweise das Transaktionsmanagement. Fehlende Funktionalität, die in Fremdsystemen bereitgestellt wird, ist dagegen schwierig an ein bestehendes DBMS anzubinden. Darüber hinaus Abbildung 1: Datenverarbeitung in DBMS und DSMS liefern DBMS stets exakte Antworten, d. h. eine Adaption im Falle einer zu hohen Systemlast ist nicht vorgesehen. Die wiederholte Auswertung der kontinuierlichen Anfragen erschwert zusätzlich die Multi-Anfragen-Optimierung, da sich die zu optimierende Anfragemenge fortlaufend ändert. In Kombination mit obigen Anforderungen erweisen sich DBMS insbesondere hinsichtlich der Adaptivität als weniger geeignet für die Datenverarbeitung im Rahmen des Verkehrsmanagements. 2.3 Datenstrommanagementsysteme Bezüglich der Charakteristika von Datenströmen treffen wir in Einklang mit [BBD+ 02] folgende Annahmen: 1. Die Verarbeitung der Anfragen erfolgt direkt beim Empfang der Daten, ohne zuvor den gesamten Datenstrom explizit zu speichern. 2. Die Ordnung auf den Datenströmen sowie deren Übertragungsgeschwindigkeit wird nicht durch die verarbeitenden Algorithmen, sondern primär durch die aktiven Datenquellen selbst bestimmt. 3. Die Datenströme sind in ihrer Größe potentiell unbeschränkt. 4. Jedes Element eines Datenstroms wird nur einmal vom Strom geliefert. 5. Änderungsoperationen auf Elementen eines Datenstroms sind nicht möglich. Neue Elemente können nur am Ende eines Datenstroms angehängt werden (append-only). Die im Rahmen des Verkehrsmanagements verarbeiteten Daten weisen diese Eigenschaften auf. Stationäre und mobile Sensoren senden kontinuierlich Daten in Form von Updates, welche wir nach obiger Definition als Elemente eines Datenstroms auffassen. Da ein Sensor stets aktuelle Daten übermittelt, tritt jedes Datum nur ein einziges Mal auf. Die Datenverarbeitung wiederum muss sich nach den Datenraten der aktiven Datenquellen richten. Ein wahlfreier Zugriff auf die Daten ist nur möglich, wenn diese zuvor archiviert wurden. Eine komplette Zwischenspeicherung und anschließende Auswertung der Datenströme ist ausgeschlossen, da diese einerseits in ihrer Größe nicht begrenzt und andererseits beim Verkehrsmanagement regelmäßig und möglichst frühzeitig Resultate erforderlich sind. Die Exploration der daraus resultierenden riesigen Datenarchive würde eine teure Aufgabe für ein Datenbanksystem darstellen. Daher sollte eine Online-Analyse der Datenströme direkt bei deren Ankunft erfolgen und, wenn überhaupt, nur ein Bruchteil der Daten zwischengespeichert werden, falls diese für künftige Anfragen erforderlich sind. Neben historischen Anfragen spielen jedoch kontinuierliche Anfragen eine weitaus bedeutendere Rolle in DSMS, die hinsichtlich beider Anfragetypen skalierbar ausgelegt sein sollten. Durch die zu Grunde liegenden Datenströme und deren fluktuierende Datenraten müssen solche Systeme zusätzlich in einem hohen Maße adaptiv sein. Diese Adaptivität in Verbindung mit limitierten Ressourcen ermöglicht teilweise nur approximative Antworten zu einer Anfrage. Liefert eine Induktionsschleife beispielsweise einen Datensatz pro Fahrzeug, so steigt die Datenrate mit zunehmender Verkehrsdichte. Lassen die Werte eine erhöhte Staugefahr vermuten, so ist eine schnelle Benachrichtigung der betroffenen Verkehrsteilnehmer sicherzustellen, während die Bestimmung der exakten Zahl der erfassten Fahrzeuge weniger von Belang ist. Während Anfragen in DBMS vor ihrer Ausführung statisch optimiert werden, ergeben sich im Kontext von DSMS neue Herausforderungen. Zur Steigerung der Performanz werden mehrere Anfragen gebündelt, so dass gemeinsame Teilanfragen nur einmal ausgewertet werden. Dabei muss auch das dynamische Einfügen und Löschen von Anfragen unterstützt werden. Zudem ist eine dynamische Laufzeitoptimierung dieser lange laufenden Anfragen notwendig. Die für ein Verkehrsmanagement relevanten Daten liegen sowohl persistent als auch in Form eines Datenstroms vor. Straßenkarten sind beispielsweise in Datenbanken abgelegt, während die von mobilen oder stationären Sensoren gelieferten Informationen kontinuierlich gesendet werden. Tabelle 1 zeigt zusammenfassend die in diesem Abschnitt dargelegten Unterschiede zwischen herkömmlichen DBMS und DSMS. 2.4 Anfrageverarbeitung auf Datenströmen Im Weiteren diskutieren wir gegenwärtige Konzepte und allgemeine Problemstellungen bei der Verarbeitung von Datenströmen. Datenbankmanagementsystem (DBMS) • Passive Datenquellen • Persistente Daten (Relationen) • Externspeichernutzung • Wahlfreier Zugriff • historische Anfragen • Exakte Antworten • Statische Optimierung Datenstrommanagementsystem (DSMS) • Aktive Datenquellen • Flüchtige Daten (Datenströme) • Hauptspeichernutzung • Sequentieller Zugriff • Kontinuierliche Anfragen • Approximative Antworten • Dynamische Optimierung Tabelle 1: Unterschiedliche Anforderungen der Datenverarbeitungssysteme 2.4.1 Algebra Anfragen in Datenbanksystemen werden typischerweise in einer deklarativen Sprache wie SQL formuliert und dann in einen Anfrageplan übersetzt, der im Wesentlichen aus Operatoren einer geeigneten Algebra besteht. Man könnte SQL um Funktionalität zur Verarbeitung von Datenströmen erweitern, wobei jedoch bestehende Funktionalität eventuell nicht mehr benötigt wird. Einfüge- und Änderungsoperationen auf Datenströmen werden obsolet, wohingegen sich approximative Anfragen bislang nicht spezifizieren lassen. Sinnvoll wäre folglich die Konzeption neuer Anfragesprachen oder die direkte Formulierung von Anfragen mittels einer GUI. Zentrales Problem [BBD+ 02] beider Ansätze ist die Definition einer geeigneten Algebra, die als Grundlage für die Verarbeitung von Datenströmen dient. Neben der logischen Algebra, in der primär die Semantik der Operatoren festgelegt wird, gibt es eine physische Algebra, die i. A. verschiedene Implementierungen der Operatoren enthält. Durch die direkte Verarbeitung der Elemente eines Datenstroms ist die klassische bedarfsgesteuerte Verarbeitung mittels Iteratoren (ONC) nach [Gr93] nicht möglich. Aufgrund potentiell unbeschränkter Datenströme dürfen keine blockierenden physischen Operatoren eingesetzt werden. Darunter versteht man Operatoren, die ihre gesamte Eingabe konsumieren müssen, bevor ein Ergebnis geliefert werden kann. Es existieren jedoch logische Operatoren, wie beispielsweise die Minus- oder die Sortieroperation, die keine nicht-blockierende Implementierung erlauben. Dieses Problem lässt sich allerdings durch die Verwendung von über einen Datenstrom gleitenden Fenstern, inkrementeller Auswertung oder a priori bekannten Eigenschaften eines Datenstroms lösen. Zum Beispiel wäre es für eine aktuelle Stauprognose ausreichend, die Sensordaten der letzten Stunden zu betrachten. 2.4.2 Indexierung Mit Indizes lassen sich Anfragen effektiv unterstützen. Typische Anfragen beim Verkehrsmanagement sind sowohl orts- als auch zeitgebunden. Eine auf Indexstrukturen mit Zeitfenstern basierende Anfrage wäre etwa: ”Wie hoch war die mittlere Verkehrsdichte auf den Autobahnen im Großraum München bezogen auf die vergangenen vier Stunden?” Deswegen bieten sich mehrdimensionale Indexstrukturen wie der MVB-Baum [BGO+ 96] an, die effiziente Suchoperationen unterstützen. Neben persistenten Daten, wie etwa Karten- und Baustelleninformationen, lassen sich auch mobile Sensoren mit Indexstrukturen verwalten. Für die Sensordaten benötigt man performante Einfüge-, Lösch- und Änderungsoperationen, wobei insbesondere mengenbasierte Operatoren von Vorteil für die Performanz wären. Ebenso müssen gleitende Fenster adäquat unterstützt werden, was bei den bislang existierenden Ansätzen jedoch nicht der Fall ist. 2.4.3 Optimierung Eine zentrale Komponente eines DBMS ist der Anfrageoptimierer, der bei der Anfrageübersetzung deskriptiv formulierte Anfragen in einen möglichst optimalen Ausführungsplan transformiert. In DSMS werden bei der statischen Optimierung Anfragen in einem Anfragegraphen unter Berücksichtigung übereinstimmender Teilanfragen zusammengefasst. Bei Anfragen auf Datenströmen benötigt man des Weiteren eine adaptive und dynamische Optimierung zur Laufzeit. Die Laufzeit einer kontinuierlichen Anfrage wiederum wird primär durch den Benutzer bestimmt, der diese bei einem Anfragekoordinator anbzw. abmeldet. Bei Datenströmen geht man von einer Vielzahl von Anfragen mit oftmals überlappenden Teilanfragen aus, wodurch eine Multi-Anfragen-Optimierung erforderlich ist. So sind sicherlich mehrere Verkehrsteilnehmer an den aktuellen Stauinformationen für die Autobahn A8 auf dem Streckenabschnitt von München nach Stuttgart interessiert, während andere lediglich die Staus zwischen Augsburg und Ulm erfahren möchten. Folglich müssen bei der Optimierung bereits ablaufende Anfragen ebenfalls berücksichtigt werden. Die traditionellen, auf der Schätzung von Zwischenergebnissen basierenden Kostenmodelle eignen sich nicht für potentiell unbegrenzte Datenströme. Stattdessen sollte eine Optimierung [VN02] die Ein- bzw. Ausgaberaten der Operatoren in Betracht ziehen. Es stellt sich zudem die Frage, wie eine dynamische Optimierung zur Laufzeit zu erreichen ist, da eine Re-Optimierung des Anfragegraphen aus Performanzgründen schwierig zu realisieren ist. Deswegen erscheinen partielle Umstrukturierungen sinnvoller. Bei einer dynamischen Optimierung sind darüber hinaus weitere Faktoren zu berücksichtigen wie etwa benutzerdefinierte Quality of Service (QoS) oder der Tradeoff zwischen Effizienz, Genauigkeit und Speicherverbrauch bei der Ausführung einer Anfrage. 2.4.4 Ressourcenmanagement Eine weitere Problemstellung bei der Verarbeitung von Datenströmen ergibt sich bei der Zuteilung der begrenzten Systemressourcen CPU-Zeit, Haupt- und Externspeicher sowie Bandbreite. Zur Laufzeit müssen diese unter den gleichzeitig ablaufenden Anfragen verteilt werden. Der Ressourcenbedarf einer Anfrage kann dabei aufgrund der potentiell unendlich großen Datenströme unbeschränkt sein, wie z.B. bei der Berechnung des kartesischen Produktes. Da in einem DSMS immer limitierte Ressourcen potentiell unbeschränkten Ressourcenanforderungen gegenüberstehen, gestaltet sich die optimale Zuteilung der Ressourcen als äußerst schwierig. So lassen sich aufgrund des begrenzten Spei- Abbildung 2: Anfrageverarbeitung im Rahmenwerk PIPES chers häufig nur approximative Antworten zu einer gegebenen Anfrage bestimmen, über die idealerweise Qualitätsaussagen getroffen werden können. Die Zuteilung der Rechenzeit geschieht mittels eines Schedulers, der hinsichtlich vieler gleichzeitig ablaufender Anfragen skalierbar ausgelegt sein muss. Weiterhin sollten dabei Abhängigkeiten zwischen der Ausführung der Operatoren sowie benutzerdefinierte QoS, wie z. B. Deadlines, berücksichtigt werden. Die Mehr-Anfragen-Optimierung führt zur Einsparung von Ressourcen (resource sharing), weil gemeinsame Teilanfragen nur einmal ausgewertet werden. Ebenso könnte der gemeinsame Zugriff auf Datenstrukturen, wie z. B. Puffer oder Indexstrukturen, die Speicherausnutzung verbessern. Bei der Zuteilung der verfügbaren Ressourcen versucht man primär, die Genauigkeit und die Effizienz hinsichtlich der Anfragen zu optimieren. Hierbei spielen die Faktoren Adaptivität und Skalierbarkeit eine zentrale Rolle, da sowohl die Anfragemenge als auch die Datenraten zur Laufzeit variieren. Darüber hinaus sollte die Ressourcenverwaltung zusätzlich mit dem Optimierer gekoppelt sein. 3 Unser konkretes Rahmenwerk PIPES In diesem Abschnitt stellen wir die Grundzüge unseres Rahmenwerks PIPES vor, mit dem sich Anfragen auf Datenströmen formulieren und ausführen lassen. Eine ausführliche Darstellung von PIPES findet sich in [CHK+ 03]. 3.1 Anfragegraph PIPES erlaubt die Integration beliebiger heterogener Datenquellen, was Anfragen auf Datenströmen und persistenten Daten ermöglicht. Diese Anfragen werden in Anfragepläne übersetzt, die in einem gerichteten Anfragegraphen zusammengefasst werden. Ein inhärenter Publish-Subscribe-Mechanismus erlaubt es, Anfragen zur Laufzeit dynamisch an- bzw. abzumelden. 3.1.1 Logische Operatoren In Anlehnung an Datenflussgraphen unterscheiden wir innerhalb eines Anfragegraphen zwischen Quellen, Operatoren und Senken (siehe Abb. 2). Die Daten fließen dabei stets von den Quellen zu den Senken. Während eine Quelle Daten emittiert, werden diese durch eine Senke konsumiert und verarbeitet. In unserer Modellierung entspricht ein Operator sowohl einer Quelle als auch einer Senke, da er Daten empfängt, diese verarbeitet und anschließend überträgt. PIPES verfügt daher über zwei zentrale Schnittstellen Source und Sink. Diese werden von der Schnittstelle Pipe, die einen Operator modelliert, erweitert. Sobald eine Quelle geöffnet ist, transferiert sie ihre Elemente an solche Senken, die über spezielle Methoden namens subscribe bzw. unsubscribe bei dieser an- bzw. abgemeldet werden können. Werden die Daten einer Quelle nicht mehr benötigt, so kann man sie schließen und verwendete Ressourcen freigeben. Eine Senke konsumiert und verarbeitet die Elemente der Quellen, auf denen sie abonniert ist. Sie wird informiert, falls eine ihrer Quellen versiegt. Für Optimierungszwecke lassen sich zusätzlich die Datenraten eines Knotens, d. h. die Anzahl der Elemente, die pro Sekunde in einem Datenstrom fließen, abfragen. Außerdem ist möglich, Anfragen temporär zu deaktivieren und später ohne Neuübersetzung zu reaktivieren. Initiale Quellen eines Anfragegraphen können in unserem Rahmenwerk zum Beispiel mobile Sensoren oder auch Datenbanksysteme sein, während terminale Senken konkrete Applikationen oder PDAs eines Endbenutzers repräsentieren können. Für deren leichte und erweiterbare Anbindung verfügt PIPES über vorgefertigte Klassen, die gemeinsame Basisfunktionalität transparent bereitstellen. 3.1.2 Physische Operatoren Bei der Konzeption und Entwicklung des Rahmenwerks PIPES wurde die Java-Bibliothek XXL [CHKS03, BBD+ 01] nahtlos erweitert. Neben den oben vorgestellten abstrakten Modellierungen und Schnittstellen enthält PIPES eine Vielzahl generischer Operatoren, die auf beliebigen Objekten arbeiten und über Funktionen und Prädikate parametrisierbar sind. Das Blockieren von Operatoren kann bislang mittels gleitender Fenster umgangen werden. Zum Funktionsumfang von PIPES gehören diverse Implementierungen folgender Operatoren: Filter, Map, Join, Gruppierung, Vereinigung, Differenz, Duplikateliminierung, Online-Aggregation et cetera. 3.1.3 Komponenten Aufbauend auf dem Anfragegraphen, der mittels eines Anfragekoordinators verwaltet wird, existieren in PIPES noch drei weitere Komponenten, die in Abb. 2 dargestellt sind. Der Scheduler übernimmt die Ablaufsteuerung im Anfragegraphen, indem er den einzelnen Knoten CPU-Zeit zuweist. Dabei werden QoS-Aspekte nach benutzerdefinierten Vorgaben berücksichtigt. Ein prioritätsbasierter, adaptiver Speichermanager verwaltet die zur Verfügung stehenden Haupt- und Externspeicherressourcen und erlaubt deren Umverteilung zur Laufzeit. Der Optimierer in PIPES beinhaltet eine statische und eine dynamische Komponente. Während bei der statischen Optimierung neue Anfragepläne in den laufenden Anfragegraphen geeignet integriert werden, initiiert die dynamische Optimierung eine partielle Re-Optimierung des bestehenden Anfragegraphen. Basierend auf den vorgestellten Schnittstellen, physischen Operatoren und Komponenten kann man auf einfache Weise ein DSMS entwickeln, das den speziellen Anforderungen eines Anwendungsszenarios gerecht wird. Wegen der generischen Konzeption muss dazu lediglich die anwendungsspezifische Zusatzfunktionalität implementiert werden. 4 Vergleichbare Projekte Dieser Abschnitt gibt zunächst einen Überblick über verwandte Ansätze und stellt dann aktuelle Projekte vor, die Prototypen von DSMS entwickeln. Das Alert System [SPAM91] benutzt ein konventionelles DBMS mit event-basierten Triggern zur Auswertung kontinuierlicher Anfragen. Tukwila [IFF+ 99] dient in erster Linie der Datenintegration verteilter, autonomer Datenquellen. Es realisiert eine ereignisbasierte Kommunikation der einzelnen Operatoren, vergleichbar mit der Funktionalität von Triggern, und enthält erste Ansätze zur adaptiven Re-Optimierung. NiagaraCQ [CDTW00] überwacht und filtert kontinuierlich über ein Wide-Area-Netzwerk (WAN) verteilte, persistente XML-Datenbestände. Das System verfügt über eine Gruppierungsstrategie für Anfragen, die das inkrementelle Aufsetzen neuer Anfragen auf bestehende Materialisierungen unterstützt. Das Aurora Projekt [CCC+ 02] befasst sich mit der Entwicklung eines Echtzeitsystems zur Überwachung von Datenströmen. Zentraler Bestandteil sind QoS, für die Techniken wie das Löschen von Elementen (load shedding) und speicheradaptives Operatorscheduling eingesetzt werden. Aurora unterstützt resource sharing durch die Verwendung von speziellen Queues. Das Aufsetzen mehrerer Anfragen wird an speziellen Verbindungspunkten, sog. connection points, ermöglicht. Diese erlauben es neu angemeldeten Operatoren, initial auf gepufferte historische Daten zurückzugreifen, bevor sie mit den aktuellen Daten des Datenstroms versorgt werden. STREAM [MWA+ 03] ist ein zentrales DSMS, das auf dem relationalen Datenmodell basiert. Anfragen, die unter anderem kontinuierlich sein können, werden in einer von SQL abgeleiteten deklarativen Anfragesprache formuliert. Um die Ressourcenanforderungen zu reduzieren, fasst STREAM die Daten in Synopsen zusammen und stellt einen globalen Scheduler bereit, der den Speicherverbrauch der Queues minimiert. Letztere werden zur Kommunikation der Operatoren verwendet. Des Weiteren wird der Join zwischen Datenströmen und bestehenden Relationen betrachtet. Das TelegraphCQ System [CCD+ 03] vereinigt bisherige Arbeiten aus Fjords, Eddies und PSoup. Das Fjords [MF02] API definiert eine Menge von Operatoren zur Auswertung von Sensordaten, die sowohl bedarfs- als auch datengesteuert eingesetzt werden können. Allerdings sind diese nicht adaptiv. Eddies [AH00] sind spezielle, zentrale Operatoren, die mit sämtlichen Operatoren eines Anfrageplans verbunden sind. Ein Eddy bestimmt dabei adaptiv, in welcher Reihenfolge ein Element die Operatoren durchläuft. PSoup [CF02] erweitert diesen Ansatz, indem Daten und Anfragen symmetrisch behandelt werden, wodurch zusätzlich historische Anfragen unterstützt werden. 5 Zusammenfassung und Ausblick Die stetig wachsende Verkehrsbelastung erfordert leistungsfähige Verkehrsmanagementsysteme. Die fortlaufend anfallenden Daten werden durch stationäre und mobile Sensoren geliefert und üblicherweise mittels traditioneller DBMS verarbeitet. Da diese Daten allerdings in Form von Datenströmen vorliegen, empfiehlt sich stattdessen der Einsatz eines DSMS, dessen Vorzüge wir insbesondere im Hinblick auf Adaptivität herausgestellt haben. Neben generellen Problemstellungen und Lösungsansätzen der Datenstromverarbeitung haben wir unser Rahmenwerk PIPES präsentiert, das Anfragen sowohl über Datenströmen als auch persistenten Daten erlaubt. Dieses komponentenbasierte Rahmenwerk ermöglicht einem Entwickler einerseits, komplexere Bausteine zu formieren, und andererseits, eigene Funktionalität nahtlos zu integrieren. Ausgehend von unserem generischen, erweiterbaren und flexiblen Bibliotheksansatz lassen sich auf diese Weise anwendungsspezifische DSMS konstruieren. Dies bietet sich im Kontext des Verkehrsmanagements hervorragend an. So könnte man ein intelligentes Verkehrsmanagementsystem realisieren, das, ausgehend von Datenströmen stationärer und mobiler Sensoren, die aktuelle Verkehrsbelastung überwacht und steuernd eingreift. Dieser offene Ansatz ließe sich analog auf Datenströme übertragen, die von beliebigen mobilen Objekten, wie etwa Flugzeugen oder Schiffen, stammen. Literatur [AH00] Avnur, R. und Hellerstein, J. M.: Eddies: Continuously Adaptive Query Processing. In: Proc. of the ACM SIGMOD. S. 261–272. ACM Press. 2000. [BBD+ 01] Bercken, J., Blohsfeld, B., Dittrich, J.-P., Krämer, J., Schäfer, T., Schneider, M., und Seeger, B.: XXL - A Library Approach to Supporting Efficient Implementations of Advanced Database Queries. In: Proc. of the Conf. on Very Large Databases (VLDB). S. 39–48. 2001. [BBD+ 02] Babcock, B., Babu, S., Datar, M., Motwani, R., und Widom, J.: Models and Issues in Data Stream Systems. In: Symp. on Principles of Database Systems. S. 1–16. 2002. [BGO+ 96] Becker, B., Gschwind, S., Ohler, T., Seeger, B., und Widmayer, P.: An Asymptotically Optimal Multiversion B-Tree. VLDB Journal. 5(4):264–275. 1996. [BGS01] Bonnet, P., Gehrke, J., und Seshadri, P.: Towards Sensor Database Systems. In: Proc. of 2nd Int. Conf. on Mobile Data Management. S. 3–14. 2001. [CBB+ 03] Cherniack, M., Balakrishnan, H., Balazinska, M., Carney, D., Çetintemel, U., Xing, Y., und Zdonik, S. B.: Scalable Distributed Stream Processing. In: Proc. of the Conf. on Innovative Data Systems Research (CIDR). 2003. [CCC+ 02] Carney, D., Cetintemel, U., Cherniack, M., Convey, C., Lee, S., Seidman, G., Stonebraker, M., Tatbul, N., und Zdonik, S. B.: Monitoring Streams: A New Class of Data Management Applications. In: Proc. of the Conf. on Very Large Databases (VLDB). S. 215–226. 2002. [CCD+ 03] Chandrasekaran, S., Cooper, O., Deshpande, A., Franklin, M., Hellerstein, J. M., Hong, W., Krishnamurthy, S., Madden, S., Raman, V., Reiss, F., und Shah, M.: TelegraphCQ: Continuous Dataflow Processing for an Uncertain World. In: Proc. of the Conf. on Innovative Data Systems Research (CIDR). 2003. [CDTW00] Chen, J., DeWitt, D., Tian, F., und Wang, Y.: NiagaraCQ: A Scalable Continuous Query System for Internet Databases. In: Proc. of the ACM SIGMOD. S. 379–390. 2000. [CF02] Chandrasekaran, S. und Franklin, M. J.: Streaming Queries over Streaming Data. In: Proc. of the Conf. on Very Large Databases (VLDB). 2002. [CHK+ 03] Cammert, M., Heinz, C., Krämer, J., Markowetz, A., und Seeger, B.: PIPES: A MultiThreaded Publish-Subscribe Architecture for Continuous Queries over Streaming Data Sources. Technical report. University of Marburg. 2003. CS-32 (submitted for publication). [CHKS03] Cammert, M., Heinz, C., Krämer, J., und Seeger, B.: A Status Report on XXL - A Software Infrastructure for Efficient Query Processing. 26(2):12–18. 2003. [Gr93] Graefe, G.: Query Evaluation Techniques for Large Databases. ACM Computing Surveys. 25(2):73–170. 1993. [IFF+ 99] Ives, Z. G., Florescu, D., Friedman, M., Levy, A., und Weld, D. S.: An Adaptive Query Execution System for Data Integration. In: Proc. of the ACM SIGMOD. S. 299–310. 1999. [MF02] Madden, S. und Franklin, M. J.: Fjording the Stream: An Architecture for Queries Over Streaming Sensor Data. In: Proc. of the IEEE Conference on Data Engineering. 2002. [MWA+ 03] Motwani, R., Widom, J., Arasu, A., Babcock, B., Babu, S., Datar, M., Manku, G., Olsten, C., Rosenstein, J., und Varma, R.: Query Processing, Resource Management, and Approximation in a Data Stream Management System. In: Proc. of the Conf. on Innovative Data Systems Research (CIDR). 2003. [Pr99] Prognos AG. Wirkungspotentiale der Verkehrstelematik zur Verbesserung der Verkehrsinfrastruktur- und Verkehrsmittelnutzung. 1999. Bundesministerium für Verkehr-, Bau- und Wohnungswesen FE-Nr. 96.584/1999. [SPAM91] Schreier, U., Pirahesh, H., Agrawal, R., und Mohan, C.: Alert: An Architecture for Transforming a Passive DBMS into an Active DBMS. In: Proc. of the Conf. on Very Large Databases (VLDB). S. 469–478. 1991. [TGNO92] Terry, D., Goldberg, D., Nichols, D., und Oki, B.: Continuous Queries over appendonly Databases. In: Proc. of the IEEE Conference on Data Engineering. S. 321–330. 1992. [VN02] Viglas, S. D. und Naughton, J. F.: Rate-Based Query Optimization for Streaming Information Sources. In: Proc. of the ACM SIGMOD. S. 37–48. 2002. [WXCJ98] Wolfson, O., Xu, B., Chamberlain, S., und Jiang, L.: Moving Objects Databases: Issues and Solutions. In: Statistical and Scientific Database Management. S. 111–122. 1998. User-Toolkits zur dienstbasierten Entwicklung mobiler Applikationen Peter Dornbusch, Martin Huber CDTM - Center for Digital Technology and Management Arcisstraße 21 - 80290 München [email protected]; [email protected] Abstract: Die erfolgreiche Entwicklung und Einführung neuer mobiler Applikationen stellt besondere Herausforderungen an die Kosteneffizienz der Dienst-Entwicklung und die Identifizierung bzw. Befriedigung von Kundenbedürfnissen. Klassische Prozesse der Software-Entwicklung können diese Anforderungen oftmals nicht erfüllen. In dem vorliegenden Papier wird ein Framework vorgestellt, dass durch Integration des Kunden und eine modulare Systemarchitektur eine effiziente Entwicklung ermöglicht. Dabei konfigurieren Nutzer die Zusammenstellung und das Zusammenspiel von verschieden Basisdiensten und generieren dadurch neue Dienste. Durch CommunityFunktionen können die von einzelnen Nutzern entwickelten Applikationsideen weiteren Nutzern verfügbar gemacht werden. In einem evolutionären Prozess können diese Dienste durch Beiträge aus der Gemeinschaft der Nutzer weiter verbessert werden. Die verschiedenen Iterationen innerhalb des nutzerdominierten Entwicklungsprozesses stehen dem Nutzer unmittelbar zur Verfügung, so dass durch diverse Anpassungen (Personalisierung) der Basisdienste und der Ablauflogik (Workflow-Engine) Schritt für Schritt eine erfolgreiche und kundenoptimal gestaltete Anwendung entsteht. Aufgrund der modularen Architektur, die sich auf Basisdienste stützt und einer davon abstrahierten Ablauflogik, kann das Framework leicht um weitere Basisdienste ergänzt werden und ist damit offen für Erweiterungen. 1. Einleitung Seit der Versteigerung der UMTS-Lizenzen und den damit verbundenen hohen Investitionen, versuchen die Mobilfunk- und Serviceprovider mögliche „Killer“Applikation zu identifizieren. Allerdings stellen die hohen Kosten der Konzeption, Entwicklung und Markteinführung einer neuen mobilen Applikation und die Ungewissheit des Markterfolges erhebliche Barrieren dar. Erste ernüchternde Ergebnisse einiger Mobilfunkbetreiber zeigen, dass bei neu eingeführten mobilen Applikationen entwickelt mit klassischen Methoden wie zum Beispiel Marktforschung - die Wahrscheinlichkeit eines Markterfolges aufgrund verfehlter Kundenbedürfnisse äußerst gering ist. Ein Weg der Risikominimierung liegt in einer Optimierung des Entwicklungsprozesses, wie sie in zum Beispiel in [Dor03] vorgeschlagen wird. Insbesondere Werkzeugunterstütztes Rapid Prototyping kann hilfreich bei einer frühzeitigen Kosten/NutzenAnalyse sein. Das vorliegende Papier stellt eine Alternative bzw. eine Ergänzung vor, die durch Integration der Nutzer in den Entwicklungsprozess und einem Framework bestehend aus Basisdiensten und einer Workflow-Engine (Ablauflogik) eine schnelle und kostengünstige Realisierung mobiler Applikationen ermöglicht. Durch die frühzeitige Kundenintegration ist sichergestellt, dass die Bedürfnisse der Kunden optimal befriedigt werden können und der Dienst damit eine hohe Wertschätzung und Zahlungsbereitschaft bei den Nutzern hervorruft. In einer ersten Implementierung ist unser Framework bereits für die prototypische Umsetzung von neuen Anwendungsideen einsetzbar. Für eine Umsetzung und Skalierung auf ein Live-System von Netz- bzw. Servicebetreibern müssen noch weitere Integrationsaspekte gelöst werden. Die Integration des Nutzers bei der Realisierung neuer Innovationen haben u.a. von Hippel [Hi01] und Thomke [Th02] im Bereich von materiell ausgeprägten Produkten sehr ausführlich untersucht. Dabei konnte gezeigt werden, dass die Integration des Nutzers in den Entwicklungsprozess, insbesondere bei „sticky information“, also schwer explizierbaren Informationen zu den Kundenbedürfnissen, sehr vorteilhaft ist. Außerdem zeigen Untersuchungen im Bereich von Open–Source-Software-Projekten [Fr01], [Le00], [He02], dass die Fähigkeit der schnellen Iteration von Dienstversionen und Community-Mechanismen Entwicklungsvorhaben beschleunigen können und zu besserer Qualität führen. Daneben konnte gezeigt werden, dass für innovative Technologien die „technology adoption“ bei der Markteinführung durch frühzeitige Kundenintegration deutlich beschleunigt werden kann und damit die Wahrscheinlichkeit für einen Markterfolg erhöht wird. Unser Framework ermöglicht mit wenigen, aber leistungsfähigen Basisdiensten eine Vielzahl von Applikationen. Im folgenden Kapitel stellen wir die Gesamtarchitektur unseres Systems vor. Anschließend beschreiben wir die einzelnen Basisdienste und veranschaulichen unser Konzept an einem Beispiel. 2. Technisches Konzept Der oben erläuterte Grundgedanke, den Nutzer bzw. Kunden (auch den technisch weniger versierten) die Möglichkeit zu geben an der Entwicklung einer mobilen Applikation mitwirken zu lassen, stellt hohe Anforderungen an die Benutzerschnittstelle und die Einfachheit eines solchen Konzepts. Die Gesamtplattform besteht einerseits aus der Logik zur Konstruktion und Ausführung und andererseits aus einer Kommunikationsplattform zur Diskussion und Evaluierung der kreierten Applikationen. Jede Applikation, die von einem Benutzer erzeugt wurde, kann freigeschaltet und der Community zur Weiterentwicklung zur Verfügung gestellt werden. Ein Versionskontrollsystem und ein mit dem Applikation verknüpftes „schwarzes Brett“ erlauben eine koordinierte Zusammenarbeit in der Community. Abbildung 1 stellt die einzelnen Schichten unserer Architektur dar. Die CommunityKomponente wird aus Gründen der Übersichtlichkeit hier nicht dargestellt. Benutzerdefinierte Applikationen werden aus einer Menge von Basisdiensten zusammengestellt. Die Ausführung der einzelnen Applikationen ist an Ereignisse geknüpft. Ein EventHandler überwacht kontinuierlich eingehende Ereignisse und stößt ggf. die entsprechende Anwendung an. Ein Ereignis kann hierbei zum Beispiel an ein Zeitintervall oder aber an eine Benutzeroberfläche auf dem Endgerät gekoppelt sein. Als Basisdienste sind in der Abbildung beispielhaft Module für SMS (Short Messaging Service), MMS (Multimedia Messaging Service), DB (Datenbank) und LES (Location Enabling Service) ausgewählt, die in der Applikationsschicht kombiniert werden. Endgerät GUI HTTP FTP SMS Event Handler MMS Applikationsschicht Basisdienste LES SMS MMS DB … Abbildung 1: Gesamtarchitektur mit Endgerät (Nutzer/Kunde) und Anbietersystem 2.1 Visuelle Konstruktion Um ein User-Toolkit zu realisieren, welches intuitiv von einem nicht technik-affinen Nutzer bedient werden kann, haben wir Elemente visueller Programmiersprachen (VP) aufgegriffen. VPs verwenden als Basis graphische Symbole. Diese Symbole werden dann in Graphen als Knoten oder Kanten eingesetzt. In [SIF96] wird eine visuelle Programmiersprache definiert als [...] eine formale Sprache mit visueller Syntax oder visueller Semantik zur vollständigen Beschreibung der Eigenschaften von Software. Syntax und Semantik visueller Programmiersprachen beziehen meist den zwei- oder dreidimensionalen Raum ein, während verbale Programmiersprachen auf eindimensionalen Zeichenketten beruhen. Bekannte Beispiele für visuelle Programmiersprachen sind LabView von National Instruments [NI03], das besonders für den Bereich der Mess- und Regelungstechnik verbreitet ist und Lego Mindstorms, zur Programmierung kleiner aus Lego(-Technik) gebauten Robotern, das in Zusammenarbeit von Lego und dem Massachusetts Institute of Technology (MIT) entwickelt wurde [LEGO], [Sey93]. Letztere wurde entwickelt, um Kindern ohne Vorkenntnisse spielerisch das Erlernen einer Programmiersprache zu ermöglichen und zeigt, dass mit visuellen Programmiersprachen in bestimmten Domänen tatsächlich Programmierung leichter vermittelt werden kann. Die positiven Erfahrungen von Lego Mindstorm, als intuitiv bedienbare Programmiersprache, die es auch Nutzergruppen ohne Vorkenntnisse ermöglicht, Aufgaben zu übernehmen, die klassischerweise die Kenntnisse einer formalen Programmiersprache voraussetzen, kann für User-Toolkits fruchtbar eingebracht werden. LabView hingegen ist eine datenflussorientierte Programmiersprache; ein Konzept an dem sich auch das hier vorgestellte Framework orientiert. 2.2 Sprachelemente Unser Ansatz für eine visuelle Sprache ist so einfach wie möglich gehalten, da mit UserToolkits insbesondere Applikationen kreiert werden sollen, die eine (Re-)Kombination bestehender Basisdienste sind und keine hohe Mächtigkeit der visuellen Sprache erfordern. Der innovative Charakter der Applikation, der durch den User über das Toolkit eingebracht wird liegt hier mehr in den Kundenbedürfnissen, den marktlichen Aspekten und den unterschiedlichen Nutzungskontexten. [Hau97] spricht in diesem Zusammenhang zum einen von zweckinduzierten Innovationen, die mit bestehenden Mitteln, also einer bestehenden technischen Dienstplattform, einen neuen Zweck, also eine neue Applikation, erfüllt. Zum anderen von inkrementalen Innovationen, bei denen Mittel und Zweck zwar prinzipiell unverändert bleiben, jedoch durch neuartige Kombinationen oder inkrementelle Verbesserungen im Endergebnis eine deutliche Steigerung erreicht werden kann. Auf mobile Anwendungen übertragen bedeutet dies, dass die technische Plattform (Basisdienste) unverändert bleibt, jedoch durch geringfügige Änderungen oder neuartige Kombinationen eine deutliche Verbesserung der Applikation erreicht werden kann. Die Sprache besteht aus Diensten, bedingten Anweisungen, zusätzlichen Funktionen und Konstanten. Schleifen in Form von Graphzyklen sind nicht möglich, um die Komplexität der Sprache gering zu halten und damit auch mögliche Fehlerquellen bei der Programmierung durch Nutzer mit wenig Programmierkenntnissen auszuschließen. Im Folgenden werden die Merkmale der Sprachelemente kurz diskutiert: Abbildung 2 Graphische Repräsentation eines Basis-Dienstes Dienste: Dienste fassen immer eine Menge an Funktionalität einer spezifischen Domäne zusammen. Da in unserem System Dienste keine Zustände haben, bestehen Dienste aus einer Menge von Methoden. Abbildung 3: Graphische Repräsentation einer Bedingung (if distance) mit bedingtem Dienst (SMS-Service) Bedingte Anweisungen: Diese sind nah an die Basisdiensten angelegt. Abstrakte bedingte Anweisungen sind nicht möglich. Zum Beispiel stellen ortsbezogene Bedingungen die Verknüpfung der Ortsfunktion mit einem Vergleich dar. Bedingte Kommunikation überprüft beispielsweise, ob das entsprechende Postfach des Benutzers eine oder mehrere SMS, MMS oder E-Mails enthält. Zusätzliche Funktionen: Dazu gehören arithmetische Funktionen und String-Operatoren. Konstanten: Alle Dienst- und Funktionseingänge können auch mit Konstanten belegt werden. 2.3 Basisdienste Im Folgenden führen wir für ein besseres Verständnis des Konzeptes einige Basisdienste auf, die bereits realisiert wurden: SMS/MMS: Diese beiden Dienste stellen in erster Linie die Möglichkeit bereit, SMS bzw. MMS an ein anzugebendes Endgerät zu verschicken. Dazu ist es nötig, den Empfänger und den Nachrichteninhalt zu spezifizieren. Eine weitere Aufgabe ist der Abruf empfangener Nachrichten. Telefon (Sprachdienst): Der Telefondienst verbindet zwei Teilnehmer miteinander, indem die Sprachkanäle zweier Teilnehmer zusammengeschaltet werden. In der Kommunikationstechnik ist eine Telefonverbindung im Allgemeinen nicht zustandslos, sondern es werden hier unterschiedliche Zustände, wie Verbindungsaufbau, Warten auf Verbindungsannahme usw. unterschieden. Da unser System zustandslos ist, wartet der Dienst bis beide Teilnehmer erfolgreich verbunden wurden. Etwaige Störungen bei der Etablierung der Verbindung verarbeitet in diesem Fall die Ablauflogik. Location-Services: Der Location-Service lokalisiert einen spezifizierten Benutzer. Der Rückgabewert ist die Benutzerposition angegeben durch Längen- und Breitengrad. E-Mail: Wie bei SMS/MMS muss hier auch der Empfänger spezifiziert werden, wobei bei einem E-Mail-Dienst dies über eine entsprechende Adresse geschieht. Ebenso kann eine Überschrift und ein Nachrichtentext angegeben werden. Buddy-List (Kontakt-Liste): Eine Buddy-List ist vergleichbar mit einem privaten Telefonbuch. Nutzerinformationen: Das Ergebnis dieses Dienstes sind nähere Informationen über einen bestimmten Nutzer. 2.4 Konfiguration Um individuelle Laufzeitparameter zu spezifizieren, wird zu jeder entworfenen Applikation, immer auch eine Konfiguration erstellt. Zum Beispiel wird in der Entwurfphase ein User nur abstrakt in die Anwendung eingebunden. Welcher Benutzer aber tatsächlich gemeint ist, wird erst in der Konfiguration bestimmt, um den Entwurf von der eigentlichen Anwendung zu trennen und damit eine bessere gemeinschaftliche Entwicklung in der Community zu ermöglichen. Für ein intuitives Verständnis durch den Nutzer kann die abstrakte Modellierung aber mit einer konkreten Konfiguration belegt werden. 2.5 Ausführung Die Ausführung übernimmt eine Workflow-Engine, die registrierte Ereignisse verwaltet. Die Workflow-Engine kann unterschiedliche realisiert sein und soll hier nur in den prägenden Eigenschaften beschrieben werden. Wenn ein Ereignis eintritt, wird die entsprechende Applikation ausgeführt. In der jetzigen Implementierung können Ereignisse ausgelöst werden, wenn ein bestimmter Zeitpunkt erreicht ist oder aber eine Nachricht (SMS, Email, etc) eingegangen ist. Da es sich bei den Anwendungen/Programmen um einfache Graphen handelt, ist die Ausführungslogik ebenfalls sehr einfach. 2.5.1 Methodenaufrufe Damit eine Methode ausgeführt werden kann, müssen drei Bedingungen erfüllt sein: 1. Alle benötigten Parameter dieser Funktion müssen mit einem entsprechenden Rückgabewert einer anderen Methode belegt sein. 2. Alle eingehenden Parameter einer Methode müssen bereits gesetzt sein. Dass bedeutet, dass Quellfunktionen bzw. Dienste bereits ausgeführt wurden. 3. Ist die Methode innerhalb einer Bedingung, so muss die Bedingung erfüllt sein. Nur wenn die Bedingungen erfüllt ist, kann eine Methode ausgeführt werden. Es wird keinerlei Aussage über den Zeitpunkt der Ausführung getroffen. Der Ausführungszeitpunkt wird autonom vom Interpreter bestimmt. 2.5.2 Beenden der Ausführung Zur Beendigung einer Applikation kommt es, wenn sich kein Dienst mehr ausführen lässt. Dies ist der Fall, wenn entweder tatsächlich alle Dienste ausgeführt wurden oder aber wenn ein Dienst nicht mehr ausgeführt werden kann, weil die Eingangsparameter nicht gesetzt sind oder gesetzt werden können. 2.5.3 Ausführung eines Programms Zur Ausführung wird auf Zyklenfreiheit geprüft und dann Sequentialisiert. : Überprüfung auf Zyklenfreiheit: Um die prinzipielle Ausführbarkeit des Programms zu gewährleisten, muss sichergestellt werden, dass der entstandene Graph G zyklenfrei ist. Dies bedeutet in diesem Zusammenhang, dass kein Dienst (Knoten des Graphen) direkt oder indirekt von sich selbst abhängig sein darf. Dazu wird für jeden Teilgraph des Graphen überprüft, ob er nach dieser Festlegung zyklenfrei ist. Trifft dies für alle Knoten von G zu, so ist auch G zyklenfrei. Um einen einzelnen Dienst zu überprüfen, muss man zuerst feststellen von welchen anderen Knoten dieser abhängig ist. Hierbei gibt es zwei unterschiedliche Arten von Abhängigkeit. Ist festgestellt worden, dass keine Zyklenabhängigkeiten vorhanden sind, so muss überprüft werden, ob das Programm ausgeführt werden kann. Um die Ausführung einer Instanz zu gewährleisten, müssen alle benötigten Parameter mit einem Wert belegt sein. Sequenzialisierung: Um das Programm ausführen zu können, muss der zuvor aufgebaute Graph sequentialisiert werden. Dies ist nötig, da nicht allen benutzten Instanzen gleich von Anfang an ihre benötigten Parameter zur Verfügung stehen, sondern diese teilweise erst von anderen bereitgestellt werden müssen. Um mögliche Startpunkte für die Ausführung zu erhalten, werden zunächst einmal alle Instanzen gesucht, die keinerlei Abhängigkeiten von anderen aufweisen und die nicht das Ziel einer Wertzuweisung oder eine bedingte Instanz sind. Diese Startpunkte können nun direkt ausgeführt werden, bzw. sind die, die als erstes ausgeführt werden müssen. Danach wird für jede Instanz, die nicht zu dieser ersten Gruppe gehört, überprüft, ob alle ihre Parameter von einem Dienst stammen, der zu der Gruppe der Startpunkte gehört. Ist dies der Fall, so kann der Dienst ausgeführt werden und wird zu den bereits Ausgeführten hinzugefügt. Im anderen Fall wird einfach mit dem nächsten Dienst fortgefahren und der gerade geprüfte wird wieder an den Schluss der Sequenz angehängt. Für bedingte Dienste muss ferner noch überprüft werden, ob sie aufgrund der Bedingung ausgeführt werden können oder nicht, das heißt, ob die Bedingung erfüllt ist oder nicht. Dies wird nun solange wiederholt, bis alle Dienste ausgeführt sind. Dadurch ergibt sich eine mögliche – nicht eindeutige Reihenfolge für die Ausführung. 3. Beispielapplikation An einem Beispiel wollen wir den Toolkit veranschaulichen. Abbildung 4 zeigt den Dienst „Schwiegermutter-Warner“. In der Entwurfssicht finden sich die einzelnen Basisdienste und die Nachrichtenflüsse zwischen den Basisdiensten. Zwei Benutzer werden lokalisiert und ihr Abstand zueinander wird bestimmt. Wenn die Benutzer sich näher als 500 m kommen, wird an einen der Benutzer eine SMS gesendet. In der Konfiguration wird nun noch spezifiziert, um welche Nutzer es sich handelt. In unserem Fall ist es beispielsweise der Nutzer (also der Dienstentwickler) selbst und dessen Schwiegermutter. Wie schon anhand dieser schematischen Beispielapplikation deutlich wird, wirken sich schon inkrementelle Änderungen der Ablauflogik (z.B. Änderung des Radius von 500m auf 3km) auf die Charakteristik der mobilen Applikation aus. Durch einen vielfältigen „Trial and Error“ Prozess durch den Nutzer bzw. die Gemeinschaft der Nutzer und die evolutionäre Weiterentwicklung der Applikationsidee kann so nach mehreren Iterationen eine marktfähige und den Kundenbedürfnissen entsprechende Applikation geschaffen werden [Hi01]. Bei der Gestaltung des „Trial and Error“ Prozesses muss abgewogen werden, welche Freiräume und welche Restriktionen zugelassen werden, um einerseits einen großen Möglichkeitsraum zu gewährleisten, andererseits den Prozess sowohl für den Kunden als auch den Betreiber, insbesondere hinsichtlich der anfallenden Kosten, attraktiv zu machen. Die (Wertschöpfungs-)Beiträge innerhalb des Entwicklungsprozesses kommen dabei maßgeblich vom Kunden/Nutzer und ermöglichen so für einen Anbieter eine veränderte Kostenstruktur für die Realisierung neuer mobiler Applikationen. In der Betriebswirtschaft wurde u.a. von Ramirez [Ram99] unter dem Begriff der “value co-production“, in ähnlichem Kontext die Vorteilhaftigkeit der Kundenintegration sehr breit diskutiert. Abbildung 4: Beispielapplikation für einen „Schwiegermutter-Warner“ In der bereits vorliegenden Implementierung des Toolkits (Abbildung 4) kann das „Look-and-Feel“ der Benutzeroberfläche in unterschiedlichen Designs und mit verschiedenen Beschriftungen gestaltet werden, um eine intuitiv zugängliche und nutzerfreundliche Benutzerschnittstelle zu realisieren. 4. Fazit und Ausblick In dem vorliegenden Papier haben wir einen ersten Entwurf für einen User-Toolkit zur mobilen Applikationsentwicklung vorgestellt. In der jetzigen Phase ist vor allem noch nicht geklärt, wie entwickelte Anwendungen in den Normalbetrieb migriert werden können. Dies soll im Zuge eines 2004 anlaufenden Forschungsprojektes zusammen mit einem Industriepartner aus dem Bereich ISP bearbeitet werden. Dennoch steht bereits zum jetzigen Zeitpunkt ein mächtiges Tool zur Verfügung, welches die Möglichkeiten und Grenzen eines Toolkits für die Entwicklung mobiler Applikationen skizziert. Literaturverzeichnis [Dor03] Peter Dornbusch, Martin Huber, Matthias Möller, Rapid Prototyping of mobile Applications, Proceedings of 8th International Workshop on Mobile Multimedia Communications, 2003 (to appear) [Fr01] Egon Franck, C. Jungwirth, Open versus Closed Source, Working Paper No. 4, Universität Zürich, 2001 [Hau97] Hauschildt, J.: Innovationsmanagement. Franz Vahlen Verlag, München, 2. Auflage, 1997 [He02] Joachim Henkel,Open Source Software from Commercial Firms – Tools, Complements, and Collective Invention, Discussion Paper No. 02-27, German Economic Association of Business Adminsitration, 2002 [Hi01] Von Hippel, E.: Perspective: User Toolkits for Innovation, The Journal of Product Innovation Management Vol. 18, pp. 247-257., 2001 [Le00] Josh Lerner, Jean Tirole, The Simple Econimics of Open Source, Harvard Business School, 2000 [LEGO] Lego, http://mindstorms.lego.com, 2003 [NI] National Instrument, http://www.ni.com, 2003 [SIF96] Stefan Schiffer, Visuelle Programmierung - Potential und Grenzen, 1996 [Ra99] Ramirez, R.: Value Co-Production: Intellectual Origins and Implications for Practice and Research, Strategic Management Journal, Vol. 20, pp. 49-65., 1999 [Th02] Thomke, S. and von Hippel, E.: Customers as Innovators: A new Way to Create Value, Harvard Business Review, Vol. 80, No. 2., 2002 Konzeption geräteübergreifender Anwendungen Thomas Königsmann Integration Management Fraunhofer-Institut für Software- und Systemtechnik ISST Emil-Figge-Strasse 91 44227 Dortmund [email protected] Abstract: Der »Digitale Begleiter« ist eine Metapher, die den Gedanken der Informationslogistik mit der Vision des Ubiquitous Computings nach Weiser verbindet. »Digitale Begleiter« manifestieren sich in Anwendungen, die kontextsensitiv und geräteunabhängig Dienstleistungen und Informationen anbieten. In dieser Arbeit wird das Konzept der »geräteübergreifenden Anwendungen« eingeführt und ein auf Dialogspezifikationsmethoden basierendes Vorgehen zur Realisierung präsentiert. Dabei gehen »geräteübergreifende Anwendungen« über die Geräteunabhängigkeit hinaus, indem gefordert wird, dass ein Wechsel des Endgerätes auch während der Anwendungsdurchführung, also zur Laufzeit der Anwendung, möglich ist. 1 Einleitung Betrachtet man die Fortschritte im Bereich der Informations- und Kommunikationstechnologien, so lassen sich grundsätzlich zwei Schwerpunkte benennen. Einerseits sind dies Bemühungen das Internet, das bisher als »gewaltiger Informationspool« betrachtet wurde, auch als Service Plattform zu etablieren, wie aus den Standardisierungsbemühungen im Bereich der Web-Services [Ch01] hervorgeht. Andererseits eröffnen technische Entwicklungen in den Bereichen der drahtlosen Datenübertragung, der mobilen Endgeräte und Anwendungen neue Einsatzgebiete. Hier wird eine Infrastruktur geschaffen, die es erlaubt, Informationen und Dienstleistungen, die bisher an Desktop-PCs gebunden waren, auf mobilen Endgeräten und somit allgegenwärtig zugänglich zu machen. Hinter diesen Möglichkeiten verbergen sich aber auch eine Reihe von Problemstellungen, die insbesondere durch den Einsatz mobiler Endgeräte noch verschärft werden. Insbesondere die Fülle an Diensten und Informationen kann bereits an stationären Arbeitsplätzen zu einer Informationsüberflutung führen (vgl. [DL01]). Der Forschungsbereich der Informationslogistik thematisiert diese Problemstellung und liefert Konzepte und Werkzeuge zur Reduktion des Volumens bei gleichbleibenden Informationsgehalt für die Anwender. Detaillierte Beschreibungen der Konzepte zur bedarfsgerechten Informationsversorgung, einem Schwerpunkt der Informationslogistik, finden sich in [DL01], [DLP03], [Ha01]. Digitale Begleiter sind ein Themenfeld der Informationslogistik, das sich insbesondere mit dem Einsatz mobiler Technologien beschäftigt. Der »digitale Begleiter« ist hierbei eine Metapher, die den Gedanken der Informationslogistik mit der Vision des »Ubiquitous Computings« nach Weiser [We91] verbindet. Dienste und Informationen werden dem entsprechend nicht an Endgeräte sondern an Personen gebunden. Im Vordergrund stehen Anwendungen, die Anwender über unterschiedliche Endgeräte hinweg begleiten. 2 Geräteübergreifende Anwendungen Ein Kernaspekt der »digitalen Begleiter« ist die allgegenwärtige Bereitstellung von Anwendungen und Informationen. Diese Anwendungen werden aufgenommen und können wieder beiseite gelegt werden, um sie an einem anderen Ort oder zu anderer Zeit wieder fortsetzen zu können. Diese Konzeption wird im Folgenden mit dem Begriff »geräteübergreifende Anwendungen« umschrieben. Hierbei wird allerdings nicht der bekannte Ansatz verfolgt, Dienste auf unterschiedliche Endgeräte zu portieren, sondern eine neue Form von Anwendungen zu ermöglichen. Im Vordergrund steht hierbei der Werkzeuggedanke, bei dem für die Durchführung von Aufgaben unterschiedliche Werkzeuge zum Einsatz kommen. Wie im Alltagsleben, sollen sich Anwender unterschiedlicher Werkzeuge bedienen können und auch die Möglichkeit haben, die Werkzeuge zu wählen, die ihrer Ansicht über die adäquaten Eigenschaften besitzen, um eine Aufgabe zu bewältigen. Überträgt man diesen Gedanken auf informationstechnische Systeme, so werden Werkzeuge durch spezialisierte Endgeräte (Information Applicances) wie beispielsweise PDA, FAX, Telefon (Mobiltelefone, Haustelefone), Systeme zur Erfassung von digitalen Handschriftnotizen, mit Set-Top-Boxen ausgestattete Fernsehgeräte, Bordcomputer in Automobilen und Info-Terminals repräsentiert. Aber auch Web-Pads, Laptop und schließlich der herkömmliche Desktop-PC zählen zu den Endgeräten. Diese Gerätschaften verfügen über unterschiedliche Eigenschaften in Hinsicht auf ihre Fähigkeiten und ihre Verfügbarkeit. Der Wechsel der Endgeräte während der Anwendungsdurchführung kann vielfältige Ursachen haben: - - der Anwender wählt ein anderes Endgerät, da es über die geeigneteren Fähigkeiten zur Durchführung einer Teilaufgabe verfügt, der Anwender ist aufgrund eines Ortswechsels gezwungen, die Anwendung zu unterbrechen und nimmt sie hinterher an einem anderen Ort auf einem anderen Endgerät wieder auf, eine Fortsetzung der Anwendung ist aufgrund der Fähigkeiten des Endgerätes nicht mehr realisierbar, die Anwendung benötigt einen unbestimmten Zeitraum um zu reagieren, der Anwender möchte die Anwendung unterbrechen und zu einem anderen Zeitpunkt wieder aufnehmen. Geräteübergreifende Anwendungen zeichnen sich einerseits durch den Einsatz heterogener Endgeräteklassen (vgl. [OH99]) und andererseits durch den Endgerätewechsel zur Laufzeit der Anwendung aus. Der Einsatz heterogener Endgeräteklassen und somit der Einsatz unterschiedlicher User-Interfaces erlaubt nicht nur unterschiedliche Typen von Endgeräten einzusetzen, sondern auch neue Interaktionsformen (vgl. [St96]), wie beispielsweise die Sprachsteuerung, Gestenerkennung und Handschrifterkennung in die Anwendung zu integrieren, da diese Interaktionsformen als Teil des Endgerätes abgebildet werden können. Die Möglichkeit des Endgerätewechsels während der Aufgabendurchführung wirft Fragestellungen bezüglich der Konzeption und Realisierung solcher Anwendungen auf. Für den Wechsel der Endgeräte müssen Möglichkeiten vorgesehen werden, eine Anwendung zu unterbrechen und auf einen anderen Endgerät wieder aufzunehmen, ohne das ein Anwender gezwungen wird die Daten, die er auf einem Endgerät eingegeben hat, auf das andere Endgerät zu übertragen. Jede Interaktion mit der Anwendung muss potentiell über unterschiedliche Endgeräte ausführbar sein, da nur so sichergestellt werden kann, das ein Wechsel überhaupt möglich ist. Dies bedeutet allerdings, dass die Anwendung selbst endgerätefrei formuliert werden muss, während die Definition der Interaktionen endgerätebezogen zu betrachten ist, da Interaktionen auf unterschiedlichen Endgeräten völlig verschieden gestaltet werden können. Dies hat immense Auswirkungen auf die Komplexität geräteübergreifender Anwendungen. Es ist somit von höchster Priorität Konzeptionen und Abstraktionen zu finden, die diese Komplexität beherrschbar zu machen. Das folgende Kapitel stellt solch einen Ansatz vor. 3 Dialogbasierter Ansatz zur Realisierung geräteübergreifender Anwendungen Die zugrunde liegende Idee zur Realisierung geräteübergreifender Anwendung basiert auf der Annahme, dass Anwender bestimmte Interaktionsschritte über unterschiedlichen Endgeräte ausführen können. Interaktionsschritte beziehen sich in dieser Arbeit auf eine User-Interface-Ebene. Sie umschreiben hierbei Interaktionen, die der Anwender mit dem Computersystem durchführen muss. Anwendungen müssen somit als eine Abfolge von Interaktionen beschreibbar sein, die der Anwender abarbeitet. Zielsetzung ist die einzelnen Interaktionsschritte mit unterschiedlichen Endgeräten durchführbar zu gestalten, so dass auch die gesamte Anwendung geräteübergreifend realisiert werden kann, indem jeder Interaktionsschritt grundsätzlich auf einem anderen Endgerät durchführbar ist. Die Problematik dieses Ansatzes liegt in der Definition, Modellierung und schließlich Realisierung der einzelnen Interaktionen. Die Funktionsaufrufe, die ein Computersystem leisten muss, unterscheiden sich zumeist deutlich von den Interaktionen, die der Anwender durchführt. Ebenso können auf bestimmten Endgeräten Interaktionen völlig verschieden geartet sein. So können über einen Web-Browser in nur einem Interaktionsschritt komplexe Formulare angeboten und verarbeitet werden, während die Umsetzung über einen Telefondialog viele einzelne Interaktionen erfordert. Zentraler Ansatz ist somit die Interaktionsmodellierung von Anwendungen. Die notwendigen Interaktionen zwischen Anwender und System werden hier als Abstraktionsebene eingeführt, die dann für unterschiedliche Endgeräte zu konkretisieren ist. In der Literatur [Gö94] unterscheidet man zwischen unterschiedlichen Modellen für die Beschreibung und Entwicklung von User-Interfaces [Hüb90]: mentale Modelle (Benutzerwissen über das Anwendungsgebiet), Benutzermodelle (kognitive Modelle) und Aufgabenmodelle (konzeptionelle Modelle) werden zumeist im Bereich der Software-Ergonomie eingesetzt, während Dialog- und Architekturmodelle in der Softwareentwicklung Beachtung finden. In dieser Arbeit sind insbesondere die letzen beiden Modellklassen von Interesse, da der Schwerpunkt auf der Konzeption und Realisierung von UserInterfaces für geräteübergreifende Anwendungen gelegt wird. Architekturmodelle definieren den strukturellen Aufbau einer Benutzerschnittstelle durch funktionale Komponenten, deren Kombinationsmöglichkeiten und Kommunikationsverbindungen. Eines der bekanntesten Architekturmodelle, das eine Interaktionskontrolle explizit thematisiert, ist das nach einem Workshop benannte Seeheim-Modell [Pf85]. Es handelt sich dabei um ein logisches Architekturmodell, das die drei funktionale Komponenten Präsentationskomponente, Dialogkontrolle und Applikationsschnittstelle unterscheidet. Dialogmodelle bilden die konzeptionelle Grundlage des zulässigen Interaktionsablaufes, der sogenannten Dialogablaufbeschreibung und der darauf aufbauenden Steuerung des Dialoges zwischen Benutzer und Anwendung, der sogenannten Dialogablaufsteuerung. Ein Dialogmodell impliziert eine bestimmte Methode der Dialogablaufbeschreibung, die als Dialogspezifikationsmethode bezeichnet wird, und hat wesentlichen Einfluss auf eine der zentralen, funktionalen Komponenten einer Benutzerschnittstelle der Dialogkontrolle [Gö94]. Für die Konzeption und Realisierung geräteübergreifender Anwendungen ist es notwendig, Dialogmodelle zu entwickeln, die es erlauben die Dialogablaufbeschreibung auf einer geräteunabhängigen Ebene zu ermöglichen. Unter Steuerung dieser neu eingeführten Ebene müssen dann Überführung auf geräteabhängige Dialogablaufbeschreibungen realisiert werden, die schließlich in einem softwaretechnischen System, das über eine Dialogkontrolle gesteuert wird, die Durchführung von Anwendungen erlaubt. 4 Existierende Ansätze Obwohl der Begriff der »geräteübergreifende Anwendungen« in der Literatur nicht wiederzufinden ist, finden sich ähnliche Ansätze im Forschungsbereich des »Ubiquitous Computing«. Die Idee des »Ubiqutous Computings« ist auf Marc Weiser zurückzuführen, der 1991 in dem Artikel »The computer for the 21st century« [We91], die Vision von vielen kleinen, vernetzen und unsichtbar in die Umwelt des Anwender integrierten Computersystemen beschrieb und damit einen neuen Forschungsbereich schuf. Seine Vision zeichnet sich insbesondere durch die unsichtbare Integration der Systeme aus, bei der sich der Mensch nicht mehr explizit mit einem Computer auseinander setzen muss, sondern Computer ein Teil seiner natürlichen Umgebung sind. Geräteübergreifende Anwendungen nehmen den Kerngedanken der Allgegenwärtigkeit von Anwendungen auf, indem tatsächlich eine Anwendung über unterschiedliche Endgeräte bedienbar wird. Die Integration der Computer in die Umwelt der Anwender wird aber außer acht gelassen. Dieser Gedanke wird in der neueren Literatur mit »Nomadic Computing« [Kl95] umschrieben. Beim »Nomadic Computing« steht die Mobilität des Anwenders im Vordergrund. Der Anwender wandert zwischen unterschiedlichen Infrastrukturen und erhält über die am Ort verfügbaren Gerätschaften oder Endgeräte, die er mit sich trägt, Zugang zu lokalen Infrastrukturen und kann über diese auf eine zentrale Instanz zugreifen, die seine persönlichen Informationen und Dienstleistungen bereitstellt. Im Gegensatz zu den Ansätzen, die geräteunabhängige Anwendungen behandeln, bei denen eine Anwendung über unterschiedliche Endgeräte angeboten wird, kann bei geräteübergreifenden Anwendungen auch zur Laufzeit ein Endgerätewechsel durchgeführt werden. Die Konzeption geräteunabhängiger Anwendungen ist heutzutage aber immer noch als problematisch zu bewerten. Zumeist wird lediglich die Präsentation von Inhalten in den Vordergrund gestellt und Mechanismen zur Transformation in unterschiedliche Formate beschrieben. Dieser Ansatz stößt allerdings an Grenzen, wenn die Anwendung komplexe Interaktionen erfordert. So ist schon das simple Aufteilen einer HTML-Seite in kleinere Bausteine, die auch auf PDAs dargestellt werden, oft schon nicht durch Transformation der Inhalte möglich, da hier Nutzerinteraktionen stattfinden müssen, um eine Navigation in den Inhalten zu erlauben. Der in dieser Arbeit verwendete Ansatz, nutzt die Transformation von Inhalten, betrachtet diese aber nur als Baustein, um Ausgaben für die einzelnen Dialogschritte zu erzeugen. Im Grunde lässt sich für die heutige Entwicklung von geräteunabhängigen Anwendungen festhalten, dass Geräteunabhängigkeit innerhalb einer Geräteklasse realisierbar ist, zwischen ähnlichen Geräteklassen nur schwierig und zwischen völlig unterschiedlichen Geräteklassen nicht realisierbar ist. Die Programmiersprache Java bietet beispielsweise eine Entwicklungsumgebung, die auf unterschiedlichen Plattformen lauffähig ist. Grundsätzliche lassen sich JavaAnwendungen zwischen unterschiedlichen Plattformen transferieren und ermöglichen somit geräteunabhängige Anwendungen. Anwendungen sind aber nur zwischen gleichen Klassen von Endgeräten transferierbar. Eine Portierung von Desktop Anwendungen auf mobile Endgeräte, wie beispielsweise PDAs, ist bereits nicht mehr realisierbar. Das kleine Display, das Fehlen von Maus und Tastatur erfordern bereits zu große Anpassungen, das eine einfache Portierung möglich wäre. Das hier auch keine Besserung zu erwarten ist, lässt sich anhand der Entwicklungsstrategie von Sun aufzeigen, die für unterschiedliche Endgerätetypen, unterschiedliche Versionen ihrer Java-VM [Wh01] anbieten. Beispiele für Geräteunabhängigkeit bei ähnlichen Klassen sind Browser und ServerArchitekturen, die multi-Device fähig sind. Dieser Ansatz zeichnet sich durch die Verwendung von Browsern, als Client-Umgebung aus. Hier existieren eine Reihe von Frameworks, die unterschiedliche Endgeräte unterstützen können. So werden hier zumeist HTML für Desktop-PCs, HTML für PDAs und WAP für mit WAP-Browsern ausgestattete Mobilfunkgeräte angeboten. Diese Ansätze setzen auf einer abstrakten Beschreibung des Contents, zumeist in XML auf und transformieren diese Inhalte auf Größen, die auch auf kleineren Displays dargestellt werden können. Tatsächlich lässt sich nur ein Bruchteil der notwendigen Anpassungen lediglich durch Transformation realisieren, in vielen Fällen ist die Anpassung des Applikationsablaufes notwendig. Beispiele für Geräteunabhängigkeit auch zwischen unterschiedlichen Klassen wie beispielsweise Spracheausgabe beim Telefon, DesktopPCs und mobilen Endgeräten finden sich nur im Bereich des »Unified Messagings« [WV02]. Beim »Unified Messaging« allerdings die Anwendung (Informationszustellung) fest definiert. Anwendungen die tatsächlich geräteübergreifend sind, finden sich lediglich im Bereich der »Remote Clients«. Hier wird die Anwendung auf Server-Systemen durchgeführt und lediglich die Ausgabe auf den PC des Anwenders gesendet. Dieser Ansatz erlaubt es das Endgerät zu wechseln. Es ist allerdings nicht möglich, andere Endgeräte-Klassen zu verwenden, da Serversysteme über keine Mechanismen verfügen, die es erlauben gerätespezifisch zu reagieren, bzw. die existierende Oberfläche auf ein anders geartetes User-Interface zu transferieren. Der in dieser Arbeit verwendete Dialogansatz, wird hauptsächlich für den Aufbau von UIMS (User-Interface-Management-Systems) [St96] verwendet. UIMS versprechen eine Beschleunigung der Entwicklung von User-Interfaces, indem eine funktionale Trennung von Präsentationskomponente, Dialogkontrolle und Applikationsschnittstelle vorgenommen wird und Werkzeuge zur Entwicklung bereitgestellt werden. Kern jedes UIMS ist die verwendete Dialogspezifikation. Es existiert ein Vielzahl von Dialogspezifikationsmethoden, die tatsächlich auch in UIMS eingesetzt werden. Die prominentesten Vertreter sind Zustandsübergangsgraphen, Petrinetze, Ereignissysteme, Kontextfreie Grammatiken, Statecharts und Graph Grammer [BFJ96]. Dialogspezifikationsmethoden verfügen über unterschiedliche Eigenschaften in Bezug auf ihre Fähigkeiten zur Abbildung von Dialogzuständen, zur Strukturierung, Abstraktion und Ausführbarkeit von Dialogabläufen (vgl. [Gö94]). Die Unterschiedlichen Charakteristika der Dialogspezifikationsmethoden, sind auch der wesentliche Grund, warum für Unterschiedliche Interaktionsformen (interaction styles) wie Fenster-, Menü-, Masken-, Kommandosprachen-Systeme oft auch unterschiedliche Dialogspezifikationsmethoden zum Einsatz kommen. Eine wie für den dialogbasierten Ansatz zur Realisierung geräteübergreifender Anwendungen benötigte einheitliche Methode zur Beschreibung unterschiedlicher Interaktionsformen ist in der Literatur nicht zu finden. 5 Vorgehen Das Vorgehen zur Konzeption und Entwicklung geräteübergreifender Anwendungen orientiert sich an einem Phasenmodell. Das Ergebnis einer Phase bilden jeweils die Grundlage der darauffolgenden Phase. Für die Übergänge zwischen den einzelnen Phasen werden Werkzeuge konzipiert, die Hilfsmittel für die Überführung in die nächste Phase bereitstellen. Abbildung 1 veranschaulicht die einzelnen Phasen und Werkzeuge, und gibt Beispiele wie diese Werkzeuge aussehen könnten. Die einzelnen Phasen werden durch graue horizontale Balken dargestellt und Werkzeuge durch Rechtecke, die mit einem Zeiger auf die Phase in der sie benutzt werden ausgestattet sind. Links an den Balken sind Beschriftungen angebracht, die das Ergebnis der Phase benennen. Die Beschriftung und die Symbole, die rechts an den Balken positioniert sind zeigen exemplarische Umsetzungen der Werkzeuge. Ergebnisse Werkzeuge Werkzeugbeispiele Anforderungskatalog •Endgeräte Interaktionskonzept •Orte •Verfügbar •Nutzer •Zeit •Darstellung •Nutzbarkeit Basis Dialogkatalog geräteunabhängiges Dialogmodell Gerätespezifische Dialogkataloge Input Select Modify gerätespezifische Dialogmodelle PDA CarPC Telefondialog Schablonen ausführbares Dialogmodell HTMLText to Speech Telko-Anlage Schablonen Engine Abbildung 1: Vorgehen bei der Realisierung geräteübergreifender Anwendungen Die erste Phase umfasst die Analyse der Anwendung, in Bezug auf die Anforderungen geräteübergreifender Anwendungen. So müssen Anwendungsfälle (Use Cases) von der reinen Betrachtung der Funktionen um Aspekte wie Verfügbarkeit von Interaktionsmedien, Angemessenheit der Interaktionsarten, zu nutzende Endgeräte, Fähigkeit der Endgeräte zur Durchführung benötigter Interaktionen und viele andere Aspekte erweitert werden. Bisher existieren nur bedingt Erfahrungen im Einsatz von geräteübergreifenden Anwendungen, so das Hilfestellungen in diesem Bereich benötigt werden. Zur Unterstützung der Analyse-Phase müssen relevante Aspekte identifiziert und ihre Auswirkungen auf die Konzeption der Anwendung beschrieben werden. Insbesondere sollte der Schwerpunkt der Analyse auf notwendige Interaktionen des Anwenders gelegt werden. Als Hilfsmittel für die Analyse sind Anforderungskataloge denkbar, die Richtlinien für die Konzeption liefern. Das Ergebnis der zweiten Phase ist ein Dialogmodell, dass geräteunabhängig formuliert wurde. Diese Beschreibung bildet die Grundlage für die folgenden Schritte, die den Dialogablauf konkretisieren. Dabei muss einerseits gewährleistet werden, dass den nachfolgenden geräteabhängigen Modellen genügend Freiräume gelassen werden, um den Dialogmodellierer nicht einzuschränken, andererseits müssen Interaktionen des Anwenders auf Parameter und Funktionsaufrufe abgebildet werden. Letzteres ist notwendig, da auf dieser Ebene die Schnittstelle zum funktionalen Kern der Anwendung geschaffen wird. Der verwendete Ansatz zur Modellierung geräteunabhängiger Dialoge basiert auf der Definition von sogenannten »Basis Dialogschritten«, die über alle Endgeräte realisierbar sind. Zur Modellierung des geräteunabhängigen Dialogmodells sollten nur Elemente eines »Basis Dialogkataloges« verwendet werden, der alle »Basis-Dialogschritte« enthält. Grundlegende Dialogschritte könnten beispielsweise »Input«, »Select« und »Modify« sein. Untersuchung unterschiedlicher Anwendungen haben gezeigt, das bereits dieses kleine Set an Dialogschritten ausreichend ist, um einen Großteil von Anwendungen abzubilden (vgl. [NB02]). Um nachfolgenden Modellen Freiräume zu gewährleisten, muss das geräteunabhängige Modell erlaubte Permutationen von Dialogschritten oder parallel durchführbare Dialogschritte abbilden können. Das geräteunabhängige Modell steht in Beziehung mit dem geräteabhängigen Modell, da beispielsweise Reihenfolgen in Funktionsaufrufen, welche die Anwendungslogik abbilden, oft harte Kriterien für eine Dialogstrukturierung darstellen. Eine Trennung ist auch nicht erstrebenswert, da der Bezug zu den Funktionen, der auf dieser Ebene abgebildet wird, verloren gehen würde. Im nächsten Schritt der »geräteabhängigen Dialogmodellierung« müssen Konkretisierungen für den Dialogablauf modelliert werden. Diese orientieren sich an den speziellen Eigenschaften der verwendeten Endgeräte. Hierzu werden gerätespezifische Dialogkataloge angeboten. Jeder dieser Kataloge enthält eine Reihe von Dialogschritten, die über ein Endgerät durchgeführt werden können. Als Beispiel für einen Dialogschritt auf einen HTML-Browser können Formulare benannt werden, über welche der Anwender Texteingaben tätigen und/oder Elemente aus einem Menü auswählen kann. Um die gleiche Funktionalität auch über einen Telefondialog mit Spracherkennung durchführen zu können, wäre es notwenig mehrere Dialogschritte durchzuführen.Denkbar wären hier für jedes Element des Formulars Eingabeaufforderungen zu generieren, die dem Anwender sequentiell durch das Formular führen. Der Dialogkatalog für Telefondialoge würde nur aus einem Element bestehen, nämlich dem Dialogschritt Sprachausgabe des Systems und Spracheingabe des Anwenders. Für die Modellierung werden Dialogkataloge für die zu unterstützenden Endgeräte angeboten, weiterhin wird eine Dialogspezifikationsmethodik entwickelt, über die sich unterschiedliche User-Interfaces abbilden lassen. Eine autonom vom Rechner durchgeführte Überführung des geräteunabhängigen Modells in das geräteabhängige ist nicht vorgesehen, da die Dialogmodellierung als Teil des User-Interfaces ein kreativer Akt ist, der sich nur schwer automatisieren lässt. Geräteübergreifende Anwendungen erfordern nun, dass insbesondere auch Gerätewechsel durchführbar sind. Ein Gerätewechsel wird auf Modellebene durch die Übertragung des Dialogzustandes eines Dialogmodells (für ein bestimmtes Endgerät) in den Dialogzustand auf das Zielendgerät realisiert. Um zu verhindern, das jedes geräteabhängige Dialogmodell (eines für ein Endgerät) Statusabbildungen auf alle anderen Dialogmodelle abbilden muss, sind Abbildungen des Dialogstatus auf das geräteunabhängige Modell (und umgekehrt auf das geräteabhängige Modell) durchzuführen. Zu untersuchen ist allerdings an welchen Stellen im Dialog Gerätewechsel ermöglicht werden sollen. In der letzten Phase werden den einzelnen im Dialogmodell verwendeten Dialogschritten Schablonen zugeordnet, die ihre tatsächliche Darstellung beschreiben. Als Werkzeug werden hierfür Software-Komponenten verwendet, die tatsächlich einen Dialog realisieren. Die in den Dialog-Katalogen beschriebenen Dialogschritte sollten schon mit Informationen zu den benötigten Schablonen in Beziehung gesetzt werden. So müssen für das ausführbare Dialogmodell lediglich die Schablonen angepasst und für den Anwendungsfall parametrisiert und konfiguriert werden. 6 Ausblick und Stand der Arbeiten Die Zukunft in der Entwicklung mobiler Endgeräte und der Interaktion mit diesen wird zur Zeit kontrovers diskutiert. So sehen sich Anwender heutzutage bereits einer Fülle von Endgeräten wie PDAs, Smart-Phones, Web-Pads, Info-Terminals aber auch neuen Desktop PCs und Laptops ausgesetzt, die zumeist über völlig unterschiedliche Nutzerschnittstellen verfügen. Die Fragestellung, ob zukünftig der Trend zu einem Endgerät konvergiert, über das alle Funktionen angeboten werden, oder ob sich der Werkzeuggedanke durchsetzt, der für jede Aktion ein anderes Endgerät vorsieht, ist nicht erkennbar. Zwischen diesen beiden Extremen existieren vielfältige Möglichkeiten, wie sich der zukünftige Umgang mit Endgeräten entwickeln kann. Mischformen, die beispielsweise ein Gerät für bestimmte Problemstellungen vorsehen, stellen ein realistischeres Szenario da. Die grundlegende Problematik, dass eine Portierung von Anwendungen auf unterschiedliche Endgeräte und somit auch auf unterschiedliche Nutzerschnittstelle nicht handhabbar ist, bleibt davon aber unberührt . Mit der Konzeption der »geräteübergreifenden Anwendungen« wird eine Möglichkeit präsentiert basierend, auf existierenden Dienstleistungen Portierungen auf neue Endgeräte durchzuführen. Innerhalb des Informationslogistik-Projektes des Fraunhofer ISST wurde diese Konzeption entwickelt und wird nun Bottom-up realisiert. So wurde ein auf WebTechnologien basierendes Framework zur Realisierung der Dialogablaufsteuerung gewählte und eine Reihe von Dialog-Katalogen exemplarisch für Desktop-PCs, für PDAs, für eine Kommandosprache für Terminals und für eine textuelle Simulation einer Sprachsteuerung realisiert. Anhand dieser Entwicklungen soll zukünftig die Konzeption »geräteübergreifender Anwendungen« präsentiert und evaluiert werden. Die Konzeption einer geräteunabhängigen Dialogbeschreibungsmethode befindet sich im Aufbau und soll mit Web-Services, als funktionalen Kern verbunden werden. Literaturverzeichnis [BFJ96] Bullinger, H. J.; Fähnrich, K. P.; Janssen, C.: Ein Beschreibungskonzept für Dialogabläufe bei graphischen Benutzerschnittstellen. in Informatik Forschung und Entwicklung 11(2), Springer, Heidelberg, 1996 [Ch01] Christensen, E.; Curbera, F.; Meredith, G.; Weerawarana,S.: Web Services Description Language (WSDL) 1.1. W3C Note 15, 2001. www.w3.org/TR/wsdl. [DL01] Deiters, W; Lienemann, C. (eds.): Report Informationslogistik - Informationen just-intime. Düsseldorf, Symposion Publishing, 2001. [DLP03] Deiters, W.; Löffeler, T.; Pfennigschmidt, S.: The Information Logistics Approach toward User Demand-Driven Information Supply. In: Proc. of the International Conference on Cross-Media Service Delivery, May 30-31, Santorini, Greece, 2003. [Gö94] Götze, R.: Dialogmodellierung für multimediale Benutzerschnittstellen. Fachbereich Informatik, Oldenburg, Dissertation, 1994. [Ha01] Haseloff, S.: Optimizing Information Supply by Means of Context: Models and Architecture. In: (Bauknecht, K., Brauer, W. and Mck, Th. eds.): Proc. of Informatik 2001, Österreichische Computer-Gesellschaft, Wien, September 2001, pp. 206-213 [Hü90] Hübner, W.: Ein objektorientiertes Interaktionsmodell zur Spezifikation graphischer Dialoge. Zentrum für Graphische Datenverarbeitung, Darmstadt, Dissertation, 1990. [Kl95] Kleinrock, L.: Nomadic Computing (Keynote Address). in Int. Conf. on Mobile Computing and Networking, Berkeley, CA, 1995. [LY96] Lindholm, T.; Yellin, F.: The Java Virtual Machine Specification, Addison-Wesley, 1996. [NB02] [Nylander, S.; Bylund, M.: Providing Device Independence to Mobile Services. 7th ERCIM workshop on User Interfaces for All,Paris, 2002 [OH99] Ohto, H.; Hjelm, J.: CC/PP exchange protocol based on HTTP Extension Framework. W3C Note, June, 1999 [Pf85] Pfaff (Hrsg.), G.E.: User Interface Management Systems. Springer-Verlag, Berlin. 1985. [St96] Stary, C.: Interaktive Systeme - Software-Entwicklung und Software-Ergonomie, Vieweg, Braunschweig/Wiesbaden 1996. [We91] Weiser, M.: The Computer for the 21st Century. In: Scientific American 265(3), 1991, pp. 94-104. [Wh01] White, J.: An Introduction to Java 2 Micro Edition (J2ME); Java in Small Things. ICSE 2001, pp. 724-725 [WV02] Wohlfeil, S.; Voelz, D.: Unified Messaging in grossen Unternehmen: Konzepte, Architekturen und betriebswirtschaftliche Aspekte. in Wirtschaftsinformatik 44/1, Vieweg, Braunschweig/Wiesbaden, 2002, S. 9-18. Implementierungskonzepte und Anwendungsentwicklung kommerzieller mobiler Datenbanksysteme – Ein Vergleich – Bela Mutschler, Günther Specht Universität Ulm Abteilung Datenbanken und Informationssysteme (DBIS) 89069 Ulm [email protected] [email protected] Abstract. In diesem Papier werden vier mobile Datenbanksysteme – IBM DB2 Everyplace, Oracle 9i Lite, Sybase UltraLite und Tamino Mobile – bezüglich ihrer Architekturen und Implementierungskonzepte sowie ihrer Unterstützung bei der Entwicklung mobiler Anwendungen verglichen. Darüberhinausgehende Aspekte der mobilen Datenbanksysteme Pointbase Micro und eXtremeDB werden ebenfalls berücksichtigt. Schwerpunkte des Papiers sind, neben den unterschiedlichen Architekturkonzepten, die von den Datenbanksystemen bereitgestellten Verfahren zur Replikation und Synchronisation. 1 Einleitung Aus den Bedürfnissen einer effizienteren mobilen Datenverarbeitung heraus entstanden in den letzten Jahren eine ganze Reihe kommerzieller mobiler Datenbanksysteme. Dabei konkurrieren in ihrer Funktionalität sehr umfassende Produkte großer Hersteller wie IBM oder Oracle mit eher schlankeren Produkten kleinerer Hersteller wie Pointbase oder Sybase. Für die Auswahl und den Einsatz eines bestimmten Produkts ist es deshalb wichtig, die den einzelnen Produkten zugrunde liegenden Konzepte und Implementierungsdetails zu kennen und einschätzen zu können. Gerade im performanzkritischen Bereich von Replikation und Synchronisation existieren dabei große Unterschiede. Im Folgenden werden die mobilen Datenbanksysteme IBM DB2 Everyplace, Oracle 9i Lite, Sybase UltraLite und Tamino Mobile untersucht und verglichen. Schwerpunkte bilden Replikation und Synchronisation, aber auch die Unterstützung bei der Entwicklung mobiler Datenbankanwendungen. Das Papier gliedert sich wie folgt. Zunächst werden in Kapitel 2 Implementierungskonzepte erläutert und verglichen. Abschnitt 2.1 geht kurz auf die wichtigsten Aspekte der jeweils realisierten Anwendungsarchitekturen ein. Während Abschnitt 2.2 Replikations- verfahren untersucht und vergleicht, fokussiert Abschnitt 2.3 bereitgestellte Synchronisationsverfahren. Abschließend stellt Kapitel 3 die verfügbaren Tools und Programmierschnittstellen der vier Systeme zur Unterstützung der Nutzer bei der Entwicklung mobiler Datenbankanwendungen gegenüber. 2 Untersuchung und Vergleich von Implementierungskonzepten 2.1 Anwendungsarchitekturen In diesem Abschnitt werden die von den untersuchten Datenbanksystemen realisierten Anwendungsarchitekturen kurz beschrieben und eingeordnet. Dabei lassen sich zwei Ansätze unterscheiden. Dem klassischen, um spezielle Middleware ergänzten Client/ Server-Ansatz, wie er bei IBM DB2 Everyplace, Oracle 9i Lite und Tamino Mobile realisiert wird (Abbildung 1), steht als Alternative die vollständige Integration der gewünschten Datenbankfunktionalität in eine Anwendung (Abbildung 2) gegenüber. Sybase UltraLite, Pointbase Micro und eXtremeDB sind Vertreter dieser zweiten Kategorie. Während im ersten Fall das DBMS der mobilen Datenbank von den auf sie zugreifenden Anwendungen getrennt bleibt, wird beim letzteren ein in seiner Funktionalität angepasstes Datenbanksystem vollständig in eine Anwendung „einkompiliert“. Die Unabhängigkeit des Datenbanksystems von den Anwendungen wird in diesem Fall aufgegeben. Wir geben im Folgenden einen kurzen Überblick über die einzelnen Systeme, bevor wie in den Abschnitten 2.2 und 2.3 auf Konzepte der Replikation und Synchronisation genauer eingehen. DB2 Everyplace-basierte Anwendungen [3, 4, 6] bestehen aus dem mobilen Datenbanksystem DB2 Everyplace, einem Mid-Tier-Server mit zusätzlicher Synchronisationskomponente und einem DB-Server im Backend. Das mobile Kerndatenbanksystem benötigt einen Speicherplatz von 180-220 kB. Für Transaktionen kann Atomarität und Dauerhaftigkeit (durch den Recovery Manager) garantiert werden [1]. Lokale Konsistenz auf dem Client ist immer gegeben, da es sich bei der mobilen Datenbank um ein klassisches Einbenutzer-System handelt. Einzelne Tabellen können aus Sicherheitsgründen verschlüsselt werden. Die SyncServer-Komponente des Mid-Tier-Servers ist für die Steuerung eines Synchronisationsvorganges zuständig. Über diese Komponente können sowohl Daten als auch Anwendungen zwischen mobilen Clients und Datenquellen im Backend synchronisiert werden. Der SyncClient ist die auf den mobilen Clients für die Steuerung der bidirektionalen Synchronisation zuständige Komponente. DB2 Everyplace baut auf einer klassischen Client/Server-Architektur auf, die um eine Middleware-Komponente erweitert ist (3-Tier-Architecture). Oracle 9i Lite [7] verwendet genau wie DB2 Everyplace eine 3-Tier-Architecture, gebildet aus mobilen Clients, einem zwischengeschalteten Mobile-Server und einem DBServer im Backend. Alle Architekturkomponenten werden zusammen als Mobile Server Environment bezeichnet. Das mobile Kerndatenbanksystem Oracle Lite benötigt einen Speicherplatz von 50 kB-1MB. Auf dem mobilen Client werden für Transaktionen die ACID-Eigenschaften garantiert. Transaktionen werden dabei explizit mit COMMIT oder ROLLBACK abgeschlossen. Der Mobile-Server entspricht in seiner Aufgabenstellung weitestgehend dem SyncServer von DB2 Everyplace. Einen drahtlosen Zugriff unterschiedlich leistungsstarker mobiler Clients ermöglicht der Oracle 9i Application Server (Wireless Edition) – als Teil des Mobile Servers. Im Backend können ausschließlich Oracle-Datenbanken eingesetzt werden, während DB2 Everyplace hier auch andere ODBC/JDBC-Datenbanken zulässt. Neben der Speicherung der Anwendungsdaten wird im Backend auch ein spezieller, für die Replikation relevanter Datenbereich, das Mobile-Server Repository (MSR), verwaltet. Um eine korrekte Replikation zwischen Backend und Clients zu ermöglichen, ist es bei Oracle notwendig, sowohl die zu replizierenden Anwendungsdaten, als auch das MSR in der gleichen Datenbank zu speichern. Drahtlose Netzwerkanbindung Mobile Clients Anwendung DB Festnetzverbindung Middleware (Synchronisations-Server) DB-Server Abbildung 1: 3-Tier-Architecture von DB2 Everyplace, Oracle 9i Lite und Tamino Mobile. Auch Tamino Mobile [9] geht von einer erweiterten Client/Server-Architektur aus. Auf den mobilen Clients kommt als mobiles Kerndatenbanksystem die Tamino Mobile Database (TMDB) zum Einsatz. Der Unterschied zu DB2 Everyplace, Oracle 9i Lite und Sybase UltraLite, die alle (objekt-)relationale Datenmodelle implementieren, liegt in der Unterstützung von XML durch TMDB. So erlaubt TMDB das Suchen und Navigieren innerhalb von XML-Daten mit den W3C-Abfragesprachen XQuery und XPath. Synchronisationsmechanismen erlauben den Abgleich von Daten zwischen mobilen Clients und einem zentralen Tamino XML-Server. Ein spezielles SyncModule ist dabei für die Kontrolle des Synchronisationsvorganges mit einem entfernten Tamino XML-Server zuständig. Der TMDB ist ein Web-Server vorgeschaltet, der ein browser-basiertes Administrations- und Arbeitsinterface zur Verfügung stellt. Der Tamino XML-Server erlaubt die Anbindung von weiteren, auch auf anderen Datenmodellen basierenden DB-Servern. Mobile Anwendung Drahtlose Netzwerkanbindung Festnetzverbindung Integrierte Datenbank Optionale Middleware DB-Server Abbildung 2: 3-Tier-Architecture von Sybase UltraLite, Pointbase Micro und eXtremeDB. Sybase UltraLite [8] ermöglicht es, eine Datenbank zusammen mit der zugehörigen Datenverwaltungslogik vollständig in eine Anwendung „einzukompilieren“. Anwendung, Datenbank und Datenverwaltungslogik bilden zusammen eine UltraLite-Anwendung. Dies hat jedoch die Aufgabe des Prinzips der Datenunabhängigkeit zur Folge. Eine in eine Anwendung einkompilierte Datenbank ist dadurch nur für die dedizierte HostAnwendung zugänglich. Prinzipiell bietet UltraLite die Funktionalität und Zuverlässigkeit einer vollständigen SQL-Datenbank. Die von einer Anwendung nicht benötigten Datenbank-Features müssen auf dem mobilen Client jedoch auch nicht verfügbar sein und werden entsprechend auch nicht mit in eine UltraLite-Anwendung integriert. Dies spart Speicherplatz. Auf die gleiche Weise gehen auch die mobilen Datenbanksysteme Pointbase Micro [10] und eXtremeDB [11] vor. Auch sie integrieren die erforderliche Datenbankverwaltungsfunktionalität und damit das mobile DBMS direkt in die Anwendung. In ihrer grundlegenden Anwendungsarchitektur unterscheiden sich die untersuchten Datenbanksysteme somit vor allem in Bezug auf die Architektur der mobilen Kerndatenbanksysteme. Während eine Seite eine saubere Trennung zwischen Anwendung und Datenbankmanagementsystem aufrechterhält, wird diese Unabhängigkeit auf der anderen Seite aufgegeben, in dem ein in seiner Funktionalität angepasstes Datenbanksystem in eine Anwendung einkompiliert wird. 2.2 Replikationsverfahren Um das Arbeiten mit mobilen Clients im unverbundenen Zustand (Disconnected Mode) zu unterstützen, ist es notwendig, während einer bestehenden Netzwerkverbindung (Connected Mode) Daten eines DB-Servers auf das mobile Datenbanksystem des mobilen Clients zu replizieren. Die Datenbanksysteme DB2 Everyplace, Tamino Mobile und Sybase UltraLite fassen Replikation lediglich als eine Teilphase bidirektionaler Synchronisation vom DB-Server zum mobilen Client auf. Oracle 9i Lite definiert dagegen ein dediziertes Replikationsverfahren. Beim von DB2 Everyplace realisierten Replikationsverfahren (als Teilphase der Synchronisation) werden Daten eines DB-Servers (Source Database) zunächst in eine Austauschrelation (Change Data Table) übertragen. Diese befindet sich physisch betrachtet ebenfalls auf dem DB-Server. Von dort aus werden die Daten über eine Spiegeltabelle (Mirror Table) einer Spiegeldatenbank (Mirror Database) auf dem Mid-Tier-Server auf die mobilen Clients repliziert. Replikation wird dabei nicht nur als initiale Übertragung von Daten in eine neue, noch leere mobile Datenbank, sondern auch als Propagierung von auf dem DB-Server durchgeführten Änderungen an die mobilen Clients verstanden. Auch bei Sybase UltraLite und Tamino Mobile kann Replikation (wie bei DB2 Everyplace) als Teilphase bidirektionaler Synchronisation aufgefasst werden. UltraLite nutzt dazu die MobiLink-Technik, die ein sitzungsbasiertes, bidirektionales Synchronisationsverfahren implementiert. Replikation bei Tamino Mobile erfolgt über eine dedizierte DataLoader-Komponente und den Einsatz weiterer Synchronisationskomponenten. Replikationsquelle bei Oracle 9i Lite muss eine Oracle-Datenbank sein. Mobile Clients, die den Replikationssenken entsprechen, können keine Replikationsquelle sein. Die Replikation erfolgt dabei unidirektional vom DB-Server zum Client. Das implementierte Replikationsverfahren basiert auf der Verwendung von Snapshots. Replikationsserver werden als Master-Sites, Clients als Snapshot-Sites bezeichnet. Die Replikation kann verbindungsbasiert oder dateibasiert erfolgen. Die Kommunikation zwischen Replikationsserver und Clients erfolgt bei verbindungsbasierter Replikation synchron, bei dateibasierter Replikation asynchron. Dateibasierte Replikation erfolgt asynchron unter Verwendung von Dateien, die in einem gemeinsam zugreifbaren Speicherbereich abgelegt sind. Der Dateitransfer kann auf verschiedene Arten erfolgen. Eine Möglichkeit besteht darin, Replikationsdateien manuell (beispielsweise über FTP) zu verteilen. Alternativ kann auch ein automatischer Dateitransfer mit Hilfe einer dedizierten Middleware-Komponente erfolgen, dem Oracle Mobile Agent (OMA). Als dritte Möglichkeit, einen Dateitransfer zwischen Replikationsquelle und Replikationssenke zu implementieren, kann eine HTTP-Verbindung samt zwischengeschaltetem Oracle Web Application Server verwendet werden. Dabei ist der Applikationsserver für die automatische, asynchrone Weitergabe aller Replikate an die Clients zuständig (Standardfall). Snapshots, die den Basiseinheiten des OracleReplikationsverfahrens entsprechen, sind materialisierte Sichten nicht-lokaler Datenbestände. Snapshots basieren auf Originaltabellen, die auch als Mastertabellen oder Mastersichten bezeichnet werden. Zur Replikation werden auf dem Mobile-Server so genannte Publikationen erzeugt. Publikationen bestehen aus einer Menge von Publikationsartikeln (die den Snapshots entsprechen), die über Subskriptionen mobilen Clients zugeordnet sind. Publikationsartikel werden mittels SQL-Anweisungen definiert und zu Publikationen zusammengefasst. Subskriptionen können parametrisiert sein. DBS DB2 Everyplace Oracle 9i Lite Tamino Mobile Sybase UltraLite Konzepte des implementierten Replikationsverfahrens Teilphase des bidirektionalen Synchronisationsprozesses. Über die Spiegeltabelle (Mirror Table) einer zwischengeschalteten Spiegeldatenbank (Mirror Database) werden Daten repliziert. Replikation kann entweder verbindungsbasiert oder dateibasiert erfolgen. Basiseinheit der Replikation sind Snapshots (Publikationsartikel). Teilphase des bidirektionalen Synchronisationsprozesses. Zur Replikation wird eine dedizierte DataLoader-Komponente eingesetzt. Teilphase des bidirektionalen Synchronisationsprozesses. Zur Replikation wird das sitzungsbasierte MobiLink-Verfahren herangezogen. Tabelle 1: Vergleich der implementierten Replikationsverfahren. 2.3 Synchronisationsverfahren Ziel der Synchronisation ist die Aufrechterhaltung bzw. Wiederherstellung eines konsistenten Zustands aller Kopien eines Datenelementes innerhalb einer Replikationsumgebung. Ein Synchronisationsprozess besteht aus zwei verschiedenen Phasen [2]. Die Reintegration überträgt auf dem mobilen Client geänderte Daten auf den DB-Server (Phase 1). Bei der anschließenden (optionalen) Rückübertragung werden zwischenzeitlich auf dem Datenbestand des Servers vorgenommene Änderungen auf die Clients übertragen (Phase 2). Alle in diesem Papier untersuchten mobilen Datenbanksysteme bieten Verfahren zur bidirektionalen Synchronisation an. Der SyncServer ist die bei DB2 Everyplace für die Koordination der Synchronisation zuständige Komponente. Der SyncClient ist die korrespondierende Synchronisationskomponente auf den mobilen Clients. Sowohl SyncClient (= SyncEngine in Abbildung 3) als auch SyncServer (= SyncML Synchronizer using WBXML in Abbildung 3) basieren auf Synchronisations-Engines, die über optional ansteckbare Adapter die Anbindung unterschiedlichster Synchronisationsquellen ermöglichen. Die Synchronisations-Engines kommunizieren untereinander über eine Java ServletEngine, die Bestandteil des SyncServers ist. Als Übertragungsformat der Synchronisations-Nachrichten wird Wireless Application Protocol (WAP) Binary encoded XML (WBXML) verwendet. Dabei handelt es sich um eine kompakte XML-Repräsentation, die die Übertragungsgröße der Synchronisations-Nachrichten stark reduziert. Verschiedene Kommunikationsadapter stellen unterschiedliche Möglichkeiten eines drahtlosen Zugriffs (auf die Java Servlet-Engine) zur Verfügung. Für die Synchronisation werden Nutzer zu Gruppen zusammengefasst. Ein zu synchronisierendes Datenelement wird in einer Subscription gekapselt, die wieder zu Subscription Sets aggregiert werden. Nutzergruppen können solche Subscription Sets zugewiesen werden. SyncServer IBM SyncGUI Mobile Devices Administration Center DB2e Adapter PIM Adapter HTTP Sync Engine File Adapter Adapter API WAP Bluetooth SyncEngine API Transport API Java Servlet Mobiler Client DB2 UDB Adapter SyncML Synchronizer using WBXML JDBC Adapter Domino Adapter Exchange Adapter Adapter API Abbildung 3: Synchronisationsarchitektur von DB2 Everyplace [6]. Die Synchronisation vom DB-Server hin zu mobilen Clients kann auch als Replikation aufgefasst werden und wurde bereits in Abschnitt 2.2 erläutert. Die Synchronisation vom mobilen Client hin zum DB-Server verläuft technisch gesehen prinzipiell gleich. Nach der notwendigen Authentifizierung einer Synchronisationsanforderung (Synchronization Request) eines mobilen Clients werden geänderte Daten über eine Zwischentabelle (Staging Table) in eine Spiegeltabelle (Mirror Table) einer Spiegeldatenbank (Mirror Database) übertragen. Neu ist, dass an dieser Stelle eventuell auftretende Synchronisationskonflikte durch den SyncServer gelöst werden müssen. Dazu greift er auf verschiedene (interne) Konfliktlösungsstrategien zurück, ohne zu garantieren, dass auch tatsächlich alle Konflikte erkannt oder behoben werden. Ausgehend von der Spiegeltabelle werden die Änderungen mit den ursprünglichen Quelldaten des DB-Servers abgeglichen. Synchronisationsvorgänge können manuell oder automatisch unter Verwendung der IBM SyncEngine API angestoßen werden. Oracle 9i Lite definiert Synchronisation als Abgleich von Snapshots. Ein Synchronisationsvorgang kann einerseits automatisch durch einen serverseitigen Datenbankprozess initialisiert werden. Andererseits können für eine individuelle Initialisierung spezielle Java Replication Classes bzw. Replication OLE Controls verwendet werden. Bei Snapshots unterscheidet Oracle 9i Lite zwischen einfachen und komplexen Snapshots. Einfache Snapshots basieren auf einer einzelnen Tabelle. Zwischen Originaltabelle und Snapshot muss eine bijektive Abbildung existieren (einfache Sichten). Nur so können auf einem Snapshot durchgeführte Änderungen auf die Originaltabelle übertragen werden. Im Falle eines Fehlers muss das Wiederherstellen eines konsistenten Datenbankzustands ermöglicht werden. Dazu kann bei einfachen Snapshots für die Originaltabelle ein Snapshot Transaction Log geführt werden. Komplexe Snapshots entsprechen komplexen Sichten. Für sie ist in Oracle keine Reintegration auf dem Server möglich, daher darf auf sie auf dem mobilen Client nur lesend zugegriffen werden. Komplexe Snapshots können sich nicht nur auf verschiedene Tabellen, sondern auch auf andere Snapshots beziehen. Einzige Voraussetzung: Datenstrukturen, auf die sie sich beziehen, müssen auf dem gleichen DB-Server verfügbar sein. Das Snapshot-Reintegrationsproblem entspricht damit dem klassischen View-UpdateProblem. Snapshots werden mittels der Anweisung CREATE SNAPSHOT angelegt. Eine optionale FOR UPDATE-Klausel legt fest, ob es sich um einen einfachen oder komplexen Snapshot handelt. Die oben angesprochene bijektive Abbildungsvorschrift einfacher Snapshots wird durch eine Datenbankanfrage, die so genannte Snapshot-Anfrage, bestimmt. Abhängig vom Typ eines Snapshots kann zwischen verschiedenen Synchronisationsverfahren unterschieden werden. Im Zuge einer vollständigen Aktualisierung (Full Refresh) werden alle Tupel, die im Ergebnis einer Snapshot-Anfrage auftauchen, vom Replikationsserver in die Snapshot-Tabelle des mobilen Clients übertragen. Vor der Übertragung werden alle existierenden Tupel der Snapshot-Tabelle gelöscht, so dass immer in eine völlig leere Tabelle geschrieben wird. Bei der schnellen Aktualisierung (Fast Refresh) werden die in den Snapshot-Logs protokollierten Änderungen an den Originaltabellen für eine effizientere Aktualisierung der Snapshots verwendet. So werden beim Fast Refresh ausschließlich die protokollierten Änderungen übertragen. Der Begriff der schnellen Aktualisierung kann zu Missverständnissen führen. Zwar wird der Eindruck erweckt, die schnelle Aktualisierung sei die in jedem Fall die effizientere Synchronisationsmethode. Dies ist jedoch nicht immer richtig. Bei kleinen Tabellen, die ein hohes UPDATE-Aufkommen vorweisen, ergibt sich eine umgekehrte Situation. In diesem Fall kann die Übertragung aller protokollierten Änderungen wesentlich aufwendiger sein, als eine alternative vollständige Aktualisierung. Force Refresh implementiert eine Mischung der beiden zuerst genannten Techniken. Zunächst wird eine schnelle Aktualisierung versucht. Scheitert diese, beispielsweise aufgrund fehlerhafter Snapshot-Logs, wird eine vollständige Aktualisierung durchgeführt. Nach der Initialisierung eines Synchronisationsvorgangs wird eine so genannte Refresh Group erstellt. Diese fasst alle Datenbanktabellen respektive Snapshot-Tabellen zusammen, die synchronisiert werden sollen. Durch Methoden der Java Replication Classes und der Replication OLE Control können der Refresh-Gruppe Snapshots hinzugefügt oder entfernt werden. Nach der Definition einer Refresh-Gruppe beginnt der eigentliche Synchronisationsvorgang. Dieser gliedert sich in zwei Phasen: Im ersten Schritt werden alle Änderungen einfacher Snapshots seit dem letzten Synchronisationsvorgang an den DB-Server übertragen (Æ Reintegration). Die Transaktionen der mobilen Clients werden auf der Server-Datenbasis nachvollzogen. Im zweiten Schritt werden an den Originaltabellen durchgeführten Änderungen auf die mobilen Clients übertragen (Æ Rückübertragung). Das mobile Datenbanksystem Sybase UltraLite implementiert mit MobiLink ein sitzungsbasiertes Synchronisationsverfahren, dessen Ablauf durch den MobiLink-Server koordiniert wird. Der MobiLink-Server kontrolliert für alle Clients sowohl die Ausführung der Synchronisation, als auch die zur Synchronisation benötigten Verwaltungsdaten (zur Ablaufsteuerung werden spezielle SQL- und Java-Skripte genutzt). Teilaufgaben sind die Koordination der Datenübertragung, die Automatisierung und Überwachung von Synchronisationssitzungen, die Auswahl von Kommunikationsprotokollen und die Erstellung von Reports, die dem DB-Administrator helfen können, Fehler aufzuspüren und zu beseitigen. Der MobiLink-Synchronisationsserver garantiert Transaktionsintegrität, d.h. eine Datenbank wird entweder ganz synchronisiert oder gar nicht. Die Synchronisation erfolgt wieder in zwei Phasen. Jeder mobile Client muss protokollierte Änderungsoperationen adäquat aufbereiten, um sie anschließend dem MobiLinkServer zu übermitteln. Genauso muss ein mobiler Client in der Lage sein, Daten in seine lokale Datenbank integrieren zu können, die vom MobiLink-Server (respektive dem DBServer) übermittelt wurden. Tamino Mobile fasst alle Synchronisationskomponenten zum MobileLogic-Framework zusammen. Für die Durchführung der Synchronisation ist der Tamino Mobile Smart Client (TMSC) zuständig. Der TMSC besteht aus dem Smart Client (SC) und dem Tamino Mobile Synchronization Server (TMSS). Der SC ist auf der mobilen Einheit installiert und nutzt ein spezielles SyncModule, das für die Steuerung eines Synchronisationsvorgangs zuständig ist. Die notwendigen Synchronisationsvorgänge selbst werden vom Entwickler noch während der Implementierung einer mobilen Anwendung definiert. Auf dem TMSS werden Arbeitsvorgangsvorlagen (Workflows) definiert, die genau festlegen, wie Daten, die von einer mobilen Einheit geschickt wurden, bearbeitet werden. Andere Workflows definieren Regeln zum Generieren neuer Daten, die an bestimmte mobile Einheiten geschickt werden müssen. DBS DB2 Everyplace Oracle 9i Lite Tamino Mobile Sybase UltraLite Konzepte des implementierten Synchronisationsverfahrens Synchronisation erfolgt über den Umweg einer Spiegeltabelle (Mirror Table) des Mid-Tier-Servers. Auftretende Synchronisationskonflikte werden durch den SyncServer erkannt und aufgelöst. Synchronisation entspricht einer Aktualisierung von Snapshots. Dazu werden verschiedene Verfahren (Full Refresh, Fast Refresh, Force Refresh) angeboten. Man unterscheidet zwischen einfachen (änderbaren) und komplexen (nicht änderbaren) Snapshots. Synchronisation erfolgt unter Verwendung spezieller Synchronisationskomponenten (Synchronization Server, SyncModule). Unterstützung eines bidirektionalen, sitzungsbasierten Synchronisationsverfahren, genannt MobiLink. Tabelle 2: Vergleich der implementierten Synchronisationsverfahren. 3 Anwendungsentwicklung und Ausblick Alle vier mobilen Datenbanksysteme realisieren Infrastrukturen für den Einsatz datenbankgestützter mobiler Anwendungen. Genauso wie sich die Systeme in den Konzepten ihrer Implementierung teilweise erheblich unterscheiden, hat eine praktische Evaluierung aller Systeme auch Unterschiede in Bezug auf die Unterstützung der Nutzer bei der Erstellung mobiler Datenbankanwendungen gezeigt. 3.1 Anwendungsentwicklung Mit DB2 Everyplace kann IBM wohl die vollständigste und am flexibelsten einsetzbare Lösung vorweisen. Besonders gelungen ist in diesem Zusammenhang der Mobile Application Builder, einem Entwicklungstool, mit dem schnell und einfach mobile Datenbankanwendungen erstellt werden können. Als Mitglied der DB2-Produktfamilie ist DB2 Everyplace weitestgehend auf die Zusammenarbeit mit anderen IBM-Komponenten abgestimmt, trotzdem können beispielsweise im Backend auch Datenbanksysteme anderer Hersteller als Replikationsquellen herangezogen werden. DB2 Everyplace unterstützt die dynamische Ausführung von SQL-Statements. Auf Datenbanktabellen kann über die Standard-APIs ODBC/CLI und JDBC zugegriffen werden. Auch Oracle bietet mit Oracle 9i Lite genau wie IBM eine ausgereifte Lösung für die Entwicklung mobiler Datenbankanwendungen an. Alle grundlegenden Anforderungen an mobile Datenbanksysteme werden erfüllt. Oracle Lite basiert auf einem ObjektKernel, auf den eine zusätzliche SQL-Schicht aufgesetzt ist. Auf der SQL-Schicht setzen die klassischen Anwendungsschnittstellen für den Zugriff auf Datenbanken, ODBC und JDBC, auf. Um die Funktionen des Kernels direkt ansprechen zu können, wird ein proprietäres Call Level Interface bereitgestellt, welches ein Object Kernel Application Interface (OKAPI) implementiert, das jedoch ausschließlich von C/C++-Anwendungen genutzt werden kann. Eine integrierte Entwicklungsumgebung, vergleichbar mit dem MAB von DB2 Everyplace, kann Oracle selbst jedoch nicht vorweisen. Diverse „normale“ Entwicklungsumgebungen, wie beispielsweise der JDeveloper von Oracle, unterstützen jedoch die Entwicklung mobiler Anwendungen. Mit Tamino Mobile (TMS) wird von der Software AG ein leistungsstarker Framework für die Entwicklung XML- und Java-basierter mobiler Anwendungen bereitgestellt. Mit dem Tamino Mobile Studio steht wie bei DB2 Everyplace eine Entwicklungsumgebung für die schnelle Erstellung von Tamino Mobile-Anwendungen bereit. Die Unterstützung extrem vieler (DeFacto-)Standards, wie Java, J2EE, XHTML, XML, XSL, VoiceXML oder WAP fördert einerseits die Definition und Verfügbarkeit eines offenen Frameworks, andererseits führt dies aber zu einer rasant zunehmenden Komplexität bei der Konzeption und Realisierung mobiler Anwendungen. Sybase UltraLite weist ein, im Vergleich zu anderen Anbietern, komplementäres Konzept auf, das durch die vollständige Integration bzw. „Einkompilierung“ einer Datenbank samt Datenbanklogik in eine UltraLite-Anwendung gekennzeichnet ist. Dadurch kann der benötigte Speicherplatz des Datenbanksystems reduziert werden. Dies erlaubt die Konzipierung und Realisierung von mobilen Anwendungen nicht nur auf PDAs oder Notebooks, sondern auch auf extrem leistungsschwachen mobilen Einheiten, wie Handys oder einfachen Organizern. Im Prozess der Anwendungsentwicklung (es stehen die Programmiersprachen C/C++ und Java zur Verfügung) muss die in ihrer Funktionalität angepasste Datenbank (Anwendungsdatenbank) in eine UltraLite-Anwendung integriert werden. Dabei wird auf eine Referenzdatenbank zurückgegriffen, die physisch auf einer Adaptive Server Anywhere-Installation eingerichtet sein muss. Adaptive Server Anywhere ist ein von Sybase angebotenes HochleistungsDatenbanksystem. Die Referenzdatenbank wird ausschließlich während der Entwicklungsphase benötigt. Auf ähnliche Weise können auch Pointbase Micro und eXtremeDB eingeordnet werden (auch wenn bei diesen beiden Produkten die tatsächliche Anwendungsentwicklung anders erfolgt). 3.2 Ausblick Aktuelle Tendenzen im Bereich mobiler Datenbanken zeigen, dass die prinzipiellen Problemstellungen weitestgehend gelöst sind, während technische Details durchaus noch Probleme bereiten. Fortschritte sind vor allem in der Unterstützung der Anwendungsentwicklung zu erwarten. Der Mobile Application Builder von IBM zeigt diesbezüglich die Richtung auf. Zusätzliche Impulse sind auch durch die Zielsetzung weitestgehender Automatisierung aller Aspekte von Replikation und Synchronisation zu erwarten. So hat IBM das Automatic Computing – und das nicht nur im Datenbankbereich – zu einem neuen Entwicklungsschwerpunkt erhoben. Schwierigkeiten – insbesondere bei der Konzeption und Realisierung mobiler Datenbankanwendungen – macht die große Vielfalt existierender Mobilplattformen (Palm OS, Windows Mobile 2003, Symbian OS, etc.), die die Entwicklung universell einsetzbarer mobiler Anwendungen stark einschränkt. Die Einführung des Mobile Information Device Profile 2 (MIDP2) stellt aber einen neuen Versuch der Etablierung einer plattformunabhängigen Mobilplattform dar. Alle großen Anbieter von Datenbanktechnologie (IBM, Oracle, Sybase, Software AG) sind im Segment mobiler Datenbanken vertreten. Nischenanbieter wie Pointbase Micro oder eXtremeDB werden sich dagegen nur im Bereich sehr spezieller Anwendungsdomänen etablieren können. Literaturverzeichnis [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] T.Fanghänel, J.S. Karlsson, C.Leung. DB2 Everyplace Database Release 8.1: Architecture and Key Features. Datenbank Spektrum - Zeitschrift für Datenbanktechnologie. Heft 5/2003. Mai 2003. pp 9-15. C.Gollmick. Nutzerdefinierte Replikation zur Realisierung neuer mobiler Datenbankanwendungen. GI-Reihe Lecture Notes in Informatics. Band P-26. pp 453-462. 2003. R.Greenwald, R.Stackowiak, J. Stern. Database Management. White Paper. 2002. N.Mielke. DB2 Everyplace: An Overview. IBM Research, Silicon Valley Lab. 2001. A.Noether. Extending Enterprise Data to Mobile Devices. IBM White Paper. 2002. DB2 Everyplace Dokumentation. Juni 2003. Oracle 9i Lite Dokumentation. Juni 2003. SQL Anywhere Studio 8 Dokumentation. Juni 2003. Tamino Mobile Dokumentation. Juni 2003. Pointbase Micro Dokumentation. Juni 2003. eXtremeDB Dokumentation. Juni 2003. Implementierung eines medizinischen Kommunikationsstandards auf einem PDA unter Linux Dipl.-Inf. Christian Weigand Bildverarbeitung und Medizintechnik/BMT Fraunhofer Institut für Integrierte Schaltungen IIS Am Wolfsmantel 33 91058 Erlangen [email protected] Abstract: Die zunehmende Vernetzung medizinischer Geräte legt nahe, die zugrunde liegenden Kommunikationsstrukturen unter Verwendung offener Architekturen und standardisierter Protokolle zu implementieren. Dies trifft gleichfalls auf den Bereich der mobilen Kommunikation, also der Kommunikation zwischen mobilen Kleinstgeräten, zu. Die Abteilung Bildverarbeitung und Medizintechnik des Fraunhofer Instituts für integrierte Schaltungen beschäftigt sich sowohl mit der drahtlosen Kommunikation in der Medizin, als auch mit der Umsetzung von Standards in der medizinischen Kommunikation. Aus der Zusammenführung dieser beiden Bereiche ist die hier vorgestellte Applikation, die Implementierung des Standards VITAL auf einem Linux PDA, entstanden. 1 Kommunikationsstandards Aktuelle Standards wie CEN ENV 13734/13735 „Vital Signs Information Representation“, kurz VITAL [VITAL], oder der vom CIC1 Konsortium entwickelte Standard POCT1-A [POCT1] für Point-of-Care Geräte2, ermöglichen Interoperabilität zwischen Geräten verschiedener Hersteller. Dies bedeutet, dass durch die Verwendung von Standards der erhebliche Mehraufwand bei der Integration und Anpassung unterschiedlicher Geräte in heterogene Netze eingespart werden kann. Diese Standards definieren ein allgemeines Daten- und Kommunikationsmodell für die Codierung und die geräteunabhängige Übertragung von Vitalparametern. 1 2 CIC - Connectivity Industry Consortium. Bei Point-of-Care Geräten handelt es sich um Laborgeräte, die direkt am Krankenbett zum Einsatz kommen. POCT1-A wurde vom Connectivity Industry Consortium ins Leben gerufen und ist unter dem Aspekt Laborgeräte zu vernetzen entstanden. Mittlerweile ist dieser Industriestandard aber auf dem Weg, die internationalen Standardisierungsgremien zu passieren, und damit in den Status eines offiziellen Standards gehoben zu werden. Wie in Abbildung 1 zu sehen ist, definiert POCT1-A zwei verschiedene Interfaces, um Laborgeräte mit einem Krankenhausinformationssystem (KIS) zu verbinden. Dabei hilft die Definition von einheitlichen Nachrichtentypen in XML3 auf Seiten des „Device Interface“ jedes beliebige POCT1-A-fähige Gerät in die Kommunikationskette einzubringen. Abbildung 1: POCT1 Kommunikationskette Das „Observation Reporting Interface“ dagegen definiert Nachrichten in HL74-Syntax [HL7], um die Verbindung zu einem Laborinformationssystem (LIS) herzustellen. Somit ist eine durchgängige Anbindung der Point-of-Care-Geräte gewährleistet. Im Gegensatz zu POCT1-A stand bei der Entwicklung von VITAL die Echtzeitfähigkeit im Vordergrund. Daher eignet sich VITAL besonders um beispielsweise EKG- oder EEG-Daten zu übertragen. Aber auch kombinierte Geräte wie Patientenmonitore mit unterschiedlichen Messgrößen können mittels VITAL einfach modelliert werden. Die Abbildung 2 zeigt beispielhaft eine solche Modellierung eines kombinierten Temperaturund Blutdruckmessgeräts. 3 4 XML – extensible markup language HL 7 – Health Level Seven; Kommunikationsstandard für Krankenhausinformationssysteme (KIS) Abbildung 2: Kombiniertes VITAL-Gerät Speziell hierfür ist im VITAL-Standard ein vollständig objektorientiertes Modell für die Datenhaltung und die Kommunikation entstanden. Die Abbildung 2 zeigt diese verschiedenen Objekte, wie das „Medical Device System“ (MDS), „Virtual Medical Device“ (VMD) und Numeric, die fast beliebig kombinierbar sind. Für jeden numerischen Wert, wie zum Beispiel die Temperatur, wird ein Numeric-Object angelegt, das neben dem Messwert auch Informationen über die Einheit (°C), den Messzeitpunkt, den Status, etc bereitstellt. Über je ein „Virtual Medical Device“ (VMD) werden die beiden einzelnen Messgeräte zu einem „Medical Device System“ (MDS) zusammengeführt. Zur Verwaltung technischer Fehler oder patienten-bezogener Alarme können hier auch noch andere Objekte, wie beispielsweise der AlertMonitor, an das MDS angegliedert werden. Dieses Objektmodell stellt somit eine Art objektorientierte Datenbank des/der medizinischen Sensor/en dar. Das besondere daran ist, dass der Empfänger der Datenübertragung das Objektmodell (MDIB5) des Senders, also des medizinischen Gerätes oder Sensors, vollständig nachbildet, wie das ISO/OSI-Schichtmodell in Abbildung 3 zeigt. Dadurch wird sichergestellt, dass der Empfänger zu jederzeit über den Zustand und die Konfiguration seines Gegenübers Bescheid weiß. Eine Verabredung und Aushandlung der Modalitäten der Kommunikation kann somit voll automatisch geschehen. Dies ist einer der besonderen Vorzüge von VITAL, die sogenannte „Plug and Play“-Fähigkeit. Der Abbildung 3 ist ebenfalls zu entnehmen, dass sich VITAL auf die Applikationsschicht des ISO/OSI-Modells beschränkt. Damit ist eine Implementierung von VITAL weitgehend unabhängig von den darunter liegenden Schichten. Es bleibt also dem Anwender überlassen wie er die Schichten 1 - 6 umsetzen möchte. Abbildung 3 VITAL Schichtenmodell 5 MDIB – Medical Data Information Base Ein weiterer Bestandteil der VITAL-Spezifikation ist eine Nomenklatur, die mehrere tausend Begriffe aus dem medizinischen Umfeld umfasst. Jeder Begriff wird dabei durch einen standardisierten 16 Bit Code gekennzeichnet – ähnlich dem aus der Laborwelt gängigen LOINC6 [LOINC]. Die geringe Wortbreite von 16 Bit ermöglicht einerseits die Nachrichtenlängen bei der Datenübertragung zu minimieren, erfordert aber andererseits den Codierungsraum in mehrere kontextabhängige Räume zu unterteilen. Folglich können dem selben Code, je nachdem in welchem Bezug er steht, vollkommen verschiedene Bedeutungen zukommen. Da davon ausgegangen wird, dass die Nomenklatur noch nicht komplett ist und zudem Neuentwicklungen zu erwarten sind, enthält jeder Codierungsraum einen ungenutzten Bereich von 4096 Werten. Dieser Bereich kann zwischenzeitlich für eigene Codes genutzt werden solange diese noch nicht in den Standard aufgenommen sind. 2 Mobiles Disease Management Für Anwendungen wie beispielsweise »Mobil Disease Management« ist es notwendig ein solches Kommunikationsprotokoll sowohl auf dem embedded System der medizinischen Sensorik, als auch den Empfängern dieser Daten zu implementieren, um eine unabhängige Interoperabilität zwischen allen an der Kommunikation beteiligten Geräte zu erreichen. Da heutige medizinische Geräte noch keine Standards unterstützen, muss zur Demonstration der Vorteile einer solchen Umsetzung der Umweg über ein zusätzliches embedded System gegangen werden. Ein solches sogenanntes Gateway liest die medizinischen Messwerte proprietär ein und stellt sich nach außen als ein standardkonformes Gerät dar. Bereits in der Vergangenheit wurden solche Gateways bei uns entwickelt. Da diese Entwicklung MMU7-loser embedded Systeme auf einem embedded Linux basieren, haben wir für eine leistungsstärkere Variante, die sowohl eine grafische Ausgabe als auch eine rudimentäre Signalverarbeitung beherrschen soll, einen handelsüblichen PDA8 [Ro02] gewählt. Dieses Gerät bietet nicht nur alle Vorzüge eines PDAs, sondern es beherbergt bereits von Haus aus eine embedded Linux Variante als Betriebssystem. Dies ermöglicht uns gewisse Synergien bei der Applikationsentwicklung auf allen embedded Systemen zu nutzen. 6 LOINC - Logical Observation Identifiers Names and Codes MMU – memory management unit 8 PDA – personal digital assistant 7 3 VITAL Implementierung Ein Beispiel einer solchen Implementierung stellt die Koppelung eines Langzeit EKGs mit einem Handheld-Computer (PDA) dar. Das EKG ist mit dem PDA über eine serielle Leitung verbunden. Über diese Kabelverbindung werden die EKG-Daten über das herstellerspezifische Protokoll ausgelesen. Die gesammelten EKG-Daten werden auf dem PDA visualisiert. Hier hat man die Möglichkeit eine erste Vorauswertung zu treffen, und mit einer geeigneten Algorithmik Unregelmäßigkeiten, zum Beispiel einen bevorstehenden Herzinfarkt, festzustellen oder den Puls des Patienten aus dem EKGSignal zu errechnen. In den compact-flash Einschub des PDAs kann entweder eine Bluetooth [Ro02] Karte oder eine WLAN [Ro02] Karte eingesteckt werden. Mit deren Hilfe können die EKG-Messungen drahtlos an einen PC oder einen anderen PDA zur Visualisierung, Auswertung und Archivierung übertragen werden. Dabei ist die direkte Übernahme der Daten in ein Krankenhaus Informationssystem (KIS) ebenfalls denkbar. Damit steht eine durchgängige Kommunikationskette zur Verfügung, mit deren Hilfe die Messergebnisse medizinischer Sensorik direkt in die elektronische Patientenakte des Betroffenen abgelegt werden können. Abbildung 4: Sharp Zaurus SL-5500G Der hier eingesetzte PDA ist ein Linux PDA der Firma Sharp (Abbildung 4). Hierfür wurde eigens eine C++/Qt embedded9-Applikation geschrieben. Die Applikation selbst gliedert sich in ein Framework mit Plug-In-Mechanismus und eine VITAL-Bibliothek. In der Bibliothek sind alle VITAL-spezifischen Klassen gekapselt. Über diese Bibliothek ist das Framework in der Lage eine VITAL-konforme Kommunikation aufzubauen. 9 Qt embedded– Programmierframework das sich von dem sowohl unter Linux als auch Windows einsetzbaren Qt Framework ableitet. Über die vier verschiedene Plug-In-Arten (MEDICAL, COM, SIGNAL, GUI), die Abbildung 5 zeigt, kann das Framework je nach Anforderung erweitert werden. Mit einem Medical-Plug-In kann nicht nur ein EKG oder Blutdruckmessgerät realisiert werden, sondern jedes medizinische Gerät, das an den PDA angeschlossen werden kann. Dazu muss lediglich ein entsprechendes Medical-Plug-In geschrieben werden, das die medizinischen Daten über das proprietäre Protokoll des Geräteherstellers ausliest. Abbildung 5 VITAL Framework Für die Kommunikationsschnittstelle existiert der Plug-In-Mechanismus COM. Dieser erlaubt es mit dem entsprechenden Plug-In sowohl eine Bluetooth als auch eine WLAN Karte zur Übermittlung der Daten einzusetzen. Aber auch für andere Schnittstellen, wie zum Beispiel die Infrarotschnittstelle, kann ein Plug-In eingesetzt werden. Selbst die Oberfläche zur grafischen Darstellung besteht aus Plug-In-Modulen (GUI-Plug-In), um die Anzeige für jede medizinische Anwendung flexibel zu halten. Die vierte Plug-InSchnittstelle (SIGNAL) erlaubt es zur Signalverarbeitung verschiedene Module zu laden. Diese können dann auf den passenden medizinischen Daten im Rahmen der Leistungsfähigkeit des PDAs eine gewisse Vorklassifikation betreiben. So ist es möglich aus dem EKG den Puls zu errechnen oder Anzeichen für einen bevorstehenden Herzinfarkt zu erkennen. Da die grafische Oberfläche des Linux PDAs auf dem Qtopia-Desktop der Firma Trolltech beruht, wurde auch die Visualisierung des EKG-Signals unter zu Hilfenahme der embedded Qt-Bibliothek [Qt01] implementiert [He01], die schon im Qtopia-Desktop Verwendung gefunden hat. Dies erlaubt es die Applikation leicht auf die PC-Seite der Kommunikationsstrecke zu portieren. Da QT für Linux Systeme ebenso existiert wie für Windows Systeme kann hier sowohl Linux als auch Windows zum Einsatz kommen. Damit konnte eine komplette Plattformunabhängigkeit vom embedded Linux des PDAs über das PC Linux bis zum Windows PC erreicht werden. Die Abbildung 6 zeigt einen Screenshot dieser Applikation, die mit geladenem EKGPlug-In auf dem PDA läuft. Abbildung 6: EKG Applikation auf dem Zaurus Diese Entwicklung ermöglicht es einen Patienten beispielsweise zu Hause, in seiner Freizeit oder bei beruflichen Aktivitäten problemlos aus der Ferne zu überwachen. Dabei kann ein EKG aufgenommen werden und über eine Funkstrecke, die optimale Bewegungsfreiheit garantiert, an einen PC mit Internetanschluss übertragen werden. Von dort aus kann eine standardisierte Übertragung der Daten zum Arzt oder Krankenhaus für eine kontinuierliche oder stichprobenhafte Überwachung erfolgen. Aber auch im Krankenhaus ist ein schnelles Monitoring von jedem Ort aus denkbar. Mit Hilfe eines zweiten PDAs und einem in verschiedenen Krankenhäusern bereits installierten WLAN Netzwerk kann der betreuenden Arzt sich die Daten seiner Patienten unabhängig von seinem Aufenthaltsort auf den Bildschirm rufen und begutachten. 4 Ergebnisse Obwohl es sich bei VITAL um einen Kommunikationsstandard handelt, der nicht speziell auf embedded Geräte zugeschnitten, sondern bewusst umfassend und global angelegt wurde, ist es möglich ohne übermäßige Anstrengung und Ressourcenverschwendung diesen Standard auf Kleinstgeräten, die dem heutigen Stand der Technik entsprechen, umzusetzen. Durch die Skalierbarkeit des Standards auf die jeweiligen Bedürfnisse der medizinischen Anwendung ist eine Portierung auf wesentlich leistungsärmere embedded Systeme machbar. Dies wird durch das hier verwendete Linux weiter unterstützt, da dieses ebenfalls leicht auf kleinere Systeme skalierbar ist und somit sogar eine Portierung der gesamten Applikation auf ein anderes System erheblich vereinfacht. Je nach Größe des embedded Systems und des Vorhandensein eines Displays kann natürlich auf eine Visualisierung des EKG-Signals verzichtet werden. Die Entwicklung einer durch Plug-Ins beliebig erweiterbaren Applikation macht den hier verwendeten PDA zu einem universell einsetzbaren Adapter für alle medizinischen Messgeräte und Anwendungen. Unterstützt durch die Verwendung der Qt Bibliothek ist auch eine Portierung der Software auf andere Geräte (PDAs) und Betriebssysteme leicht zu bewerkstelligen. Bereits jetzt existieren für die verschiedenen Anwendungsgebiete in der Medizin verschiedene Kommunikationsstandards. Diese werden sich in der Zukunft nach und nach direkt in den verschiedenen medizinischen Geräten wiederfinden. Dank der immer größeren Verbreitung der drahtlosen Kommunikation ist eine lückenlose Dokumentation und Überwachung von beispielsweise Risikopatienten nicht nur in den Kliniken sondern auch zu Hause zu erreichen. Deshalb gehen verschiedene Gerätehersteller bereits jetzt dazu über ihre Geräte auch mit Funkschnittstellen auszustatten. 5 Literaturverzeichnis [VITAL] VITAL ENV 13734/13735 “Vital Signs Information Representation” CEN Standard Dokument. [POCT1] POCT1-A Connectivity Industry Consortium (CIC) Standard, http://www.poccic.org. [LOINC] Logical Observation Identifiers Names and Codes, http://www.loinc.org. [HL7] Health Level Seven, http://www.hl7.de. [He01] Herold, H.: Das Qt-Buch: portable GUI-Programmierung unter Linux/Unix/Windows, SuSE-Press, Nürnberg, 2001. [Qt01] Qt/Embedded: The C++ Embedded GUI Application Developer’s Toolkit, Trolltech AS, Oslo, 2001. [Ro02] Roth, J.: Mobile Computing: Grundlagen, Technik, Konzepte, dpunkt.verlag, Heidelberg, 2002. Teilnehmerliste (Stand der Anmeldungen 15.10.2003) Felix Alcala Otto-von-Guericke-Universität Magdeburg [email protected] Karsten Baumgarten Friedrich-Schiller-Universität Jena Institut für Informatik D-07740 Jena [email protected] Jöran Beel Otto-von-Guericke-Universität Magdeburg [email protected] Gert Brettlecker Private Universität für Medizinische Informatik und Technik Tirol (UMIT) Institut für Informationssysteme A-6020 Innsbruck, Österreich [email protected] Prof. Dr. Martin Breunig Forschungszentrum für Geoinformatik und Fernerkundung Hochschule Vechta Postfach 1553 D-49364 Vechta [email protected] Michael Cammert Philipps-Universität Marburg Fachbereich Mathematik und Informatik Hans Meerwein Straße D-35032 Marburg [email protected] Peter Dornbusch CDTM Center for Digital Technology & Management Arcisstr. 21 D-80290 München [email protected] Arne Frenkel Otto-von-Guericke-Universität Magdeburg [email protected] Christoph Gollmick Friedrich-Schiller-Universität Jena Institut für Informatik D-07740 Jena [email protected] Dr. Torsten Grabs ETH Zürich Institut für Informationssysteme ETH Zentrum CH-8092 Zürich [email protected] Klaus Haller ETH Zürich Institut für Informationssysteme ETH Zentrum, IFW C47.2 CH-8092 Zürich [email protected] Günter Hector MAQSIMA GmbH Am TÜV 1 D-66280 Sulzbach [email protected] Christoph Heinz Philipps-Universität Marburg Fachbereich Mathematik und Informatik Hans Meerwein Straße D-35032 Marburg [email protected] Hagen Höpfner Otto-von-Guericke-Universität Magdeburg Institut für Technische und Betriebliche Informationsysteme Universitätsplatz 2 D-39106 Magdeburg [email protected] Michael Klein Universität Karlsruhe Fakultät für Informatik Institut für Programmstrukturen und Datenorganisation Postfach 6980 D-76128 Karlsruhe [email protected] Dr. Birgitta König-Ries Universität Karlsruhe Fakultät für Informatik Institut für Programmstrukturen und Datenorganisation Postfach 6980 D-76128 Karlsruhe [email protected] Thomas Königsmann Fraunhofer Institut für Software- und Systemtechnik Emil-Figge-Str. 91 D-44227 Dortmund [email protected] Prof. Dr. Jung Sun Lie FH Braunschweig/Wolfenbüttel Salzdahlumer Str. 46/48 D-38302 Wolfenbüttel [email protected] Johannes Lülf Otto-von-Guericke-Universität Magdeburg [email protected] Bela Mutschler Universität Ulm Abt. Datenbanken und Informationssysteme Oberer Eselsberg D-89069 Ulm [email protected] Prof. Dr. Hans-Jörg Schek ETH Zürich Institut für Informationssysteme ETH Zentrum CH-8092 Zürich [email protected] Prof. Dr. Heiko Schuldt Private Universität für Medizinische Informatik und Technik Tirol (UMIT) Abteilung Information and Software Engineering A-6020 Innsbruck, Österreich [email protected] Prof. Dr. Günther Specht Universität Ulm Abt. Datenbanken und Informationssysteme Oberer Eselsberg D-89069 Ulm [email protected] Dr. Can Türker ETH Zürich Institut für Informationssysteme ETH Zentrum, IFW C47.2 CH-8092 Zürich [email protected] Christian Weigand Fraunhofer-Institut für Integrierte Schaltungen IIS Abteilung Bildverarbeitung / Medizintechnik Am Wolfsmantel 33 D-91058 Erlangen [email protected] Peter Wilhelm MAQSIMA GmbH Am TÜV 1 D-66280 Sulzbach [email protected] Andre Zeitz Universität Rostock Fachbereich Informatik Lehrstuhl Datenbank- und Informationssysteme Albert-Einstein-Strasse 21 D-18051 Rostock [email protected] Call for Papers Mobilität und Informationssysteme Workshop des GI-Arbeitskreises "Mobile Datenbanken und Informationssysteme" 16. und 17. Oktober 2003 in Zürich http://www.dbs.ethz.ch/~tuerker/mdbis/ Die Infrastruktur moderner Informationssysteme besteht nicht nur aus statischen Komponenten, sondern verstärkt aus mobilen Geräten wie Laptops, PDAs und Handheld-PCs, die über drahtlose Netze miteinander kommunizieren. Mobile Geräte sind zudem mittlerweile so leistungsstark, dass sie immer mehr auch als Erbringer komplexer Dienste fungieren. Ehemals isolierte Datenquellen und Dienste können so dynamisch zu virtuellen Informationsräumen zusammenwachsen, in denen von der Mobilität der beteiligten Nutzer, Daten und Dienste abstrahiert werden. Mobile Nutzer können Information jederzeit und von überall individuell erzeugen, abfragen und verarbeiten. Die mobile Informationsverarbeitung eröffnet nicht nur die Perspektive für eine Vielzahl spannender und nützlicher Anwendungen, etwa aus dem Bereich der Gesundheitsversorgung, dem Ressourcenmanagement oder der Navigationssysteme, sondern stellt auch neue Herausforderungen an die Forschung und Entwicklung zukünftiger Informationssysteme, etwa an die Koordination von mobilen Komponenten in hochgradig verteilten und vor allem sich dynamisch ändernden Informationsräumen. Dieser Workshop soll Vertreter von Hochschulen, Produkthersteller und Anwender mobiler Datenbanken und Informationssysteme zusammenführen und ihnen die Möglichkeit bieten, ihre Beiträge im Kreis fachlich interessierter Kollegen zu diskutieren. Dabei sollen sowohl Grundlagenfragen als auch Aufgabenstellungen aus Anwendungs- und Technologiebereichen erörtert werden. Erbeten werden Beiträge, die folgende oder verwandte Themengebiete unter dem Gesichtspunkt der Auswirkung von Mobilität auf Informationssysteme betrachten: Architektur und Implementierung mobiler Informationssysteme Benutzerschnittstellen und Informationsanpassung/-präsentation Anpassungsfähige, selbstoptimierende mobile Informationskomponenten Sensor-Datenbanken und kontinuierliche Anfragen Informationsströme und eingebettete Datenbanken Personalisierung und Sicherheit Kooperation und mobile Agenten Mobile Service-Grids und Ad-hoc-Informationsräume Mobile Peer-to-Peer-Infrastrukturen Die Beiträge können eigene Lösungen für die obigen Problemstellungen präsentieren oder auch offene Fragestellungen und Anforderungen an zu entwickelnde Lösungen beschreiben. Visions- und Anwenderpapiere sowie Berichte über neue Projekte im Umfeld mobiler Informationssysteme sind ausdrücklich erwünscht. Die Workshop-Sprache ist Deutsch. Einreichungen (in PDF) können ab sofort unter [email protected] vorgenommen werden. Akzeptiert werden deutsch- und englischsprachige Beiträge. Langbeiträge sind auf maximal 10 Seiten in LNI-Format begrenzt (Kurzbeiträge: 5 Seiten). Hinweise zur LNI-Formatierung finden Sie unter http://giserver.gi-ev.de/LNI/autorenrichtlinien/. Eingereichte Beiträge werden von mindestens zwei Mitgliedern des Programmkomitees sorgfältig geprüft. Akzeptierte Beiträge erscheinen in den WorkshopProceedings, die als technischer Bericht veröffentlicht wird. TERMINE Deadline für Einreichungen von Beiträgen: 01.08.2003 Benachrichtigung über Annahme/Ablehnung: 05.09. 2003 Abgabe Endfassung (camera-ready): 26.09.2003 Workshop: 16./17.10.2003 Modellierung und Verwaltung beweglicher Objekte und mobiler Nutzer Beschreibung, Auffindung und Inanspruchnahme mobiler Dienste Komposition und Ausführung von mobilen Diensten Quality-of-Service für mobile Dienste Replikation, Caching, Synchronisation Anfragebearbeitung, Indexierung, Optimierung Ortsabhängiger Zugriff und kontextbasierte Anfragen PROGRAMMKOMITEE Jürgen Bittner (SQL GmbH, Dresden) Christoph Gollmick (Uni Jena) Hagen Höpfner (Uni Magdeburg) Birgitta König-Ries (Uni Karlsruhe) Klaus Küspert (Uni Jena) Holger Meyer (Uni Rostock) Günther Specht (Uni Ulm) Can Türker (ETH Zürich) Call for Participation Mobilität und Informationssysteme Workshop des GI-Arbeitskreises "Mobile Datenbanken und Informationssysteme" 16. und 17. Oktober 2003 in Zürich http://www.dbs.ethz.ch/~tuerker/mdbis/ Liebe Mitglieder und Freunde des GI Arbeitskreises "Mobile Datenbanken und Informationssysteme", liebe am Thema "Mobilität" Interessierte, Donnerstag, 16.10.2003 der Workshop "Mobilität und Informationssysteme" ist der fünfte Workshop des GI-Arbeitskreises "Mobile Datenbanken und Informationssysteme" und gleichzeitig das Herbsttreffen 2003 dieses Arbeitskreises. 13:30-13:45 Begrüssung Die Infrastruktur moderner Informationssysteme besteht nicht nur aus statischen Komponenten, sondern verstärkt aus mobilen Geräten wie Laptops, PDAs und Handheld-PCs, die über drahtlose Netze miteinander kommunizieren. Mobile Geräte sind mittlerweile so leistungsstark, dass sie immer mehr auch als Erbringer komplexer Dienste fungieren. Ehemals isolierte Datenquellen und Dienste können so dynamisch zu virtuellen Informationsräumen zusammenwachsen, in denen von der Mobilität der beteiligten Nutzer, Daten und Dienste abstrahiert werden. Mobile Nutzer können Information jederzeit und von überall individuell erzeugen, abfragen und verarbeiten. Die mobile Informationsverarbeitung eröffnet nicht nur die Perspektive für eine Vielzahl spannender und nützlicher Anwendungen, etwa aus dem Bereich der Gesundheitsversorgung, dem Ressourcenmanagement oder der Navigationssysteme, sondern stellt auch neue Herausforderungen an die Forschung und Entwicklung zukünftiger Informationssysteme, etwa an die Koordination von mobilen Komponenten in hochgradig verteilten und vor allem sich dynamisch ändernden Informationsräumen. Dieser Workshop soll Vertreter von Hochschulen, Produkthersteller und Anwender mobiler Datenbanken und Informationssysteme zusammenführen und ihnen die Möglichkeit bieten, ihre Beiträge im Kreis fachlich interessierter Kollegen zu diskutieren. Dabei sollen sowohl Grundlagenfragen als auch Aufgabenstellungen aus Anwendungs- und Technologiebereichen erörtert werden. Kurzfristige Anmeldungen zum Workshop sind möglich! Die Tagungsgebühr beträgt 40.00 Euro (10.00 Euro für Studenten). Bitte schicken Sie Ihre Anmeldung an [email protected]. Über eine rege Teilnahme würden wir uns sehr freuen! 12:30-13:30 Registrierung 13:45-14:15 B. Mutschler, G. Specht: Implementierungskonzepte und Anwendungsentwicklung kommerzieller mobiler Datenbanksysteme: Ein Vergleich 14:15-14:45 K. Baumgarten, C. Gollmick: Konzeption eines interaktiven mobilen Reiseinformationssystem 14:45-15:15 F. Alcala, J. Beel, A. Frenkel, B. Gipp, J. Lülf, H. Höpfner: Ortung von mobilen Geräten für die Realisierung lokationsbasierter Diensten 15:15-15:45 Pause 15:45-16:15 P. Dornbusch, M. Huber: User-Toolkits zur dienstbasierten Entwicklung mobiler Applikationen 16:15-16:45 T. Königsmann: Konzeption geräteübergreifender Anwendungen 16:45-17:15 M. Cammert, C. Heinz, J. Krämer, B. Seeger: Datenströme im Kontext des Verkehrsmanagements ab 18:30 „Informal Get-Together“ Freitag, 17.10.2003 09:00-10:00 H. Schuldt: Sensor Data Stream Processing in Health Monitoring 10:00-10:30 Pause 10:30-10:55 C. Weigand: Implementierung eines medizinischen Kommunikationsstandards auf einem PDA unter Linux 10:55-11:20 M. Breunig, R. Malaka, W. Reinhardt, J. Wiesel: Vision mobiler Geodienste 11:20-12:15 Öffentliches Herbsttreffen des Arbeitskreises "Mobile Datenbanken und Informationssysteme" 12:15 Ende des Workshops