Mobilität und Informationssysteme - ETH E-Collection

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
Jürgen Bittner
Christoph Gollmick
Hagen Höpfner
Birgitta König-Ries
Klaus Küspert
Holger Meyer
Günther Specht
Can Türker
SQL GmbH, Dresden
Universität Jena
Universität Magdeburg
Universität Karlsruhe
Universität Jena
Universität Rostock
Universität Ulm
ETH Zürich
Externe Gutachter
Thomas Müller
Universität Jena
Lokale Organisation
Can Türker
Antoinette Galler
ETH Zürich
ETH Zürich
Vorwort
Der fünfte Workshop des GI-Arbeitskreises Mobile Datenbanken und Informationssyste”
me“ findet unter dem Titel Mobilität und Informationssysteme“ am 16./17. Oktober 2003
”
in Zürich statt. Wie seine Vorgänger soll auch dieser Workshop Vertreter von Hochschulen,
Produkthersteller und Anwender mobiler Datenbanken und Informationssysteme zusammenführen und ihnen die Möglichkeit bieten, ihre Beiträge im Kreis fachlich interessierter
Kollegen zu diskutieren. Dabei sollen sowohl Grundlagenfragen als auch Aufgabenstellungen aus Anwendungs- und Technologiebereichen erörtert werden.
Der vorliegende Bericht enthält die Beiträge zu diesen Workshop. Insgesamt wurden sechs
Lang- und zwei Kurzbeiträge angenommen. Diese Workshop-Beiträge spiegeln ein breites Spektrum des Gebietes Mobile Datenbanken und Informationssysteme“ wider und
”
bieten interessante Ansatzpunkte für spannende Diskussionen. Hinzu kommt ein eingeladener Beitrag von Prof. Dr. Heiko Schuldt von der Privaten Universität fü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 für ihre Einreichungen, den Programmkomiteemitgliedern und externen Gutachtern für die Begutachtung und Auswahl der eingereichten Beiträge, und Prof. Dr. Heiko
Schuldt für die Annahme der Einladung zu einem Vortrag. Last but not least geht ein spezieller Dank an Antoinette Galler für Ihre Unterstützung bei der lokalen Organisation.
Zürich, Oktober 2003
Can Türker
Inhaltsverzeichnis
Heiko Schuldt, Gert Brettlecker
Sensor Data Stream Processing in Health Monitoring
Felix Alcala, Jöran Beel, Arne Frenkel, Bela Gipp, Johannes Lülf, Hagen Höpfner
Ortung von mobilen Geräten fü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, Jürgen Krämer, Bernhard Seeger
Datenströme im Kontext des Verkehrsmanagements
Peter Dornbusch, Martin Huber
User-Toolkits zur dienstbasierten Entwicklung mobiler Applikationen
Thomas Königsmann
Konzeption geräteübergreifender Anwendungen
Bela Mutschler, Gü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 Ö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., Böhm, K., Grabs, T., Rö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 Geräten für die Realisierung
lokationsbasierter Diensten
Felix Alcala
[email protected]
Jöran Beel
[email protected]
Johannes Lülf
[email protected]
Arne Frenkel
[email protected]
Béla Gipp
[email protected]
Hagen Höpfner∗
[email protected]
Otto-von-Guericke-Universität Magdeburg
Postfach 4120, 39016 Magdeburg, Deutschland
Abstract: Die Entwicklung im Sektor von mobilen Endgeräten geht eindeutig in die
Richtung, immer kompaktere Geräte mit immer mehr Funktionalität anzubieten. Schon
heute können z.B. Laptops oder sogar PalmTops mit GPS-Kontrollern kombiniert werden. Die somit verfügbaren genauen Positionsinformationen ermöglichen die Realisierung von unterschiedlichsten lokationsbasierten Diensten. Ziel des in diesem Papier
vorgestellten Projektes ist es, die Möglichkeiten derartiger Szenarien zu untersuchen.
Dazu wird ein System vorgestellt, welches die ad-hoc Lokalisierung von Nutzern von
mobilen Endgeräten mittels mobiler Endgeräte ermö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 Endgeräte deren Kompaktheit und Leistungsfähigkeit ist. Nutzer mobiler Endgeräte wie Laptops, PDAs oder Handys können
sich unabhängig von Büroräumen und Schreibtischen bewegen und dennoch die Funktionen ihrer Geräte ausschöpfen. In Kombination mit der kabellosen Vernetzung und der Lokalisierung derartiger Geräte ergibt sich aus Sicht der Anbieter von Informationssystemen
daraus die Mö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 ﬂächendeckend verfügbaren Funknetztechnologien (GSM [ETS93], GPRS
[ETS98], HSCSD [ETS99]) einen zellulären Charakter aufweisen, kann zum einen über
die zur Einwahl notwendigen Basisstationen mittels Triangulation die ungefähre Position
eines Gerätes ermittelt werden. Zum anderen besteht die wesentlich genauere Möglichkeit
der Positionsbestimmung unter Verwendung des GPS [Kap96]. Beide Verfahren haben
Vor- und Nachteile, welche hier aber nicht tiefergehend erläutert werden sollen.
∗ Gefördert
durch die DFG unter der Fördernummer SA 782/3-2.
Das in dem Beitrag beschriebene Projekt wurde als Grundlage für die Weiterentwicklung des beim Jugend-forscht“-Wettbewerb 2002 präsentierten und prä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 ursprüngliche Ansatz nutzt die Zell-Triangulation zur Positionsbestimmung.
Um eine noch genauere Lokalisierung zu ermöglichen wurde im Rahmen der hier vorgestellten Arbeit untersucht, ob und wie sich das GPS eignet, um derartige lokationsbasierte
Informationssysteme zu unterstützen.
Die Aufgabenstellung wurde im Rahmen eines Softwarepraktikums am Institut für Technische und Betriebliche Informationssysteme der Fakultät für Informatik an der Ottovon-Guericke Universität Magdeburg bearbeitet. Da die vollständige Integration der GPSPositionsbestimmung den Rahmen dieser Veranstaltung gesprengt hätte und der positive Abschluss eines Softwarepraktikums ein lauffähiges System voraussetzt, wurde das in
Abschnitt 2 vorgestellte Ersatzszenario implementiert. Die hierbei verwendeten Konzepte
lassen sich aber - bei vorhandener Hardware - mit etwas zusätzlichem Aufwand in den
GSM-Schutzengel integrieren.
2 Gesamtarchitektur
Grob gesagt, war das Ziel des Projektes die Ortung von mobilen Geräten durch mobile
Geräte. Bei dem zu ortenden Gerät handelt es sich um ein GPS-fähiges Endgerät, welches
über eine Internet-Anbindung verfügt. Es ermittelt permanent seine Position und aktualisiert sie in einer zentralen Datenbank. Für die Abfrage dieser Position aus der Datenbank existieren eine Standard-Desktopanwendung und eine Applikation für Java-fähige
Handys. Beide Applikationen ermöglichen die Darstellung der Position des zu ortenden
mobilen Gerä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 möglich ist, können auch Informationen zur aktuellen Bewegungsrichtung und Geschwindigkeit angezeigt werden. Um den
Missbrauch der verfügbaren Daten zu verhindern, enthält das System auch Mechanismen
zur Rechtevergabe. Auf diese Weise kann festgelegt werden, welcher Nutzer welche mobilen Gerä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 Funktionalitä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 Gerätes an den Positionsserver.
Die Übermittlung geschieht über TCP/IP, was beliebige Anwendungsprotokolle ermöglicht.
Ideal ist eine paketbasierte Technik wie GPRS. Um die übertragene Datenmenge möglichst
gering zu halten, kann man die Übermittlung in frei deﬁnierbaren Zeitintervallen erfolgen lassen sowie Mindestpositionsveränderungen deﬁnieren. Der Positionsserver trägt alle ü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 für beliebige Nutzer vom Server abfragen. Das zur Anzeige der Position benötigte Kartenmaterial wird vom Kartendienst Map24 [NET03] geladen. Dieser ermöglicht das Anfragen beliebiger Kartenausschnitte innerhalb von Europa ü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 Gerät mit GPS-Funktionalität zur Verfügung stand, wurde für die Positionsermittlung auf einen Laptop mit angeschlossenem externem GPS-Controller zurückgegriffen.
2.2 Anforderungen an die Endgeräte
Das ortende mobile Endgerät muss Java nach der Connected-Limited-Device-Conﬁguration-Speziﬁkation (CLDC) [Sun03] unterstützen und eine Internet-Verbindung aufbauen
können. Für das ortende nicht-mobile Endgerät gelten die gleichen Voraussetzungen. Jedoch wird hier anstatt der eingeschränkten J2ME (Java 2 Micro Edition) die Java Virtual
Machine 1.4 oder höher benötigt, welche einen stark erweiterten Funktionsumfang liefert.
An das zu ortende mobile Endgerät werden die folgenden Anforderungen gestellt:
Möglichst permanente Anbindung an das Internet: Damit die Positionen des Nutzers
die notwendige Aussagekraft besitzen, müssen sie in möglichst kurzen Abständen
an den Server übermittelt werden. Hierfür ist eine dauerhafte Internet-Anbindung
des Endgerätes, beispielsweise über GPRS, sinnvoll. Bei GPRS wird nicht nach
Zeit sondern nach übertragendem Volumen abgerechnet. Da die Positionsdaten nur
wenig Übertragungskapazität benötigen, sind die anfallenden Kosten relativ gering.
Integration von GPS im Endgerät: Damit das Gerät seine Position ermitteln kann, muss
ein GPS-Empfänger integriert sein bzw. Zugriff auf ein externes GPS-Gerät bestehen.
Fähigkeit zum Ausführen von Java: Die Übermittlung der Position an den Server erfolgt über ein Java-Programm. Damit das Gerät dadurch nicht blockiert wird, muss
es multitasking-fähig sein.
Derzeit erfüllen nur wenige Geräte diese Anforderungen. Es existieren zwar GPS-fähige
PDAs, diese benötigten jedoch zusätzlich ein Mobiltelefon, um eine Verbindung zum Internet herzustellen. Andererseits gibt es von Benefon1 oder Garmin2 Mobiltelefone mit
integriertem GPS-Empfänger. Diese Geräte sind aber nicht java-fähig. Es ist jedoch zu
erwarten, dass diese Anforderungen bald von einer zunehmenden Anzahl von Geräten
erfüllt werden. So bietet Global Locate bereits heute einen extrem kleinen und stromsparenden GPS-Chipsatz3 an, der in Mobiltelefone integriert werden könnten. Tatsächlich
stellte Invair Technologies auf der CeBIT 2003 ein Smartphone 4 vor, das alle Anforderungen erfüllt. Leider war es uns noch nicht möglich ein derartiges Gerät zu testen.
3 Vom Server bereitgestellte Funktionalitä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 gewährleistet die
Konsistenz dieser Daten. So ist beispielsweise eine Umrechnung der Positionsdaten notwendig, da der positionssendende Benutzer die Daten des GPS-Gerätes in einem anderen
Format ausliest als sie später für das Kartenmaterial benötigt werden. Aufgrund der Beschränkungen der J2ME ist eine Umrechnung direkt nach dem Auslesen auf dem mobilen
Endgerät nicht sinnvoll möglich.
Daneben ist es mangels Serializable-Implementation seitens der J2ME nicht möglich ein
GPS-DataPiece5 als Objekt zu übertragen. Daher werden die GPS-DataPieces bzw. Positionsdaten vom Client in einen String konvertiert, welcher über eine Socket-Verbindung
an den Server geschickt wird. Dieser trägt die Daten nach erfolgreicher Benutzeridentiﬁkation in die Datenbank ein. Die Stringgenerierung fü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 zurück. Damit der Server prüfen kann ob die Berechtigung zur Lokalisierung vorliegt, müssen die eigenen Nutzerdaten mit ü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 Einfügen von GPS-DataPieces fü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 unverschlüsselt. Für den Einsatz in
einem Produktivsystem ist eine Verschlüsselung insbesondere der personen- und positionsbezogenen Daten zwingend gefordert. Je nach verwendeter Java Virtual Machine kann
es diesbezüglich aber auf den mobilen Geräten zu Problemen kommen. Serverseitig ist
eine Verschlüsselung der übertragenen Daten hingegen problemlos möglich.
3.1 Datenbank
Der Zugriff auf die Datenbank erfolgt ausschließlich über den Server (vgl. Abbildung 2).
Zum einen ist es systembedingt (Verwendung von J2ME ohne plattformabhängige Erweiterungen) technisch nicht möglich, direkt von einem mobilen Gerät auf Datenbanken zuzugreifen. Andererseits ist ein direkter clientseitiger Zugriff aus Gründen der Datenﬂussund Zugriffskontrolle nicht sinnvoll.
Der Server greift ü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 ü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 spä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 gehörende Benutzername, der Kurs und zudem der Zeitpunkt, zu welchem die Daten in die Datenbank eingefügt wurden. Letzteres kann genutzt werden, um Zeitunterschiede zwischen
Auslesen der Daten aus dem GPS-Gerät und dem Einfügen in die Datenbank festzustellen.
Als Primärschlü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 sämtliche Nutzerdaten gespeichert,
wie Benutzername, Vor- und Nachname, Anschrift und natürlich die Mobilfunknummer.
Eine letzte Tabelle enthä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 dürfen. Damit nur berechtigte Benutzer Positionen abfragen oder eintragen können, werden bei jedem Kommunikationsvorgang zwischen Client
und Server der eigene Benutzername und das Passwort übermittelt. Der Server überprü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 aufwändiges Sessionmanagement, welches im
Mobilfunkbereich durch häuﬁg wechselnde IP-Adressen zusätzlich verkompliziert würde.
4 Client-Applikationen
Wie eingangs erwähnt wurde, bestehen die Möglichkeiten, die Ortung von Nutzern mobiler Endgeräte entweder von einem Desktop-PC oder von einem anderen mobilen Endgerät
aus zu realisieren. Im Folgenden werden die beiden Client-Anwendungen vorgestellt.
4.1 Mobiltelefon-Client
Für die Umsetzung des Prototyps wurden exemplarisch Mobiltelefone als eine Klasse mobiler Endgeräte genutzt. Prinzipiell ist jedoch eine Portierung der Client-Anwendung auf
z.B. PDAs oder Smartphones ohne Probleme möglich, solange diese Geräte die in Abschnitt 2 vorgestellten Anforderungen ausreichend erfüllen.
Wahl der Programmiersprache: Eine wichtige Anforderung bei der Wahl der Programmiersprache für die auf dem Mobiltelefon laufende Software war die Kompatibilität.
Die Software für das Mobiltelefon sollte möglichst ohne größere Anpassungen auf allen
gängigen Mobiltelefonen sowie PDAs lauffähig sein. Daher kamen proprietäre Systeme
wie z.B. ExEn von In-Fusio6 für diese Entwicklung nicht in Frage. Nahezu alle neu auf
dem Markt erscheinenden Handys und PDAs verfügen jedoch inzwischen über eine eingebaute Java Virtual Machine“. Die Java-Speziﬁkation unterteilt sich in mehrere Varianten,
”
die unterschiedliche Zielgeräte abdecken. Neben dem sehr verbreiteten Standard (J2SE)
und der Enterprise Edition (J2EE) bietet Sun für kleine Gerä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 Proﬁle. Diese verwendet die Kilobyte Virtual Machine (KVM)
und begnügt sich mit nur 32 bis 512 kb Arbeitsspeicher. Dieses Mobile Information Device Proﬁle bietet unter anderem Netzwerkunterstützung nach dem HTTP 1.1 Standard, eine
graphische Benutzeroberﬂäche, die sich automatisch den Gegebenheiten des verwendeten
Gerätes anpasst sowie die Möglichkeit, Daten permanent zu speichern. Für die Kommunikation mit der GPS-Hardware sind die Java APIs für Bluetooth von Interesse. So wäre es
möglich, mit der GPS-Einheit zu kommunizieren wenn diese beispielsweise in dem Akku
des Mobiltelefons integriert wäre, was wiederum ein einfaches Nachrüsten der Technik
erlauben würde.
Die geringen Hardwareanforderungen des MIDP führen jedoch zu Einschränkungen, die
bei der Softwareentwicklung zu beachten sind. Da z.B. viele MIDP-unterstützende Geräte
über keinen Fließkomma-Prozessor verfügen, können keine Variablen vom Typ float
oder double verwendet werden.
Installation: Die Installation der Software kann auf zwei Arten geschehen. Entweder wird
das Gerä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
über eine normale HTML-Seite erfolgen kann. Zuerst wird nun nur eine .jad-Datei herunter geladen. Diese enthält unter anderem eine Beschreibung des Programms und die
Dateigröße der Software. Anschließend kann der Anwender entscheiden, ob er die komplette Software herunterladen möchte. Diese enthält dann die kompilierten Klassen in einer
komprimierten .jar-Datei.
Programmbedienung: Nach dem Starten der Software erscheint zuerst das Hauptmenü
(siehe Abbildung 3(a)). Unter View Map kann die eigene Position oder auch die Position
(a) Hauptmenü
(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 über ein Farbdisplay verfügen, erfolgt die Kartendarstellung (vgl. Abbildung 3(c)) in Farbe. Auf Wunsch kann ein Fadenkreuz eingeblendet
werden, welches die exakte Position darstellt. Unter dem Menüpunkt View details wer-
den die Längen- und Breitengrade, der Zoomfaktor, die Breite des Kartenausschnitts, die
Höhe ü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 Positionsveränderung. Dadurch wird das übertragene Datenvolumen und somit die Kosten
der GPRS Datenübertragung reduziert. Der Menüpunkt Change User beinhaltet die Benutzerverwaltung. Wie schon in Kapitel 3.2 erwähnt, dient sie der Zugriffskontrolle und
der Benutzerauthentiﬁzierung. Der Menupunkt Change target ermöglicht - entsprechende Berechtigungen vorausgesetzt - das Anzeigen von Daten anderer Nutzer. Unter Server
data werden Einstellungen bezüglich des Servers (z.B. Adresse und Port) vorgenommen.
Dementsprechend, ermöglicht Map settings das Festlegen spezieller Parameter für den
Zugriff auf den Kartenserver. Der vorletzte Menüpunkt Mobile settings umfasst spezielle
Anpassung der Software an das verwendete Endgerät. Dazu gehören die Auﬂösung und
die Farbdarstellung. Normalerweise ist dies aber nicht notwendig, da die Software anhand
des Gerätes automatisch kalibriert wird. Der letzte Menüpunkt bietet eine umfangreiche
Hilfefunktion.
4.2 Desktop-Client
Da mobile Endgeräte oftmals beschränkte Darstellungsmöglichkeiten (Displaygröße) besitzen, können sie nicht alle Details der GPS-Daten sinnvoll gleichzeitig darstellen. Um
dieses Problem zu lösen wurde zusä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 Plattformunabhängigkeit gewahrt bleibt und der Client auf jedem
Computer, der über eine entsprechende Java Virtual Maschine“ verfügt, benutzt werden
”
kann. Die graphische Benutzeroberﬂäche ist in Swing realisiert, wodurch eine leichte und
weitgehend intuitive Bedienung möglich ist.
Funktionalität: Der Desktop-Client (siehe Abbildung 4) ermöglicht es, die Position von
mobilen Endgeräten auf einer Karte anzuzeigen. Für den Betrieb der Software ist eine
Anbindung an das Internet erforderlich, da sowohl die Positionsinformationen als auch
das Kartenmaterial hierüber bezogen werden. Der Zugriff auf die Positionsdaten erfolgt
über das in Kapitel 3 vorgestellte string-basierte Protokoll. Der Zugriff auf das Kartenmaterial ist über HTTP realisiert: Eine einfache, aus dem vom Positionsserver erhaltenen Längen- und Breitengrad zusammengesetzte URL genügt, um dynamisch den jeweils
benötigten Kartenausschnitt zu erhalten. Auf diese Anfrage wird dann die Karte im GIFFormat zurückgeliefert. Die Positionen der Nutzer werden dabei vom Kartenserver in das
Bild eingefügt, was stets eine optimale Lesbarkeit der Beschriftungen sicherstellt. Hierfür
müssen zuvor dem Server in einer gesonderten HTTP-Anfrage die jeweils aktuellen und
einzuzeichnenden Positionen der Nutzer mitgeteilt werden.
Nach dem Programmstart ist eine Authentiﬁzierung des Nutzers anhand des Nutzernamens
und des Kennworts notwendig. Nach erfolgreicher Prüfung der Daten durch den Positions-
(a) Detailstufe Region“
”
(b) Detailstufe Straße“
”
Abbildung 4: Desktop-Client
server wird die so genannte Buddylist“ übertragen und im Client angezeigt. Diese Liste
”
enthält alle Nutzer mobiler Endgeräte, die dem Anwender der Software ein Ortungsrecht
eingeräumt haben. Über die Buddylist“ erfolgt die Auswahl der Nutzer, die auf der Karte
”
eingezeichnet werden. Dabei ist es möglich, beliebig viele Nutzer gleichzeitig anzuzeigen. Der Zoomfaktor wird automatisch so gewählt, dass alle Nutzer im Kartenausschnitt
repräsentiert sind.
Zusätzlich zu der Position auf der Karte werden zu den ausgewählten Nutzern statistische
Daten in einem Kartenreiter angezeigt. Diese Statistik enthält zum einen Angaben über
die aktuelle geographische Position (Längen- und Breitengrad sowie die Höhe über Normal Null). Zum anderen werden auch Angaben über die aktuelle Geschwindigkeit, die
aktuelle Bewegungsrichtung und über den Zeitpunkt der letzten Messung angezeigt. Diese Angaben sind alle in Textform gegeben. Zur besseren Übersicht werden Richtung und
Geschwindigkeit noch durch eine Windrose dargestellt, bei der mit steigender Geschwindigkeit der Richtungszeiger wächst.
Das Zoomen der Karte ist über zwei verschiedene Methoden möglich. Zum einen kann
einfach stufenweise herein- oder herausgezoomt werden. Zum anderen ist es möglich, über
fünf vorgegebene Detailstufen (Straße, Stadt, Region, Land und Europa) auch bequem in
größeren Sprüngen zu zoomen.
Über ein Wiedergabe-Modul kann der Nutzer zudem sämtliche auf dem Positionsserver
gespeicherte Routen von früheren Zeitpunkten wiedergeben. Hierzu wird die Route vom
Server übertragen und in einer gewählten Geschwindigkeit abgespielt. Die Zuordnung der
Positionen zu einer Route wird ü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
wählen. Außerdem ist es möglich einen Standard-Nutzer anzulegen, damit die Anmeldung
beim Start des Programms vereinfacht wird.
5 Zusammenfassung und Ausblick
Die Ortung von mobilen Endgeräten ist eine zwingende Voraussetzung für die Realisierung lokationsbasierter Dienste. Im Rahmen des vorgestellten Projektes wurde ein System
entwickelt, das es ermöglicht, die Position eines mit GPS ausgestatteten mobilen Endgerä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 möglich. In dem Papier
wurde die Gesamtarchitekur präsentiert und einige Aspekte der Implementierung sowie
der Anwendung des Systems erläutert.
Bei dem vorgestellten System handelt es sich um einen Prototyp, der noch zahlreiche
Punkte für zukünftige Arbeiten offen lässt. Darunter sind u.a. (1) Skalierbarkeit des Servers bei einer großen Anzahl von Nutzern und (2) verschlüsselte Kommunikation zwischen
den beteiligten Komponenten. Neben den technischen Fragen, sind Anwendungen ein zentraler Punkt für Anschlussfragestellungen. Wie eingangs erwä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 Inﬁneon Technologies AG, der NETSOLUT GmbH sowie der SOS r. AG, welche die Entwicklung durch Geld und Sachmittel unterstü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 fü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.
Datenströme im Kontext des Verkehrsmanagements∗
Michael Cammert
Christoph Heinz
Jürgen Krämer
Bernhard Seeger
Fachbereich Mathematik und Informatik
Universitä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 Datenströme. Wir skizzieren typische Anforderungen an Datenverarbeitungssysteme und begründen, warum traditionelle Datenbankmanagementsysteme im Kontext von Datenströmen weniger geeignet sind. Vielmehr
motivieren wir den Einsatz von Datenstrommanagementsystemen, wobei wir einen
Überblick über allgemeine Problemstellungen und Ansätze bei der Verarbeitung von
Datenströmen geben. Neben prototpyischen Systemen präsentieren wir unser bibliotheksorientiertes Rahmenwerk, mit dem sich Anfragen über Datenströmen adäquat
formulieren und ausführen lassen. Im Ausblick erlä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 adäquate Steuerung des
Verkehrs. Dazu müssen Verkehrsdaten erfasst, übertragen, analysiert und verwaltet werden, was unter dem Begriff Verkehrsmanagement zusammengefasst wird. Die Daten können sowohl von stationären als auch von mobilen Sensoren geliefert werden. Beispielsweise registrieren stationäre Sensoren an Autobahnbrücken den aktuellen Verkehrsfluss,
während mobile Sensoren fahrzeugspezifische Informationen, wie etwa die exakte Position eines Fahrzeugs, übermitteln.
Die initialen Ziele des Verkehrsmanagements liegen in einer effizienteren Ausnutzung der
bestehenden Kapazität des Straßennetzes und einer Verlagerung der Verkehrsbelastung,
um dem wachsenden Verkehrsaufkommen entgegenzukommen. Geeignete Verkehrsmanagementsysteme könnten dazu eine Vielzahl von Daten berücksichtigen, z. B. Routenplä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
gefördert.
nagements [Pr99] prognostiziert für das Jahr 2010 eine Steigerung der Streckenkapazitä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 erhöhen und im Gegenzug bei wenig befahrenen Streckenabschnitten senken.
Die erfassten Sensordaten werden im Allgemeinen in einem Datenbanksystem verwaltet,
wodurch sämtliche Updates persistent gespeichert werden. Hieraus resultieren enorme Datenbestände, von denen meist nur ein Bruchteil für aktuelle Analysen herangezogen wird,
da eine vollständige Auswertung der archivierten Daten zu aufwändig wäre. Das stellt
den Einsatz von Datenbanksystemen zur Verwaltung von Sensordaten generell in Frage.
Seit zirka zwei Jahren beschäftigen sich daher einige Forschergruppen mit dem Entwurf
von Datenstrommanagementsystemen, die sich speziell für die Analyse und Verarbeitung
von Daten eignen, die autonomen Datenquellen entspringen. In diesem Artikel geben wir
zunächst einen Überblick über die in diesem Themengebiet grundsätzlich auftretenden
Problemstellungen und Ansätze. Danach präsentieren wir PIPES (Public Infrastructure
for Processing and Exploring Streams), unser Rahmenwerk zur Verarbeitung von Datenströ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 Datenströmen vor.
Abschließend fassen wir die vorgestellten Konzepte zusammen und geben einen Ausblick
auf mögliche Anwendungsszenarien.
2
Datenströ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 wäre. In Abbildung 1 werden die beiden Konzepte gegenübergestellt.
2.1
Anforderungen
Zunächst möchten wir zentrale Anforderungen bei der Datenverarbeitung im Kontext des
Verkehrsmanagements herausarbeiten. Da permanent verschiedenste Sensordaten erfasst
werden, ergeben sich potentiell unendliche Datenströme. Für eine dynamische Steuerung
des Verkehrsflusses mü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, adäquat zu
integrieren und nach Ablauf wieder zu entfernen. Bei hoher Verkehrsdichte trifft folglich eine größere Zahl von zum Teil ähnlichen Anfragen auf eine stark erhöhte Menge
von Sensordaten. Allerdings existieren auch Phasen geringerer Verkehrslast. Ein geeignetes System muss hinsichtlich dieser Lastä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 Möglichkeit zur Reduktion der Updaterate besteht in der dezentralen Ausführung von
Anfragen, falls die Sensoren über genügend Rechenkapazität verfügen [BGS01, CBB+ 03].
Neben der Quantität der Daten spielen ebenso deren Qualität und Verfügbarkeit eine Rolle. So muss ein System auch bei Ausfall oder Fehlfunktion von Sensoren sowie einer
Unterbrechung bzw. Überlastung des Kommunikationsnetzwerks weiterhin funktionieren. Eine zusätzliche Anforderung besteht in der effektiven Unterstützung von orts- und
zeitabhängigen Anfragen. Darüber hinaus müssen sämtliche Anfragen nahezu in Echtzeit bedient werden, was eine komplette Zwischenspeicherung der Daten für eine spätere
Verarbeitung ausschließt. Vielmehr sollten diese direkt bei ihrer Ankunft vom System verarbeitet werden. Wenn die exakte Auswertung der Anfrage aus Komplexitäts- oder Performanzgründen nicht mö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, könnte die Auswertung ähnlicher Anfragen unterstützen.
Diese vielseitigen Anforderungen an ein System zur Datenstromverarbeitung im Kontext
des Verkehrsmanagements verdeutlichen, dass die Faktoren Adaptivität, Flexibilität, Skalierbarkeit sowie die Unterstü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 über den in seiner Datenbank persistent abgespeicherten Daten. Die Elemente eines zu verwaltenden Datenstroms müssen
daher zunächst in diese Datenbank eingefügt werden. Anfragen werden somit bezüglich
des Datenbestands zu einem festen Zeitpunkt einmalig beantwortet. Dadurch basieren aktuelle Resultate auf fortwährenden Wiederholungen derselben Anfrage. Dies kann sich,
ebenso wie das explizite Einfügen eines neu eintreffenden Datenstromelements, als sehr
aufwändig erweisen. [TGNO92]
Manche Komponenten eines DBMS sind nur sehr bedingt nützlich, wie beispielsweise
das Transaktionsmanagement. Fehlende Funktionalität, die in Fremdsystemen bereitgestellt wird, ist dagegen schwierig an ein bestehendes DBMS anzubinden. Darü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 zusätzlich die Multi-Anfragen-Optimierung, da sich die zu optimierende Anfragemenge fortlaufend ändert.
In Kombination mit obigen Anforderungen erweisen sich DBMS insbesondere hinsichtlich
der Adaptivität als weniger geeignet für die Datenverarbeitung im Rahmen des Verkehrsmanagements.
2.3
Datenstrommanagementsysteme
Bezüglich der Charakteristika von Datenströ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 Datenströmen sowie deren Übertragungsgeschwindigkeit wird
nicht durch die verarbeitenden Algorithmen, sondern primär durch die aktiven Datenquellen selbst bestimmt.
3. Die Datenströme sind in ihrer Größe potentiell unbeschränkt.
4. Jedes Element eines Datenstroms wird nur einmal vom Strom geliefert.
5. Änderungsoperationen auf Elementen eines Datenstroms sind nicht möglich. Neue
Elemente können nur am Ende eines Datenstroms angehängt werden (append-only).
Die im Rahmen des Verkehrsmanagements verarbeiteten Daten weisen diese Eigenschaften auf. Stationä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 ü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 möglich, wenn diese zuvor archiviert wurden.
Eine komplette Zwischenspeicherung und anschließende Auswertung der Datenströme ist
ausgeschlossen, da diese einerseits in ihrer Größe nicht begrenzt und andererseits beim
Verkehrsmanagement regelmäßig und möglichst frühzeitig Resultate erforderlich sind. Die
Exploration der daraus resultierenden riesigen Datenarchive würde eine teure Aufgabe für
ein Datenbanksystem darstellen. Daher sollte eine Online-Analyse der Datenströme direkt
bei deren Ankunft erfolgen und, wenn überhaupt, nur ein Bruchteil der Daten zwischengespeichert werden, falls diese für kü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 Datenströme und deren fluktuierende Datenraten
müssen solche Systeme zusätzlich in einem hohen Maße adaptiv sein. Diese Adaptivität
in Verbindung mit limitierten Ressourcen ermö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
erhöhte Staugefahr vermuten, so ist eine schnelle Benachrichtigung der betroffenen Verkehrsteilnehmer sicherzustellen, während die Bestimmung der exakten Zahl der erfassten
Fahrzeuge weniger von Belang ist.
Während Anfragen in DBMS vor ihrer Ausführung statisch optimiert werden, ergeben sich
im Kontext von DSMS neue Herausforderungen. Zur Steigerung der Performanz werden
mehrere Anfragen gebündelt, so dass gemeinsame Teilanfragen nur einmal ausgewertet
werden. Dabei muss auch das dynamische Einfügen und Löschen von Anfragen unterstützt
werden. Zudem ist eine dynamische Laufzeitoptimierung dieser lange laufenden Anfragen
notwendig.
Die für ein Verkehrsmanagement relevanten Daten liegen sowohl persistent als auch in
Form eines Datenstroms vor. Straßenkarten sind beispielsweise in Datenbanken abgelegt,
während die von mobilen oder stationären Sensoren gelieferten Informationen kontinuierlich gesendet werden. Tabelle 1 zeigt zusammenfassend die in diesem Abschnitt dargelegten Unterschiede zwischen herkömmlichen DBMS und DSMS.
2.4
Anfrageverarbeitung auf Datenströmen
Im Weiteren diskutieren wir gegenwärtige Konzepte und allgemeine Problemstellungen
bei der Verarbeitung von Datenströmen.
Datenbankmanagementsystem
(DBMS)
• Passive Datenquellen
• Persistente Daten (Relationen)
• Externspeichernutzung
• Wahlfreier Zugriff
• historische Anfragen
• Exakte Antworten
• Statische Optimierung
Datenstrommanagementsystem
(DSMS)
• Aktive Datenquellen
• Flüchtige Daten (Datenströ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 übersetzt, der im Wesentlichen aus Operatoren einer geeigneten Algebra besteht. Man könnte SQL um Funktionalität zur Verarbeitung von Datenströmen erweitern, wobei jedoch bestehende Funktionalität eventuell nicht
mehr benötigt wird. Einfüge- und Änderungsoperationen auf Datenströmen werden obsolet, wohingegen sich approximative Anfragen bislang nicht spezifizieren lassen. Sinnvoll
wäre folglich die Konzeption neuer Anfragesprachen oder die direkte Formulierung von
Anfragen mittels einer GUI. Zentrales Problem [BBD+ 02] beider Ansätze ist die Definition einer geeigneten Algebra, die als Grundlage für die Verarbeitung von Datenströmen
dient.
Neben der logischen Algebra, in der primär die Semantik der Operatoren festgelegt wird,
gibt es eine physische Algebra, die i. A. verschiedene Implementierungen der Operatoren
enthält. Durch die direkte Verarbeitung der Elemente eines Datenstroms ist die klassische bedarfsgesteuerte Verarbeitung mittels Iteratoren (ONC) nach [Gr93] nicht möglich.
Aufgrund potentiell unbeschränkter Datenströme dürfen keine blockierenden physischen
Operatoren eingesetzt werden. Darunter versteht man Operatoren, die ihre gesamte Eingabe konsumieren mü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 lässt sich allerdings durch
die Verwendung von über einen Datenstrom gleitenden Fenstern, inkrementeller Auswertung oder a priori bekannten Eigenschaften eines Datenstroms lösen. Zum Beispiel wäre
es für eine aktuelle Stauprognose ausreichend, die Sensordaten der letzten Stunden zu betrachten.
2.4.2
Indexierung
Mit Indizes lassen sich Anfragen effektiv unterstützen. Typische Anfragen beim Verkehrsmanagement sind sowohl orts- als auch zeitgebunden. Eine auf Indexstrukturen mit Zeitfenstern basierende Anfrage wäre etwa: ”Wie hoch war die mittlere Verkehrsdichte auf den
Autobahnen im Großraum München bezogen auf die vergangenen vier Stunden?” Deswegen bieten sich mehrdimensionale Indexstrukturen wie der MVB-Baum [BGO+ 96] an, die
effiziente Suchoperationen unterstützen. Neben persistenten Daten, wie etwa Karten- und
Baustelleninformationen, lassen sich auch mobile Sensoren mit Indexstrukturen verwalten. Für die Sensordaten benötigt man performante Einfüge-, Lösch- und Änderungsoperationen, wobei insbesondere mengenbasierte Operatoren von Vorteil für die Performanz
wären. Ebenso müssen gleitende Fenster adäquat unterstützt werden, was bei den bislang
existierenden Ansätzen jedoch nicht der Fall ist.
2.4.3
Optimierung
Eine zentrale Komponente eines DBMS ist der Anfrageoptimierer, der bei der Anfrageübersetzung deskriptiv formulierte Anfragen in einen möglichst optimalen Ausführungsplan transformiert. In DSMS werden bei der statischen Optimierung Anfragen in einem
Anfragegraphen unter Berücksichtigung übereinstimmender Teilanfragen zusammengefasst. Bei Anfragen auf Datenströmen benötigt man des Weiteren eine adaptive und dynamische Optimierung zur Laufzeit. Die Laufzeit einer kontinuierlichen Anfrage wiederum
wird primär durch den Benutzer bestimmt, der diese bei einem Anfragekoordinator anbzw. abmeldet. Bei Datenströmen geht man von einer Vielzahl von Anfragen mit oftmals
überlappenden Teilanfragen aus, wodurch eine Multi-Anfragen-Optimierung erforderlich
ist. So sind sicherlich mehrere Verkehrsteilnehmer an den aktuellen Stauinformationen
für die Autobahn A8 auf dem Streckenabschnitt von München nach Stuttgart interessiert,
während andere lediglich die Staus zwischen Augsburg und Ulm erfahren möchten.
Folglich müssen bei der Optimierung bereits ablaufende Anfragen ebenfalls berücksichtigt
werden. Die traditionellen, auf der Schätzung von Zwischenergebnissen basierenden Kostenmodelle eignen sich nicht für potentiell unbegrenzte Datenströ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 Performanzgründen schwierig
zu realisieren ist. Deswegen erscheinen partielle Umstrukturierungen sinnvoller. Bei einer
dynamischen Optimierung sind darüber hinaus weitere Faktoren zu berücksichtigen wie
etwa benutzerdefinierte Quality of Service (QoS) oder der Tradeoff zwischen Effizienz,
Genauigkeit und Speicherverbrauch bei der Ausführung einer Anfrage.
2.4.4
Ressourcenmanagement
Eine weitere Problemstellung bei der Verarbeitung von Datenströmen ergibt sich bei der
Zuteilung der begrenzten Systemressourcen CPU-Zeit, Haupt- und Externspeicher sowie Bandbreite. Zur Laufzeit müssen diese unter den gleichzeitig ablaufenden Anfragen
verteilt werden. Der Ressourcenbedarf einer Anfrage kann dabei aufgrund der potentiell unendlich großen Datenströme unbeschränkt sein, wie z.B. bei der Berechnung des
kartesischen Produktes. Da in einem DSMS immer limitierte Ressourcen potentiell unbeschränkten Ressourcenanforderungen gegenüberstehen, gestaltet sich die optimale Zuteilung der Ressourcen als äußerst schwierig. So lassen sich aufgrund des begrenzten Spei-
Abbildung 2: Anfrageverarbeitung im Rahmenwerk PIPES
chers häufig nur approximative Antworten zu einer gegebenen Anfrage bestimmen, über
die idealerweise Qualitätsaussagen getroffen werden können.
Die Zuteilung der Rechenzeit geschieht mittels eines Schedulers, der hinsichtlich vieler
gleichzeitig ablaufender Anfragen skalierbar ausgelegt sein muss. Weiterhin sollten dabei
Abhängigkeiten zwischen der Ausführung der Operatoren sowie benutzerdefinierte QoS,
wie z. B. Deadlines, berücksichtigt werden.
Die Mehr-Anfragen-Optimierung führt zur Einsparung von Ressourcen (resource sharing), weil gemeinsame Teilanfragen nur einmal ausgewertet werden. Ebenso könnte der
gemeinsame Zugriff auf Datenstrukturen, wie z. B. Puffer oder Indexstrukturen, die Speicherausnutzung verbessern. Bei der Zuteilung der verfügbaren Ressourcen versucht man
primär, die Genauigkeit und die Effizienz hinsichtlich der Anfragen zu optimieren. Hierbei spielen die Faktoren Adaptivität und Skalierbarkeit eine zentrale Rolle, da sowohl die
Anfragemenge als auch die Datenraten zur Laufzeit variieren. Darüber hinaus sollte die
Ressourcenverwaltung zusätzlich mit dem Optimierer gekoppelt sein.
3
Unser konkretes Rahmenwerk PIPES
In diesem Abschnitt stellen wir die Grundzüge unseres Rahmenwerks PIPES vor, mit dem
sich Anfragen auf Datenströmen formulieren und ausführen lassen. Eine ausführliche Darstellung von PIPES findet sich in [CHK+ 03].
3.1
Anfragegraph
PIPES erlaubt die Integration beliebiger heterogener Datenquellen, was Anfragen auf Datenströmen und persistenten Daten ermöglicht. Diese Anfragen werden in Anfragepläne
übersetzt, die in einem gerichteten Anfragegraphen zusammengefasst werden. Ein inhä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. Wä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 empfängt, diese verarbeitet und anschließend überträgt. PIPES verfügt daher über zwei zentrale Schnittstellen Source und
Sink. Diese werden von der Schnittstelle Pipe, die einen Operator modelliert, erweitert.
Sobald eine Quelle geöffnet ist, transferiert sie ihre Elemente an solche Senken, die über
spezielle Methoden namens subscribe bzw. unsubscribe bei dieser an- bzw. abgemeldet werden können. Werden die Daten einer Quelle nicht mehr benö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. Für Optimierungszwecke lassen sich zusätzlich die Datenraten
eines Knotens, d. h. die Anzahl der Elemente, die pro Sekunde in einem Datenstrom fließen, abfragen. Außerdem ist möglich, Anfragen temporär zu deaktivieren und später ohne
Neuübersetzung zu reaktivieren.
Initiale Quellen eines Anfragegraphen können in unserem Rahmenwerk zum Beispiel mobile Sensoren oder auch Datenbanksysteme sein, während terminale Senken konkrete Applikationen oder PDAs eines Endbenutzers repräsentieren können. Für deren leichte und
erweiterbare Anbindung verfügt PIPES über vorgefertigte Klassen, die gemeinsame Basisfunktionalitä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 enthält PIPES eine Vielzahl generischer Operatoren,
die auf beliebigen Objekten arbeiten und über Funktionen und Prädikate parametrisierbar
sind. Das Blockieren von Operatoren kann bislang mittels gleitender Fenster umgangen
werden. Zum Funktionsumfang von PIPES gehö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 übernimmt die Ablaufsteuerung im Anfragegraphen, indem er den einzelnen
Knoten CPU-Zeit zuweist. Dabei werden QoS-Aspekte nach benutzerdefinierten Vorgaben berücksichtigt. Ein prioritätsbasierter, adaptiver Speichermanager verwaltet die zur
Verfügung stehenden Haupt- und Externspeicherressourcen und erlaubt deren Umverteilung zur Laufzeit. Der Optimierer in PIPES beinhaltet eine statische und eine dynamische
Komponente. Während bei der statischen Optimierung neue Anfrageplä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 Zusatzfunktionalität implementiert werden.
4
Vergleichbare Projekte
Dieser Abschnitt gibt zunächst einen Überblick über verwandte Ansä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 Funktionalität von Triggern, und enthält erste Ansätze zur adaptiven Re-Optimierung.
NiagaraCQ [CDTW00] überwacht und filtert kontinuierlich über ein Wide-Area-Netzwerk
(WAN) verteilte, persistente XML-Datenbestände. Das System verfügt über eine Gruppierungsstrategie für Anfragen, die das inkrementelle Aufsetzen neuer Anfragen auf bestehende Materialisierungen unterstützt.
Das Aurora Projekt [CCC+ 02] befasst sich mit der Entwicklung eines Echtzeitsystems zur
Überwachung von Datenströmen. Zentraler Bestandteil sind QoS, für die Techniken wie
das Löschen von Elementen (load shedding) und speicheradaptives Operatorscheduling
eingesetzt werden. Aurora unterstützt resource sharing durch die Verwendung von speziellen Queues. Das Aufsetzen mehrerer Anfragen wird an speziellen Verbindungspunkten,
sog. connection points, ermöglicht. Diese erlauben es neu angemeldeten Operatoren, initial auf gepufferte historische Daten zurü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 kö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 Datenströ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 können. Allerdings sind diese nicht adaptiv. Eddies [AH00] sind spezielle, zentrale Operatoren, die
mit sämtlichen Operatoren eines Anfrageplans verbunden sind. Ein Eddy bestimmt dabei
adaptiv, in welcher Reihenfolge ein Element die Operatoren durchläuft. PSoup [CF02]
erweitert diesen Ansatz, indem Daten und Anfragen symmetrisch behandelt werden, wodurch zusätzlich historische Anfragen unterstützt werden.
5
Zusammenfassung und Ausblick
Die stetig wachsende Verkehrsbelastung erfordert leistungsfähige Verkehrsmanagementsysteme. Die fortlaufend anfallenden Daten werden durch stationäre und mobile Sensoren
geliefert und üblicherweise mittels traditioneller DBMS verarbeitet. Da diese Daten allerdings in Form von Datenströmen vorliegen, empfiehlt sich stattdessen der Einsatz eines
DSMS, dessen Vorzüge wir insbesondere im Hinblick auf Adaptivität herausgestellt haben. Neben generellen Problemstellungen und Lösungsansätzen der Datenstromverarbeitung haben wir unser Rahmenwerk PIPES präsentiert, das Anfragen sowohl über Datenströmen als auch persistenten Daten erlaubt. Dieses komponentenbasierte Rahmenwerk
ermöglicht einem Entwickler einerseits, komplexere Bausteine zu formieren, und andererseits, eigene Funktionalitä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 könnte man ein intelligentes Verkehrsmanagementsystem realisieren, das, ausgehend von Datenströmen stationärer und mobiler Sensoren, die aktuelle Verkehrsbelastung überwacht und steuernd eingreift. Dieser offene Ansatz ließe sich analog
auf Datenströme ü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., Krämer, J., Schä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., Ç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., Krä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., Krä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 fü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-Universität Magdeburg
[email protected]
Karsten Baumgarten
Friedrich-Schiller-Universität Jena
Institut für Informatik
D-07740 Jena
[email protected]
Jöran Beel
Otto-von-Guericke-Universität Magdeburg
[email protected]
Gert Brettlecker
Private Universität für Medizinische Informatik und Technik Tirol (UMIT)
Institut für Informationssysteme
A-6020 Innsbruck, Österreich
[email protected]
Prof. Dr. Martin Breunig
Forschungszentrum für Geoinformatik und Fernerkundung
Hochschule Vechta
Postfach 1553
D-49364 Vechta
[email protected]
Michael Cammert
Philipps-Universitä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 München
[email protected]
Arne Frenkel
Otto-von-Guericke-Universität Magdeburg
[email protected]
Christoph Gollmick
Friedrich-Schiller-Universität Jena
Institut für Informatik
D-07740 Jena
[email protected]
Dr. Torsten Grabs
ETH Zürich
Institut für Informationssysteme
ETH Zentrum
CH-8092 Zürich
[email protected]
Klaus Haller
ETH Zürich
Institut für Informationssysteme
ETH Zentrum, IFW C47.2
CH-8092 Zürich
[email protected]
Günter Hector
MAQSIMA GmbH
Am TÜV 1
D-66280 Sulzbach
[email protected]
Christoph Heinz
Philipps-Universität Marburg
Fachbereich Mathematik und Informatik
Hans Meerwein Straße
D-35032 Marburg
[email protected]
Hagen Höpfner
Otto-von-Guericke-Universität Magdeburg
Institut für Technische und Betriebliche Informationsysteme
Universitätsplatz 2
D-39106 Magdeburg
[email protected]
Michael Klein
Universität Karlsruhe
Fakultät für Informatik
Institut für Programmstrukturen und Datenorganisation
Postfach 6980
D-76128 Karlsruhe
[email protected]
Dr. Birgitta König-Ries
Universität Karlsruhe
Fakultät für Informatik
Institut für Programmstrukturen und Datenorganisation
Postfach 6980
D-76128 Karlsruhe
[email protected]
Thomas Königsmann
Fraunhofer Institut für Software- und Systemtechnik
Emil-Figge-Str. 91
D-44227 Dortmund
[email protected]
Prof. Dr. Jung Sun Lie
FH Braunschweig/Wolfenbüttel
Salzdahlumer Str. 46/48
D-38302 Wolfenbüttel
[email protected]
Johannes Lülf
Otto-von-Guericke-Universität Magdeburg
[email protected]
Bela Mutschler
Universität Ulm
Abt. Datenbanken und Informationssysteme
Oberer Eselsberg
D-89069 Ulm
[email protected]
Prof. Dr. Hans-Jörg Schek
ETH Zürich
Institut für Informationssysteme
ETH Zentrum
CH-8092 Zürich
[email protected]
Prof. Dr. Heiko Schuldt
Private Universität für Medizinische Informatik und Technik Tirol (UMIT)
Abteilung Information and Software Engineering
A-6020 Innsbruck, Österreich
[email protected]
Prof. Dr. Günther Specht
Universität Ulm
Abt. Datenbanken und Informationssysteme
Oberer Eselsberg
D-89069 Ulm
[email protected]
Dr. Can Türker
ETH Zürich
Institut für Informationssysteme
ETH Zentrum, IFW C47.2
CH-8092 Zürich
[email protected]
Christian Weigand
Fraunhofer-Institut für Integrierte
Schaltungen IIS Abteilung Bildverarbeitung / Medizintechnik
Am Wolfsmantel 33
D-91058 Erlangen
[email protected]
Peter Wilhelm
MAQSIMA GmbH
Am TÜV 1
D-66280 Sulzbach
[email protected]
Andre Zeitz
Universitä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

Mobilität und Informationssysteme - ETH E-Collection

Dieses Dokument Sammlung (en)

Dieses Dokument gespeichert

Schlagen Sie uns vor, wie wir StudyLib verbessern können