Birgitta König-Ries, Michael Klein, Philipp Obreiter (Hrsg.)

Persistence, Scalability, Transactions Database Mechanisms for Mobile Applications

Workshop by the GI-Arbeitskreis „Mobile Datenbanken und Informationssysteme“ April, 10 - 11th, 2003 in Karlsruhe, Germany

Gesellschaft für Informatik 2003

Lecture Notes in Informatics (LNI) - Proceedings Series of the Gesellschaft für Informatik (GI) Volume P-43 ISBN 3-88579-372-5 ISSN 1617-5468 Volume Editors Dr. Birgitta König-Ries Institute for Program Structures and Data Organization Universität Karlsruhe, Germany Email: [email protected] Michael Klein Institute for Program Structures and Data Organization Universität Karlsruhe, Germany Email: [email protected] Philipp Obreiter Institute for Program Structures and Data Organization Universität Karlsruhe, Germany Email: [email protected]

Series Editorial Board Heinrich C. Mayr, Universität Klagenfurt, Austria (Chairman, [email protected]) Jörg Becker, Universität Münster, Germany Ulrich Furbach, Universität Koblenz, Germany Axel Lehmann, Universität der Bundeswehr München, Germany Peter Liggesmeyer, Universität Potsdam, Germany Ernst W. Mayr, Technische Universität München, Germany Heinrich Müller, Universität Dortmund, Germany Heinrich Reinermann, Hochschule für Verwaltungswissenschaften Speyer, Germany Karl-Heinz Rödiger, Universität Bremen, Germany Sigrid Schubert, Universität Dortmund, Germany Dissertations Dorothea Wagner, Universität Konstanz, Germany Seminars Reinhard Wilhelm, Universität des Saarlandes, Germany © Gesellschaft für Informatik, Bonn 2003 printed by Köllen Druck+Verlag GmbH, Bonn

Preface “Persistence, Scalability, Transactions – Database Mechanisms for Mobile Applications“ has been the fourth workshop organized by the GI working group on mobile databases and information systems (GI Arbeitskreis “Mobile Datenbanken und Informationssysteme”). Our program included two invited talks from industry and ten research papers. These have been carefully chosen from the submissions by the program committee. We are very pleased that we have been able to put together a program that covers the area from a wide variety of angles, offering new insights and stimuli. We are also very pleased by the large interest in the topic which is reflected by the number of submissions and participants from outside the original working group. What you hold in your hands now are the post proceedings of the workshop, containing extended versions of the papers that where presented at the workshop. These papers went through another round of reviewing and improvement. This workshop would not have been possible without the efforts of many people and the support of several organizations. In particular, I would like to thank all the members of the program committee as well as my colleagues, Michael Klein and Philipp Obreiter and Gabriele Bütner, FZI, who helped with the local organization. We are also very thankful to the Gesellschaft für Informatik for its financial support, which makes it possible to publish these post-proceedings in the LNI series, and to the FZI (Forschungszentrum Informatik) and its board of directors, who graciously agreed to host the workshop.

I sincerely hope that you enjoy reading this volume and that it will provide you with new ideas and insights into this exciting research area. On behalf of the organizing committee,

Birgitta König-Ries

Organisation Programme committee 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) Can Türker (ETH Zürich)

Additional Referee Klaus Haller (ETH Zürich)

Local Organizers Michael Klein Birgitta König-Ries Philipp Obreiter

Contents

Invited Talks López-Aladros, Alcatel SEL Restrukturierung der TK-Netze zur Reduzierung der Komplexität

7

Stumpf, IBM Mobile Datenbanksysteme von IBM: Aktuelle Informationen jederzeit überall im Zugriff

8

Applications Zipf, Leiner Anforderungen an mobile Geo-Datenbanken für Katastropheninformationsund –warnsysteme

9

König-Ries, Klein Hunting for Mobile Information - A Report on the Lab Course “Mobile Databases”?

18

Technologies Niess, Flor, Vögler Generischer Zugriff auf Lotus Notes Datenbanken mit mobilen Endgeräten unter Verwendung von Portaltechnologien

30

Apel, Plack Überblick und Vergleich von Technologien als Grundlage einer Middleware für mobile Informationssysteme

40

Haller, Schuldt, Türker Flexible Fehlerbehandlung für mobile Ad-hoc-Prozesse

55

5

Nagi, König-Ries Asynchronous Service Discovery in Mobile Ad-hoc Networks

69

Replication Gollmick, Rabinovitch Fragmentbildung zur Unterstützung der nutzerdefinierten Replikation

79

Queries Ulusoy, Yoncaci, Lam Evaluation of a Criticality-Based Method for Generating Location Updates

94

Höpfner, Sattler Cache-supported Processing of Queries in Mobile DBS

106

Böttcher, Türling Checking XPath Expressions for Synchronization, Access Control and Reuse of Query Results on Mobile Clients

122

6

Restrukturierung der TK-Netze zur Reduzierung der Komplexit¨at F.J. Banet, R. Lopez-Aladros, S. Rupp Alcatel SEL

Abstract: Mit GPRS, den Location Based Services und schliesslich auch mit UMTS nimmt die Komplexit¨at der TK-Netze stark zu. Die Aufw¨ande, solche Netze zu planen, zu administrieren und neue Dienste einzubringen, steigen dramatisch. Mit der Konsolidierung der Datenbanken im Netz kann ein erster Schritt getan werden, den Trend umzukehren und die Netze wieder zu vereinfachen. Dar¨uber hinaus muss u¨ berlegt werden, ob nicht auch bei der Architektur der Netze grundlegend neue Prinzipien angedacht werden m¨ussen, um der zunehmenden Vielfalt der Protokolle entgegenzuwirken.

7

Mobile Datenbanksysteme von IBM: Aktuelle ¨ Informationen jederzeit uberall im Zugriff Joachim Stumpf IBM Data Management Technical Consultant, IBM

Abstract: Die Dynamik des Marktes verlangt nach aktuellen Informationen zu jeder Zeit. Immer mehr Menschen arbeiten mobil. Aktuelle Informationen vor Ort erm¨oglichen ihnen fundierte, schnelle Entscheidungen. Einsatzpl¨ane f¨ur mobile Servicemitarbeiter – vor Ort automatisch aktualisiert – erh¨ohen die Produktivit¨at der Mitarbeiter und verringern R¨uckfragen. Eine Bestellung eines Kunden, die bereits vor Ort in einer Form erstellt werden kann, die R¨uckfragen minimiert, reduziert die Lieferzeit und erh¨oht somit die Kundenzufriedenheit. Dies sind alles Argumente f¨ur mobile L¨osungen. Damit diese L¨osungen auch offline funktionieren, m¨ussen die Daten auch lokal verf¨ugbar sein. IBM DB2 bietet hier mit DB2 Everyplace f¨ur Palm, WinCE, Win32, Linux oder Symbian Unterst¨utzung f¨ur eine breite Plattformpalette. ¨ In diesem Vortrag bekommen Sie einen Uberblick u¨ ber mobile L¨osungen mit DB2 mit dem Schwerpunkt DB2 Everyplace. Dabei werden beispielhaft bereits bestehende L¨osungen skizziert. Danach werden die Basisfunktionalit¨aten der mobilen Datenbank, die Datentypen und die Architektur der Gesamtl¨osung DB2 Everyplace Enterprise edition erkl¨art. In einem weiteren Teil werden Themen und L¨osungsans¨atze angesprochen, die w¨ahrend eines Projektes abgehandelt werden m¨ussen. Dies betrifft Themen wie Connectivity, Verf¨ugbarkeit, Skalierung, Konflikte und Datenverteilung mit entsprechender Filterung.

8

Anforderungen an mobile Geo-Datenbanken für Katastropheninformations- und –warnsysteme Alexander Zipf1 und Richard Leiner2 1

2

FB Geoinformatik und Vermessung Fachhochschule Mainz Holzstrasse 36 55116 Mainz [email protected]

European Media Laboratory - EML Schloss-Wolfsbrunnenweg 33 69118 Heidelberg [email protected]

Abstract: Die jüngsten Hochwasserkatastrophen verdeutlichten, dass heutige Katastropheninformations- und -warnsysteme nur bedingt den Anforderungen an die Technik genügen und das Potential moderner mobiler Informationssysteme nicht voll ausgeschöpft wird. Der vorliegende Beitrag untersucht welche Anforderungen an mobile Katastropheninformations- und -warnsysteme insbesondere bezüglich mobiler Datenbanken zu stellen sind. Besondere Bedeutung kommt hierbei mobilen Geodatenbanken zu, da Umweltkatastrophen per se einen raumzeitlichen Bezug – wie eine sich verändernde Ausdehnung – aufweisen. So müssen Aktualisierungen auch des räumlichen Ausmaßes der Katastrophe vor Ort eingepflegt werden können und rasch allen Betroffenen zur Verfügung stehen. Es werden Szenarien mobiler Katastropheninformations- und –warnsysteme vorgestellt und die für Datenbanken daraus ableitbaren Anforderungen skizziert.

1. Mobile Katastropheninformationssysteme Die Ereignisse an der Elbe zeigen, dass im Katastrophenfall eine leistungsfähige, dezentrale Kommunikationsplattform zum Informationsaustausch zwischen Krisenstäben, Einsatzkräften, Behörden und Bevölkerung nötig ist. Hochwasservorhersagemodelle sind nutzlos, wenn ihre Prognosen die betroffene Bevölkerung nicht rechtzeitig erreichen oder nicht richtig verstanden werden. Zwar existieren bereits Vorhersagemodelle zur Hochwasserdynamik [MA02], doch ein Großteil dieser Informationen ist für die eigentliche Zielgruppe nicht zugänglich. Beispielsweise ist die Vorhersage des in 24 Stunden an einem amtlichen Pegel zu erwartenden Wasserstandes für den Normalbürger wertlos, wenn sie nicht mit einer räumlichen Information verbunden ist (z.B. einer Karte der zu erwartenden Überschwemmungen)[LE03]. Diese Überlegungen ergeben sich aus aktuellen Arbeiten an der Konzeption eines mobilen Katastropheninformationssystems. Bereits existierende Vorhersagemodelle sollen integriert und die errechneten Überschwemmungsflächenvorhersagen den betroffenen Bürgern, zuständigen Behörden und Krisenstäben vor Ort rasch zur Verfügung gestellt werden. Bisher werden im Katastrophenschutz allerdings v.a. Desktop-GIS (GIS = Geographisches Informationssystem, Software zur Aufnahme, Verwaltung, Analyse und Visualisierung raumbezogener (geographischer) Daten) eingesetzt [NO00]. GIS bieten ein großes Potential im weiteren Bereich Katastrophenvorhersage und -management, wie bei Erdbeben etc. [KI03], da sie Informationen über ihre räumliche Position als Schlüssel integrieren, verwalten und analysie-

9

ren können. Auch im Hochwasserschutz werden sie zunehmend eingesetzt [AS03], jedoch wurden mobile Einsatzmöglichkeiten dabei kaum berücksichtigt. Als raumbezogenen Daten spielen sowohl vektorbasierte Geometriedatenmodelle, als auch digitale Geländemodelle (z.B. als TIN (Triangular irregular Network / unregelmäßige Dreiecksvermaschung) oder rasterbasierte Fernerkundungsdaten eine wesentliche Rolle [PE03]. Die zu verbreitenden Informationen umfassen Prävention (z.B. Gefahrenpotenzialkarten), aktuelle Vorhersagen (z.B. Überschwemmungsflächenvorhersage, Vorhersage von Wasserstandstiefen) und individuelle Warnungen (z.B. SMS). Insbesondere betreffen sie aber das Krisenmanagement während des Notfalls selbst (z.B. Aktualisierung und Übermittlung aktueller Lagebeschreibungen etc., vgl. Abbildung 1). Wesentliche Einsatzszenarien werden im Folgenden skizziert und daraus Anforderungen an mobile Geodatenbanken für den Einsatz im Katastrophenfall abgeleitet. Schwerpunkt des Beitrags bildet die Analyse spezieller Anforderungen (raumzeitlicher) Geodaten für mobile Datenbanken im skizzierten Szenario als Übersicht über relevante Aspekte bei der Konzeption eines solchen Systems. Die verschiedenen Hochwasser-Prognosesysteme sind oft als Einzellösungen entwickelt worden und die Entscheidung Integration (wie?) oder gar Neuimplementierung muss für jede System individuell geklärt werden.

2. Anwendungsszenarien Prävention –Aufklärung über Risikopotentiale Durch die Verbreitung von Hochwasserinformationen (z.B. Überflutungs-, Druckwasser- und Gefahrenpotentialkarten) soll die Aufklärung über die Überschwemmungsrisiken der verschiedenen Gewässersysteme verbessert werden. Die Risiken am Standort werden so für den Bürger klar erkennbar. Auf dieser Informationsgrundlage kann eine Minderung des Schadenspotenzials erzielt werden, indem z.B. Stromverteilerkästen nicht im Keller, sondern in oberen Stockwerken installieren werden, etc. Wichtig ist dabei, dass die digitalen Gefahrenpotenzialkarten in ihrer Darstellung intuitiv interpretierbar sind, räumlich genau vorliegen (min. 1:5000) und jederzeit abgerufen werden können. Vorhersage – Ortsunabhängige und zeitnahe Warnung bei akuter Gefahr Hochwasserinformationssysteme sollen die aktuellen, für Hochwasserwarnungen relevanten Umweltdaten (z.B. Wasserstände, Wettervorhersage, Schneeschmelze,...) zusammenfassen. Bestehende Vorhersagemodelle (z.B. Wasserstandvorhersagemodelle der Hochwasservorhersagezentralen) sind zu integrieren. Idealerweise werden sie um Vorhersagemodelle (z.B. Inundationsflächen mittels digitaler Geländemodelle) erweitert. Derart berechnete Vorhersagen werden dynamisch erzeugt (z.B. als WasserstandsvorhersageDiagramme, Überschwemmungsflächen- u. Wasserstandstiefenkarten) und über verschiedene Medien verbreitet. Im Ernstfall werden automatisch Warnungen versendet. Krisenmanagement – Informations- und Planungsplattform für Krisenstäbe, Rettungskräfte und Bürger Im Katastrophenfall können autorisierte Personen (bzgl. mobile Datensicherheit vgl. [HOF02]) über mobile Geräte Informationen nicht nur vor Ort empfangen, sondern auch eingeben (z.B. Lagebericht von gefährdeten Deichen, Aktivierung von Krisenplänen...). Aufgrund von Überschwemmungen gesperrte Straßen sollen

10

mit alternativen Routen angezeigt werden können. Hierzu müssen die Daten mobil vor Ort leicht in die Datenbasis einpflegbar sein.

Katastrophen-IS

Abbildung 1: Schematische Übersicht: Aufbau eines mobilen Katastropheninformationssystems

3. Datenbankrelevante Anforderungen an ein mobiles Katastrophenmanagementsystem Hauptziel ist die Entwicklung eines robusten, offenen und skalierbaren Systems. Zudem ist die Erweiterbarkeit für neue Datenquellen und Endgeräte zu gewährleisten. Hieraus ergeben sich für Architektur, Datenerfassung, -haltung und –analyse, sowie Benutzungsschnittstellen Anforderungen, die in den folgenden Abschnitten dargelegt werden. Bei der Entwicklung eines solchen Systems muss in der Regel auf eine Reihe heterogener existierender Systeme zurückgegriffen werden. Hierbei entstehende Integrationsprobleme werden in diesem Rahmen nicht behandelt. Wir konzentrieren uns auf die für mobile Datenbanken und Informationssysteme relevanten Aspekte. Dabei gelten für mobile Katastrophenwarnsysteme natürlich nicht grundlegend andere Anforderungen als bei anderen mobilen Informationssysteme. Bei den „speziellen“ Anforderungen ist besonders die Verwaltung raumbezogener Daten – in 2D oder 3D – möglichst inklusive Zeitbezug – aber unter Berücksichtigung der limitierten Ressourcen mobiler Systeme und kabelloser Netzwerke zu nennen. Auf Seite der speziellen Gewichtung allgemeiner Anforderungen sei einerseits die hohen Anforderungen an Robustheit im Katastrophenfall zu nennen, andererseits Integrationsfähigkeit im Falle einer räumlichen (weitere Anrainerstaaten etc.) oder funktionalen (neue Prognosemodelle) Erweiterung. Erst in jüngerer Zeit setzt sich überhaupt eine echte Kopplung derartiger Modelle mit Geoinformationssystemen durch [SE03]. 3.1 Architektur Für die Integration heterogener Geodatenbestände (z.B. Fachinformationen der Behörden, dynamisch aktualisierte Umweltdaten, Wasserstandsvorhersagen der HVZ [HOM96] gibt es bis heute keine Standardlösungen. Die Systemarchitektur muss daher

11

offen sein für Schnittstellen zur Eingabe (z.B. Niederschlagsdaten, Datenbanken der Fachbehörden), aber auch für unterschiedliche Endgeräte. Ebenso muss das System skalierbar sein und für künftig Zusatzkomponenten erweiterbar bleiben (z.B. Schnittstelle zu benachbarten Staaten etc.). Zudem müssen Anwendungen immer auf den aktuellen (Geo-)Datengrundlagen arbeiten auch wenn diese von unterschiedlichen Clients aktualisiert werden. Beim Funkweg müssen verschiedene Standards unterstützt werden. Gerade in Katastrophenfällen sind die Mobilfunknetze oft überlastet, so dass ein dynamischer Wechsel möglich sein sollte. Daher sind folgende Anforderungen zu erfüllen: -

Maximale Robustheit im Katastrophenfall Hohe Skalierbarkeit, da im Katastrophenfall viele Nutzer Entwicklung einer verteilten dezentralen Architektur mit offenen Standards [ZA01] Verarbeitung (Datenerfassung und -haltung,) von Geodaten auf mobilem Client; Update- und Synchronisationsmechanismen von Geodaten zwischen Clients und Server. Skalierbare Unterstützung heterogener Endgeräte für raumzeitliche Aus- und Eingabe Schnittstellenbasierte Integration externer Geo-/Umweltdaten, Prognosemodelle

3.2 Mobile Erfassung, Haltung und Analyse von Geodaten Das System muss auf verteilte Datenbestände zugreifen und diese zur Bearbeitung flexibel miteinander kombinieren können. Die Entwicklung leistungsfähigerer mobiler Geräte ermöglicht die Portierung auch aufwändigerer GIS-Anwendungen. Insb. Fragen der mobilen Geodatenerfassung sind noch nicht ausreichend bearbeitet. Nutzer sollen vor Ort Geoobjekte verändern, erfassen und übertragen können. Auf dem Server müssen die Daten in die Geodatenbestände eingefügt werden. Im skizzierten Anwendungsfall werden dabei hohe Ansprüche an Bedienbarkeit und Funktionsfähigkeit des Systems gestellt. Hieraus ergeben sich diverse datenbankspezifischer Anforderungen: Offenheit Für mobile Geodienste sollen offene Schnittstellen eingesetzt werden. Dies soll die starke Heterogenität möglicher Clients abfedern. Gerade im mobilen Kontext muss an unterschiedlichen Orten mit unterschiedlichen Geräten auf heterogene Server-Infrastrukturen zugegriffen werden. Für Geodienste bedeutet dies, dass diese Funktionalität mittels OGC- oder ISO-Schnittstellen auf mobilen Geräten zur Verfügung gestellt werden soll. Diese Standards müssen hierzu zum Teil erweitert werden, damit auch Manipulation und Aktualisieren von Geodaten auf dem Server über ein mobiles Endgerät durchgeführt werden kann. Dies erfordert eine Persistenzschicht, die die geladenen Geodaten auf dem Client lokal und transparent für die Anwendungsebenen zwischenspeichert. Ein entsprechender Prototyp wurde entwickelt [SC01]. Dieser speichert Geodaten gemäß der Geography Markup Language (GML) des OGC auf dem Client, fragt sie mittels räumlicher Zugriffsmechanismen (R-Tree, [GU84]) ab und verfügt über Analysemethoden. Verfügbarkeit und Performanz Bezüglich Verfügbarkeit und Performanz sind besondere Randbedingungen zu erwarten, da die Nutzung eines solchen Systems auf wenige hohe Spitzenauslastungen im Katastrophenfall ausgelegt sein muss, während von einer geringeren laufenden Nutzung auszugehen ist. Damit haben Stabilität und Robustheit höchste Priorität. Weitere Aspekte wie z.B. Sicherheit besitzen gegenüber diesen

12

eine geringe Priorität. Ein effizienter Zugriff auf Geodaten ist also wichtig. Zunächst scheint v.a. die Serverseite gefordert. Allerdings kann schon alleine die Verbreitung der Informationen ein Problem sein kann. Insbesondere spielt dabei die Priorisierung wichtiger Informationen (möglichst benutzergruppenspezifisch) eine wesentliche Rolle. Zur Umsetzung sind Push-Techniken und Data-Dissemination-Verfahren [vgl. z.B. LE01, KU02] zukünftig zu evaluieren und weiter zu entwickeln. Protokolle für ressourcensparende Übertragung von Geodaten Es ist also nötig vektorielle Geodaten zeitnah bidirektional zwischen Client und Server auszutauschen. Hierzu sind ressourcensparende Übertragungsprotokolle zu entwickeln. Neben Standardverfahren (z.B. Veränderungen als Deltas kodiert übertragen) ist zu untersuchen, wie semantisches Wissen über die Geodaten zur Verbesserung progressiver Übertragungsprotokolle ausgenutzt werden kann. Z.B. können Verfahren aus der kartographischen Modellgeneralisierung adaptiert, und z.B. mit räumlichen Fokus-Verfahren [ZR02] kombiniert werden. D.h. schon auf dem Datenbank-Server müssen die Geodaten entsprechend Einsatzzweck und technischen Randbedingungen aufbereitet werden. So sind Streaming-Verfahren zu evaluieren und gegebenenfalls anzupassen [BE99]. Effiziente und flexible raumzeitliche Datenmodelle Wie erwähnt ist auf dem Client eine Persistenzschicht für Geodaten erforderlich. Im Idealfall unterstützt diese auch temporale Veränderung der Geodaten. Hierzu ist ein flexibles raumzeitliches Datenmodell, wie etwa von [ZI01]) zur Verwaltung und Auswertung räumlicher Daten und ihrer zeitlichen Veränderung notwendig. Dies ermöglicht die Entwicklung weitergehender Funktionalitäten hin zu einem raumzeitlichen GIS [BR01]. Zudem ist die Einbeziehung der dritten Dimension der Geoobjekte denkbar. Dabei sind die drei räumlichen Dimensionen und die zeitliche Dimension explizit durch entsprechende Datentypen zu unterstützen und nicht lediglich als zusätzliche Attributwerte zu betrachten [ZK01] Die Beispiele zeigen zwar, daß flexible Datenmodelle existieren, jedoch werden in Raum und Zeit veränderliche Objekte bis hin zu 3D-Geländemodellen als TIN in mobilen Datenbanken bisher nicht effizient genug verwaltet. Neben der Spezifikation der raumzeitlichen Datentypen sind daher entsprechende Datenbankunterstützung für entsprechende ressourcensparende Index- und Abfragmechanismen zu erarbeiten. Dabei ist auf Rechenzeit als auch Speicherbedarf Wert zu legen. Typischerweise kommen hierbei Approximationsverfahren zum Einsatz. Replikation von Geodaten und mobile Transaktionen Ein Teil der Geodaten muss auf dem Client vorliegen, um Aktualisierungen überhaupt vornehmen zu können, und um eine gewisse Unabhängigkeit von unzuverlässigen Funknetzen zu gewährleisten. Also muss eine bestimmte Untermenge des Geodatensatzes auf dem Client repliziert werden [vgl. HOE01]. Dies muss aber aufgaben- und regionen-spezifisch konfigurierbar sein. Hier bietet z.B. das Konzept der nutzerdefinierten Replikation [GO01] erweiterte Möglichkeiten zur anwendungsgesteuerten dynamischen Auswahl von Replikaten replizierter relationaler Datenbankinhalten. Derartige Konzepte sind in weiteren Arbeiten bzgl. einer Adaption an die Anforderungen von Geodaten zu evaluieren. In der Regel sind im direkten Umfeld der Katastrophe sehr genaue und detaillierte Datenbestände notwendig, während die weitere Umgebung weniger genau repräsentiert sein kann. Zudem sollte z.B. ein entsprechender Download von weiteren Untermengen eines vorlie-

13

genden Basisbestands auf dem Client z.B. während der Einsatzfahrt über spezielle Mechanismen vorgesehen sein. Eine Anforderung ist dabei, dass erfasste Daten auf dem Client zwischengespeichert und je nach Verfügbarkeit des Netzwerks in bandbreitenschonender Weise übertragen werden. Dabei ist weniger eine zeitweilige Verfälschung der Datenbasis problematisch, als vielmehr, dass auf keinen Fall Deadlocks entstehen dürfen, oder sonstige Ausfälle des Systems die Folge sein darf. Daneben kann man diskutieren, ob zwar zeitweilig nicht aktuelle Daten vorliegen dürfen, aber es sollte dabei natürlich keine Erfassung am Client komplett verlorengehen (mit Ausnahme des Spezialfalls, daß durch das Fortschreiten des Ereignisses, sprich der Umweltkatastrophe, ein älterer Zustand komplett durch die neue Situation „überschrieben“ werden kann und die Archivierung des Zwischenzustandes zudem nicht für die Anwendung relevant ist). Ein wünschenswerter Aspekt bei der Transaktionssteuerung sind Nutzerrechte, die u. U. eine rollenspezifisch unterschiedliche Priorisierung von Schreib-Requests unterstützen sollten. All diese Aspekte werden durch die thematische Klammer "Konsistenz" zusammengehalten. Wie oben angedeutet ist auch hierbei eine Priorisierung unterschiedlich wichtiger Informationen wünschenswert, So sollten Meldungen mit höchster Priorität, die durch nichts zu behindern sind anders behandelt werden wie sonstige Informationen. Dies hat offensichtlich weitreichende Auswirkungen auf Replikation, Transaktionsmodell (z.B. Echtzeitverhalten für einen Teil der Operationen) und Kommunikation hat. Ortsabhängige Anfragebearbeitung Ein wichtige Möglichkeit ortsbezogener Dienste (LBS) ist die Einbeziehung der Position, um eine Anfrage zu parametrisieren, z.B. auf den relevanten Gebietsausschnitt einzuschränken [ZP01, ZS02]. In welchen Anwendungsfällen ist dies sinnvoll? Ein Beispiel sind „Fokuskarten“, die den wesentlichen Teil einer Karte besonders darstellen [ZR02]. Weniger wichtige Informationen sollen schon früh generalisiert werden [CE00]. Eine weitere Möglichkeit sind ortsbezogen getriggerte Warnhinweise, z.B. wenn ein Nutzer einem akut gefährdeten Bereich zu nahe kommt. Eine weitere Anwendung stellt die ortsbezogene Erlaubnis zur Durchführung von Aktionen dar. So ist es denkbar, daß zur Qualitätssicherung Updates wirklich nur direkt „vor Ort“, d.h., in einer definierbaren Region vorgenommen werden dürfen. 3.3 Bedienschnittstelle Um in einer Krisensituation ein hilfreiches Werkzeug darzustellen, muss die Bedienung gerade in Stresssituationen auch für ungeschulte Benutzer intuitiv und zuverlässig sein. Hierbei sind verschiedene Nutzerrollen (u. Endgeräte) zu unterscheiden: vom zu warnenden Bürger, Stabsstellen, Behörden bis zu den Rettungskräften vor Ort. Besonderes Augenmerk soll auf einer geeigneten Repräsentation räumlicher Daten mittels Karten liegen [ZI02]. Aktuell werden in einem Online-Prototypen hierzu interaktive Vektorkarten auf Basis von SVG (Scalable Vector Graphics) getestet. Neben „SVG-Playern“ für das Web wurden auch erste SVG-Browser für mobile Geräte entwickelt [BR02]. 3.4 Positionierung Positionierungsverfahren zählen nicht zu den datenbank-relevanten Technologien, dürfen aber bei der Entwicklung ortsbezogener mobiler Informationssysteme nicht vernach-

14

lässigt werden. Navigation und Orientierung sind wesentliche Aufgaben [HU03] in mobilen Anwendungen und gerade im Katastrophenfall unerlässlich. Hier sollen nicht die verschiedenen Positionierungstechnologien dargestellt werden, aber auf die Problematik der Genauigkeit der Ortsbestimmung bei Notfällen hingewiesen werden [STA02]. Hoffnung ergeben sich aus neuen Entwicklungen im Bereich Indoor-GPS [AU02]. Intelligente Positionierungs- und Navigationsunterstützung setzt nicht auf einzelne Technologien, sondern auf die integrative Kombination mehrerer Ansätze [KR02].

4. Zusammenfassung und Ausblick In diesem Beitrag wurden Anforderungen an mobile Datenbanken und Informationssysteme anhand des Szenarios Einsatz mobiler Katastropheninformations- und warnsysteme für Prävention und als Kommunikationsplattform im Krisenfall am Beispiel von Hochwasser diskutiert. Neben einer Diskussion von Anforderungen an Architektur und Benutzungsoberflächen wurde den Anforderungen bzgl. der Datenhaltung – und hier insbesondere der Verwaltung und Aktualisierung raumbezogener Daten besondere Beachtung geschenkt. Während zur Zeit die meisten mobilen GIS entweder reine Auskunftssysteme sind, oder aber eine spätere Synchronisierung der mobil aufgenommenen vektoriellen Geodaten mit dem Server bei Rückkehr aus dem Felde zum Einsatz kommt, müssen im skizzierten Fall die Daten aus der mobilen Erfassung zeitnah mit dem Server abgeglichen werden. Diese Synchronisation muss auch unter hoher Last bei unsicheren, kabellosen Netzverbindung funktionieren. Hier fehlen für vektorbasierte Geodaten (im Gegensatz zu rasterbasierte Verfahren [RA99]) optimierte Protokolle für Übertragung und Aktualisierung, Es ergeben sich eine Reihe weiterer interessanter Möglichkeiten und Fragestellungen, z.B. 3D auf mobilen Geräten [CO02], Einbeziehung weiterer Kontext-Faktoren bei der Datenaufbereitung [ZI02], multi-modale Interaktion [HA03], oder Einbeziehung von individuellen Umweltinformationen [STO02].

Danksagung Wir danken der Klaus-Tschira-Stiftung (KTS) für die Förderung und allen Mitarbeitern am EML und Partnern für anregende Diskussionen. Den Reviewern sei für ihre konstruktiven Hinweise zur Verbesserung des Beitrags gedankt.

Literaturverzeichnis [AS03] Assmann, A. u. S. Jäger (2003): GIS-Einsatz im Hochwassermanagement. In: Symposium für Angewandte Geographische Informationstechnologie. AGIT 2003. Salzburg. [BE99] Bertolotto M. & M. J. Egenhofer (1999): Progressive Vector Transmission, ACM-GIS 1999: 152-157. [BR01] Breunig, M. (2001): On the Way to Component-Based 3D/4D Geoinformation Systems". LNIES, . 94, Springer, Heidelberg.

15

[BR02] Breunig, M., Brinkhoff, T., Bär, W. und Weitkämper, J. (2002): XML-basierte Techniken für Location-Based Services. In: Zipf, A. und Strobl. J. (Hrsg.): Geoinformation mobil. Wichmann Verlag. Heidelberg. pp. 26-35. [CE00] Cecconi, A. and Weibel, R. (2000). Map Generalization for On-demand Web Mapping. GIScience 2000, Savannah (GA, USA). [CO02] Coors, V. (2002): Dreidimensionale Karten für Location Based Services. In: Zipf, A. und Strobl. J. (Hrsg.): Geoinformation mobil. Wichmann Verlag. Heidelberg. pp 14-25. [GO03] Gollmick, C. (2003): Nutzerdefinierte Replikation zur Realisierung neuer mobiler Datenbankanwendungen. In: Gerhard Weikum, Harald Schöning, Erhard Rahm (Eds.): BTW 2003, Datenbanksysteme für Business, Technologie und Web, Tagungsband der 10. BTW-Konferenz, 26.-28. Februar 2003, Leipzig: 453-462. [GU84] Guttman, A. (1984): R-trees: a dynamic index structure for spatial searching, Proc. of SIGMOD Conf., Boston. pp. 47-57. [HA03] Häußler, J, Zipf, A. (2003): Multimodale Kateninteraktion und inkrementelle Zielführung zur integrierten Navigationsunterstützung für Fußgänger und Autofahrer. Symp.für Angewandte Geographische Informationstechnologie. AGIT 2003. Salzburg. [HOF02] Hoffmann, M. (2002): Mehrseitig sichere Location Based Services – Endgeräte, Übertragungstechnik und Anwendungen. In: Zipf, A. und Strobl. J. (Hrsg.): Geoinformation mobil. Wichmann Verlag. Heidelberg. pp 75-84. [HOM96]Homagk, P. (1996): Hochwasserwarnsystem am Beispiel Baden-Württemberg. In Geowissenschaften 14, H. 12 (1996) 539-546. [HOE01] Höpfner, H. (2001) Grundlagen von Replikationstechniken für mobile Datenbanken, In Martin Endig, Thomas Herstel (Hrsg.): Tagungsband 13. GI-Workshop "Grundlagen von Datenbanken", Preprint Nr. 10/2001, Institut für Technische und Betriebliche Informationssysteme, Otto-von-Guericke Universität Magdeburg, 68-72, Gommern, Juni 2001. [HU03] Hunolstein S.V. & Zipf, A. (2003): Towards Task Oriented Map-based Mobile Guides. In: Schmidt-Belz et al: HCI in Mobile Guides. Workshop at MobileHCI. Fifth Int. Symp. on Human Computer Interaction with Mobile Devices. Undine. Italy. [KI03] Kienzle, A., D. Hannich u. W. Wirth (2003): Das GIS als Werkzeug bei der Analyse der Erdbebengefährdung urbaner Räume. In: Symposium für Angewandte Geographische Informationstechnologie. AGIT 2003. Salzburg. [KR02] Kray, C., Baus, J. & Krüger, A. (2002): Positionsinformation & Navigationsaufgaben. In: Zipf, A. & Strobl. J. (Hrsg.): Geoinformation mobil. Wichmann. Heidelberg. 98-108. [KU02] Kubach, U. (2002): Vorabübertragung ortsbezogener Informationen zur Unterstützung mobiler Systeme. Dissertation. Universität Stuttgart. Institut für Parallele und Verteilte Systeme. Fakultät Informatik, Elektrotechnik und Informationstechnik. [LE01] Lehner, W. (Hrsg.) (2001): Advanced Techniques in Personalized Information Delivery. Arbeitsbericht des Instituts für Informatik, Universität Erlangen-Nürnberg, 34(5), 2001. [LE02] Lehner, W (2002): Subskriptionssysteme: Marktplatz für omnipräsente Informationen. Teubner Texte zur Informatik, Band 36, B.G. Teubner Verlag Stuttgart. 2002. [LE03] Leiner, R. (2003): Erfassung und Modellierung der räumlichen und zeitlichen Überschwemmungsflächendynamik in Flussauen am Beispiel des nördlichen Oberrheins. Dissertation am Geographischen Institut der Universität Heidelberg. [MA00] Mahlau A. et al. (2000): FLOODFILL Katastrophenmanagement und Risikoanalyse im Hochwasserschutz. AGIT 2000. Symp. f. Angew. Geogr. Info.techn. Salzburg. [NO00] Noggler B. (2000): GIS im Katastrophen- und Zivilschutz. AGIT 2000. Salzburg. [PE03] Peinado, O. et al. (2003): Fernerkundung und GIS im Katastrophenmanagement - die Elbe-Flut 2002. In: AGIT 2003. Salzburg. [RA99] Rauschenbach, U. (1999): The Rectangular Fish Eye View as an Efficient Method for Transmission and Display of Large Images. IEEE ICIP’99, Kobe, Japan. 24.-28.10.1999.

16

[RU02] Ruzicka, R.G. (2002): pocket eHIS – mobiler GPS-unterstützter Zugriff auf geodätische Daten und Umweltinformationen. In: Zipf, A. und Strobl. J. (Hrsg.): Geoinformation mobil. Wichmann Verlag. Heidelberg. pp 210-215. [SE03] Schmidt, F. u. Ehret, U. (2003): HBV-IWS-02 und ArcGIS: Entwicklung eines GISgekoppelten hydrologischen Modells. In: AGIT 2003. Salzburg. [SC02] Schmitz, S., Zipf, A., Aras, H. (2002): Realisierung eines mobilen Geodatenservers für PDAs auf der Basis von Standards des OpenGIS-Consortiums. Workshop "Mobile Datenbanken und Informationsysteme". Universität Magdeburg. 21.-22.03.2002. [SH02] Shekhar S., Huang Y., Djugash J. & Zhou C. (2002): Vector map compression: a clustering approach, In: ACM GIS 2002. Proc. of the tenth ACM int. symposium on Advances in geographic information systems. McLean, Virginia, USA. pp. 74-80. [STA02] Staudinger, M. und Haselgüler, B. (2002): Die Genauigkeit der Ortsbestimmung mit Mobilfunkgeräten bei der automatischen Standortbestimmung in Notfällen. In: Zipf, A. u. Strobl. J. (Hrsg.): Geoinformation mobil. Wichmann. Heidelberg. pp. 150-156. [STO02] Storch, H. (2002): Mobiler Zugriff auf Umweltinformationen – konzeptionelle Anforderungen an integrative Umweltbewertungsverfahren auf der Basis von individuellen Präferenzen in zeit-räumlichen Kontexten. In: Zipf, A. und Strobl. J. (Hrsg.): Geoinformation mobil. Wichmann Verlag. Heidelberg. pp. 157-166. [ZA01] Zipf, A. und Aras, H. (2001): Realisierung verteilter Geodatenserver mit der OpenGIS SFS für CORBA. In: GIS. 3/2001. GIS - Geo-Informations-Systeme. pp 36-41. [ZI01] Zipf, A. and Krüger, S. (2001a): TGML - Extending GML by Temporal Constructs - A Proposal for a Spatiotemporal Framework in XML. ACM-GIS 2001. Atlanta. USA. [ZP01] Zipf, A. (2001): Interoperable GIS-Infrastrukturen für Location-Based Services (LBS) M-Commerce und GIS im Spannungsfeld zwischen Standardisierung und Forschung. In: GIS Geo-Informations-Systeme. 09/2001. pp. 37-43. [ZI02] Zipf, A. (2002): User-Adaptive Maps for Location-Based Services (LBS) for Tourism. In: K. Woeber, A. Frew, M. Hitz (eds.), Proc. of the 9th Int. Conf. for Information and Communic. Techn. in Tourism, ENTER 2002. Innsbruck. Springer. Heidelberg, Berlin. [ZS02] Zipf, A. und Strobl. J. (Hrsg.): Geoinformation mobil. Wichmann Verlag. Heidelberg. [ZK01] Zipf, A. und Krüger, S. (2001b): Flexible Verwaltung temporaler 3D-Geodaten. In: GIS - Geo-Informations-Systeme. 12/2001. pp 20-27. [ZR02] Zipf, A. and Richter, K.F. (2002): Using Focus Maps to Ease Map Reading. Developing Smart Applications for Mobile Devices. In: Künstliche Intelligenz. 04/2002. pp. 35-37.

17

Hunting for Mobile Information - A Report on the Lab Course “Mobile Databases”∗ Birgitta K¨onig-Ries Michael Klein {koenig|kleinm}@ipd.uni-karlsruhe.de Institute for Program Structures and Data Organization Universit¨at Karlsruhe (TH) Am Fasanengarten 5, D-76128 Karlsruhe

1 Introduction With the numbers of mobile devices and applications rising steadily, in the near future, hands-on experience with and theoretical knowledge about mobile information systems will become a key qualification for computer science graduates. The information systems group at the computer science department of the Universit¨at Karlsruhe has therefore decided to complement its “classical” database systems lab course by a second lab course focusing on mobile information systems. The course’s conclusion and highlight is a two day field trial, during which the knowledge acquired during the semester can be applied and extended. This experiment has been designed as an “electronically enhanced” scavenger hunt. The problems are put in such a way that mobile devices and mobile database technology is needed for their solution. In this paper, this field trial is presented in detail. In Section 2 we describe the objectives of the field trial. The Sections 3 and 4 introduce the structure, rules and set-up of the game. In Section 5, we present the results from the first game play in the 2002/2003 fall semester. After a short overview of related activities in Section 6, the paper concludes with a detailed report on the first implementation of the game during the 2002/2003 fall semester and an outlook to future enhancements in Section 7.

2 Objectives of the Lab Course The aims of both the entire lab course and the concluding field trial are threefold: First, the participants should acquire knowledge about (mobile) databases. Second, they should gain hands-on experience with mobile devices and in particular mobile databases. Third, they should practice teamwork and learn how mobile devices can be used to communicate ∗ This

work has been partially funded by the BMBF Program Notebook University [9].

18

and cooperate. Let us have a more detailed look at these objectives:

2.1 Objectives with Respect to Knowledge about Database Systems The participants of the course should learn something about database technology in general, in particular about how to access a database. A particular emphasis is put on the concepts and challenges of mobile database systems. They should learn about the principles behind mobile database technology, the techniques used, and the remaining problems. The outcome of this is the following curriculum: • Querying a database using SQL • Accessing a database using JDBC • Principles of mobile databases: publications and subscriptions • Principles of mobile databases: synchronisation and conflict handling

2.2 Objectives with Respect to Usage of Mobile Devices and Databases A major goal of a lab course is, of course, to offer the participants the opportunity to gain hands-on experience with a particular technology or device. In our case the students are required to use mobile databases and to use different kinds of mobile devices, i.e., laptop computers and PDAs. In more detail, this means: • working with an application scenario (UML class diagrams, . . .). This scenario is then used for the subsequent assignments. • accessing and querying a mobile DBMS. • defining appropriate subscriptions and publications for the sample application using Pointbase Embedded. • writing a Java application for manipulating the data that can run on a PDA. • synchronizing data using Pointbase Unisync. • implementing customized conflict resolvers using Pointbase Unisync.

2.3 Objectives with respect to Communication and Cooperation The ability to work in a team is a valuable skill that is not emphasized very often in a university setting. The lab course offers an opportunity to experience team work and to learn about supporting tools and techniques. The participants should learn

19

• how to organize work within a team, making sure that all the goals are met, • how to organize communication within a team, • how to use tools like CVS that support cooperation.

2.4 Objectives of the Field Trial During the semester, the students have the opportunity to acquire all the skills mentioned above one by one. The field trial then, gives them the opportunity to apply everything that has been learned in a new, realistic setting, to use the individual skills in combination, to deepen the understanding of the concepts, and to obtain some practical experience using mobile devices “out in the field”.

3 The Game Now, that we know what the participants are supposed to learn during the two day field trial, let us take a closer look at what happens during those two days.

3.1 Idea of the Game The basic idea of the game is an “electronically enhanced” scavenger hunt with mobile devices. Generally, the participating players are divided in n + 1 ≥ 3 groups: Group A, which creates the scavenger hunt and n Groups B1 , . . . , Bn , which are in competition and race each other to solve these problems. In detail, the process looks like this: Group A creates a more or less complex puzzle. The solution of this puzzle yields a password. The information needed to solve this problem is transformed in different ways and distributed at different locations within the gaming area. For solving the scavenger hunt, the teams of the chasers B1 , . . . , Bn get mobile devices to gather the information, which is necessary to derive the password. The team that is able to reconstruct the password first, wins the game. To achieve the learning goals listed in the previous section, it makes sense to use mobile database systems for information storage on the mobile devices. Devices could be PDAs or laptops – cell phones are not suitable because of their limited capabilities. The synchronization of the information within each group is achieved by dedicated central server database systems, one for each chasing group. Typically, the communication is done via wireless network connections (like the WLAN network DUKATH [2] on the campus of our university). Moreover, the following conditions should be fulfilled in order to enhance the learning effect:

20

• High amount of information. The amount of information has to be so large that it is not possible to just manually scan the information to solve the puzzles. Rather, it should be necessary to use database technology to analyze the information. This means in particular, that it should be necessary to use SQL statements to retrieve relevant subsets of the data. Furthermore, the participants should need to rely on the database’s data filtering methods as the storage capabilities on the mobile device are limited. • Network Partition. Parts of the information should be disseminated to gaming regions without network access to train the usage of the database in an offline mode, requiring subsequent synchronization, when a connection to the network becomes possible again. • Spatial distribution. The distribution of the information should require the team members to search at different locations in parallel, if they do not want to fall behind their competing teams. This simulates a realistic spatial distribution of the distributed mobile databases. • Conflicting information. Some of the individual information parts should be contradictory in order to force the group members to use the conflict resolving mechanism of the database. An important additional requirement is, that the scavenger hunt should be designed in such a way, that the competing groups can start with different tasks. Thereby, copying of other groups’ solutions can be avoided. However, it needs to be made sure, that the puzzles are equally demanding for each group. Like in conventional scavenger hunts, the game gets especially interesting if information is becoming available successively by solving parts of the complete puzzle. For solving these puzzle fragments, information from different sources and locations should be necessary.

3.2 The Model After the informal introduction in the previous section, we will now introduce the formal model of the information at the core of the game. The basic concept of the model is a message, i.e. all information that is exchanged during the game exists as a message (see Figure 1). Each message is defined by a unique id and contains a message text text, which can be used for different purposes. This text can be a semantically true or false statement, which is expressed by the boolean attribute truth. Thus, messages that are definitely false can be ignored. Values that are not known yet are set to NULL. Messages can be assigned a group membership. This attribute allows to formulate information about more than one message. When preparing the game, Group A defines one or more locations for each message (location attribute): As record in the central team database for Bi , at an arbitrary location in the gaming area, or nowhere, i.e. the message stays in the creating database of Group A and is therefore invisible to the hunters. All locations except for nowhere are denoted as accessible location.

21

Message -ID : string(idl) -text : string(idl) -truth : boolean(idl) -location : string(idl) -group : string(idl)

Figure 1: UML-Diagram of a message. Basically, all information in the game is represented as messages.

3.3 Playing the Game 3.3.1 3.3.1 Creating the Game. If the game creation is examined more formally, it can be regarded as a sequence of transformations applied to an initial starting message. In principle, this sequence has to be reversed by the hunting teams. Starting point for Group A is a true message N in the central team databases of the hunters, which gives away the secret password: “The password is x”. As this message would be visible to all hunters directly, the game would end at once. Thus, the access to this message has to be aggravated. Basically, Group A can use one of six transformations to hamper the access to Message N: 1. Change of Location. N is put to another location. 2. Cut-out. One of N’s attributes is replaced by NULL. 3. Technical Distraction. At N’s location, another false message with an arbitrary text is put, e.g. “Further messages can be found in the office of Michael Klein”, which is not correct. 4. Semantical Distraction. At N’s location, another true message is put, but its text is senseless or irrelevant, e.g. “Peter has a green jacket”. 5. Technical Transformation. N is transformed technically, e.g. encrypted or split into several messages. 6. Semantical Transformation. N is replaced by one or more messages containing a classical puzzle (like cross word puzzles or logic puzzles), which yields N’s text as solution OR N is replaced by a message containing an instruction, which leads to N’s text when executed, e.g. “Ask employee X for the text of message N” or “Enter the solution from Message 26 into the website Z to obtain the text from Message N”. Notice that the first five transformations can be automated by tools (and are inherently reversible), whereas the last operation needs some creativity by Group A and cannot be

22

supported by an algorithm. Additionally, its reversibility has to be checked by the attendant team. However, inventive semantical transformation are crucial for an interesting and motivating game. More details for the first five transformations can be found in Table 1. 3.3.2 3.3.2 Preparing the Game. Before the created game can be played, some preparations are necessary. Basically, all messages in the creation database of Group A have to be disseminated to their given location, i.e. they are copied to one or more team databases or they are put to N.location in the gaming area. To do this, Group A should use different media like floppies, CDs, zip discs, computers with stored files that can be access via cable, WLAN or bluetooth, or simple sheets of paper that have to be typed manually. Each Message N with N.location = ’nowhere’ remains in the creation database and is not visible to the hunters. 3.3.3 3.3.3 Execution of the Game. B1 . . . Bn ’s task of the game is to know the password first. At the beginning, every member of every hunting team synchronizes her local database with the server database of her team, i.e. an initial download is executed. After that, everyone – sometimes alone, sometimes with others – tries to revers the transformations by solving the puzzles. Frequently, the distributed databases have to be synchronized by the team members, which sometimes results in conflicting data. The hunters have an additional table Hypothesis, which can be used to add own remarks or to test reverse transformations. This table has the same schema as the message table, but possesses the additional attribute note, which accepts arbitrary texts for a message. Basically, all originally found messages are entered unmodified into the Message table, whereas all manually altered messages are stored in the Hypothesis table. The Hypothesis table is also synchronized via the team server yielding further conflicts if group members enter contradictory theses to a message. Typically, these conflict can be handled manually only.

4 Technical Realization When we played the game for the first time, we used the following technical realization: We started with 4 hunting teams and 8 laptops (DELL Latitude C840) all equipped with WLAN cards and bluetooth capabilities. As server as well as mobile database, we used Pointbase Embedded in version 4.4 [13]. This is a pure java application that only needs one single jar file with the size of approximately 2 MB for its execution. From the laptops, we accessed it with Pointbase Console. The participants of the game knew this database as they had used it during the semester for their assignments. We preferred Pointbase (instead of other more popular products like Microsoft SQL Server CE [5] or Oracle9i Lite [11]) because of its good documentation, the pure java implementation, and its good portability.

23

Transformation Change of Location

Cut-out

Technical traction

Dis-

Semantical Distraction

Technical Transformation (Encryption)

Technical Transformation (Splitting)

Input

Effect

Message N new accessible location o

new Message M with M.location = N.location M.text = ’N’s location is o’ M.truth = true N.location = o

Message N

t = N.text, w = N.truth new Message M with M.location = N.location M.text = ’N’s text is t’ or M.text = ’N’s truth ist w’ M.truth = true N.text = NULL or N.truth = NULL

Message N [arbitrary text t]

new Message M with M.location = N.location M.text = t or arbitrary M.truth = false

Message N [irrelevant text t]

new Message M with M.location = N.location M.text = t or from phrase generator M.truth = true

Message N [Key k] Encryption method V

key = k or arbitrary new Message M with M.location = N.location M.text = V(N.text, key) M.truth = N.true new Message K with K.location = N.location K.text = key K.truth = true new Message L with L.location = N.location L.text = ’If M is encrypted with Key k via Method V, you obtain Message N’ L.truth = true N.location = ’nowhere’

Message N Number of parts x

new Messages M1 . . .Mx with Mi .location = N.location Mi .text = ith part of M.text Mi .truth = N.true new Message L with L.location = N.location L.text = ’Combine Messages M1 . . . Mx to obtain Message N L.truth = true N.location = ’nowhere’

Table 1: Transformation methods that can be automated to make the access to Message N more difficult. The semantical transformation is not listed as it cannot be supported by an algorithm.

24

The synchronization between server and client database was supported by Pointbase Unisync, which propagates the changes of the client to the server and also updates the local records. Appearing conflicts could be handled manually or automatically with the help of customizable conflict resolvers. To transfer the data between server and client, we used the wlan network of the university, DUKATH [2]. Besides Pointbase’s database tools, we developed an own java based shell, which offers commands for the presented transformations and their reverse transformations like encrypt, decrypt, phrase and so on. Moreover, it allows to freely edit messages to support semantical transformations.

5 Evaluation of the Field Trial The game introduced above was played for the first time as the conclusion of the 2002/2003 fall semester’s lab course on mobile databases and information systems. In that semester, there was a total of 16 participants in the course. They were split into two groups, A and A’. During the first day, each of these groups designed a scavenger hunt for the other group to solve. Both groups were able to find appropriate puzzles. To our surprise, these differed widely in their nature. Group A designed a more or less classical scavenger hunt, where information needed to be found at different places. An example for two of their puzzles were: "What animal is on the picture of the room with the number you found in puzzle number 3?" "Find the identifier of the ’SIGMOD Record’ journal series." Group A’, on the other hand, developed puzzles that required less movement and more thinking. An example: "Given 3 fives and a one: compute 24. You may use the four basic arithmetic operations (each one at most once) and brackets. The solution consists of the numbers and operators in the right order (without brackets)." Once the basic puzzles were designed, the groups transformed them according to the rules presented in Section 3. In both cases this resulted in about one hundred messages. Ten of these contained the actual puzzles. Another twenty contained information about how to combine messages to puzzles, keys to decode messages, information about the truth value of messages and information about the location of additional information. The remaining 70 messages did not contain any valuable information and were entered merely to produce “noise” and distract.

25

Group A’, for instance, split up the puzzle mentioned above into the following three messages. The first part of each message is its identifier1 , the second one the truth value (where NULL means unknown), the third the group to which this message belongs, the fourth the contents of the message. The location of the message is omitted here. ("Abeck", NULL, "", "Given the numbers (5,5,5,1) compute 24.") ("Beth", NULL, "", "You may use each of the four basic arithmetic operations and most once. Brackets may be used") ("Deussen", NULL, "", "The solution consists of the numbers and operators in the right order.") ("Schmidt", TRUE, "", "Combine the messages Abeck, Beth, and Deussen to obtain a complete puzzle.") In the next step, they added some distracting information as follows: ("Abeck1", NULL, "blue", "Given the numbers (5,5,5,1) compute 24.") ("Abeck2", NULL, "yellow", "Given the numbers (5,5,5,1) compute 25.") ("Abeck3", NULL, "green", "Given the numbers (5,5,5,1) compute 26.") ("Lockemann", TRUE, "", "Yellow and green messages are wrong.") After that, they used encryption to add another level of confusion. They encrypted the Lockemann message and added a message containing the key and another message containing the information about the key. The new messages looked like this: ("FZI", TRUE, "", "external funding") ("DBS", TRUE, "", "e4fete93mvmeopvmepe") ("Campus", TRUE, "", "Message DBS can be decrypted with message FZI. The resulting message’s id is Lockemann") On the second day, Group A was split up into groups B1 and B2, while A’ was split up into B1’ and B2’. In the morning, B1 and B2 raced each other to solve the puzzle designed by group A’, in the afternoon, it was the turn of B1’ and B2’ to solve the puzzle developed by group A. All the groups were able to solve the mystery within the time frame allowed. In contrast to our expectations, all the groups chose to work rather stationary. They set up base camps in the building and would only occasionally send off a team member to retrieve remote information. Upon the return of this team member, the information was entered in the team’s database and synchronized. In retrospect, we have identified two main reasons for this (from our point of view rather undesirable) behavior: 1 In

this case the names of Karlsruhe computer science professors.

26

• The groups had access to laptop computers only and apparently found these to have to carry around much. • A tool for distant communication, allowing to tell your group that you just entered information and that therefore, they should synchronize, was lacking. • It was February and it was cold outside. While we have little chance to influence the latter, we have developed some ideas on how to enhance mobility. For the next scavenger hunt, PDAs and a remote communication tool will be available. Also, we are thinking about adding a rule prohibiting face-to-face encounters of certain team members, thus forcing them to use remote synchronization.

6 Related Activities In this section, we give a brief overview of other game-like activities involving mobile devices. We did not find any references to these or similar games being used in teaching about mobile information systems. However, in general, (role) games are a quite popular teaching method. They are used rather frequently in economics curricula (see e.g., [12] for a popular product), but can also be found in technical areas. For instance, the database systems lab course of our group includes a three day role play on database design [1]. Geocaching [3, 7] is a by now rather well known scavenger hunt that is based on the usage of mobile, GPS-enabled devices. The basic idea is to publish the coordinates of a starting point and scavenger-like instructions how to proceed from there (which often involve some computations to obtain the next coordinate or the coordinates of the cache). Once the cache is found, the finder adds an entry to the log book and swaps something hidden in the cache for something he brought. Information about caches is published in dedicated web portals. Some theoretical work on mobile, augmented reality games can be found in [10]. The games proposed there are implemented based on the neXus platform [8] developed by the authors. This platform offers some of the functionality of mobile databases.

7 Conclusion In this paper, we have described an electronically enhanced scavenger hunt. This scavenger hunt is used as integral part of the mobile information systems lab course at the information systems group of the Universit¨at Karlsruhe. The goals of this scavenger hunt are on the one hand to offer the students the opportunity to use the knowledge they have acquired during the semester in a realistic setting and on the other hand to enable them to experience working with mobile devices and mobile databases out in the field.

27

The evaluation of last semester’s instantiation of the game has led us to the following modifications for the next run: • The database needs to be available on PDAs, thus lowering the threshold to actually move around with the devices. • A tool for remote communication among the group members is needed. ICQ seems like a good choice for this. • Additional game rules requiring team members to be geographically separated should be added. For the first change to be realized, i.e. to make databases available on the PDAs, some technical adjustments are necessary: First, instead of using the rather powerful (and big) Pointbase Embedded, the much more lightweight Pointbase Micro Edition [13] should be used. While this edition lacks some of the features of Pointbase Embedded, e.g. client side filtering, complex SQL queries, and views, the functionality is sufficient for the game. Second, the current GUI uses Swing, which proves to be too resource consuming to run smoothly on the PDAs. Therefore, a reimplementation using Thinlets [14] seems unavoidable. Thinlets allow to describe the GUI as an XML document and offer a very lightweight platform independent implementation of the interface. In addition, the installation of the necessary tools, i.e., the database, the communication tool, the tools for the creation of the game, on the mobile devices should be made easier. Here, the software station developed by L IU and O BREITER [4] seems to be a promising approach: Their software station allows for the automatic download, installation, configuration, and maintenance of all the necessary components via a simple webpage access. This method does not require any tool to be present or any special set up of the mobile device. To summarize, we believe the scavenger hunt to be an excellent tool for teaching concepts and usage of mobile information systems. It offers a task that is at the same time challenging, educational, realistic and fun. On the other hand, the game is an interesting prototype considering the tremendous growth rates in the market for mobile games that are being forecast for the near future. In particular, games that – like the scavenger hunt – more or less seamlessly integrate virtual reality and real life, seem to be on the rise.

Acknowledgement We would like to thank our teaching assistants Markus Oster, Kai Goller and Johannes Matheis for implementing the tools and installing the game environment. We would also like to thank all the participants for taking part so enthusiastically.

28

References [1] Database Systems Lab Course. IPD, Universit¨at Karlsruhe. http://www.ipd.uka.de/∼dbprak [2] Drahtlose Universit¨at Karlsruhe (TH) (DUKATH) (engl. Wireless University Karlsruhe). http://www.uni-karlsruhe.de/Uni/RZ/Netze/DUKATH/ [3] Geocaching. http://www.geocaching.de, http://www.geocaching.com [4] Lei Liu, Philipp Obreiter: The Software Station – a System for Version Controlled Development and Web Based Deployment of Software for a Mobile Environment. Submitted to 20th National Conference on Data Bases, Changsha, China (2003) [5] Microsoft Corporation: SQL Server CE http://www.microsoft.com/sql/ce/default.asp [6] Practical Seminar Mobile Datenbanken und Informationssystem (engl. Mobile databases and Information Systems) at the Institute for Program Structures and Data Organization, Chair Prof. P. Lockemann. Universit¨at Karlsruhe (TH), 2002. http://www.ipd.uni-karlsruhe.de/∼modbprak/ [7] Navicache. http://www.navicache.com [8] University of Stuttgart. SFB 627: Nexus – Umgebungsmodelle f¨ur Mobile Kontextbezogene Systeme (engl. Environmental models for mobile context-aware systems) http://www.nexus.uni-stuttgart.de/ [9] Notebook University Karlsruhe (TH)-Projekt (NUKATH) within the BMBF Program Notebook University. http://www.nukath.uni-karlsruhe.de/ [10] Daniela Nicklag, Christoph Pfisterer, Bernhard Mitschang: Towards Location-based Games. In: Loo Wai Sing, Alfred (ed.); Wan Hak Man (ed.); Wong Wai (ed.); Tse Ning, Cyril (ed.): Proceedings of the International Conference on Applications and Development of Computer Games in the 21st Century: ADCOG 21; Hongkong, 22.-23. November 2001 [11] Oracle Corporation: Oracle9i Lite. http://otn.oracle.com/products/lite/content.html [12] TOPSIM.com http://www.topsim.com/ [13] Pointbase Inc.: Pointbase Embedded, Pointbase Micro, Pointbase Unisync. http://www.pointbase.com/ [14] Robert Bajz´at: Thinlets. http://www.mycgiserver.com/∼thinlet/

29

Generischer Zugriff auf Lotus Notes Datenbanken mit mobilen Endgeräten unter Verwendung von Portaltechnologien Walter Niess, Thomas Flor, Gabriel Vögler DaimlerChrysler AG Forschung Information und Kommunikation Software-Architekturen (RIC/SA) Wilhelm-Runge-Straße 11 Postfach 23 60 D-89013 Ulm [email protected]

Zusammenfassung: Im Folgenden soll dargestellt werden, wie mit mobilen Endgeräten, wie z.B. PDAs oder WAP-Mobiltelefonen auf beliebige Lotus-NotesDatenbanken zugegriffen werden kann. Durch Verwendung des IBM WebSphere Everyplace Access Servers ist sowohl Online- als auch ein Offlinezugriff möglich. Ein generisches Portlet stellt einen allgemeinen Zugriffsmechanismus auf NotesDatenbanken zur Verfügung. Hierbei kann die Darstellung speziell an die Anforderungen kleiner Displays von mobilen Endgeräten angepasst werden. Da unternehmenskritische Daten verarbeitet werden sollen, spielt Sicherheit eine wichtige Rolle.

1

Einsatz von PDAs in Unternehmen

Personal Digital Assistants (PDAs) finden immer größere Verbreitung. Wurden sie anfangs nur als elektronische Alternative eines papierbasierten Zeitplansystems zum Speichern persönlicher Daten, wie Kalender, Kontakte und Notizen verwendet, also sogenannter PIM(Personal Information Management)-Daten, so sind sie heute aufgrund der zunehmenden Leistungsfähigkeit immer flexibler einsetzbar. Auf heutigen Geräten finden sich neben Textverarbeitung und Tabellenkalkulation oder einem Anzeigeprogramm für elektronische Bücher (eBooks) auch Anwendungen, die von möglichen Internetverbindungen Gebrauch machen, wie z.B. ein E-Mail-Client oder ein Internet-Browser. Selbst Telefonanwendungen existieren, mit denen PDAs als Mobiltelefon verwendet werden können. Auch in Unternehmen finden PDAs immer breitere Anwendungsbereiche. Aufgrund ihrer Leistungsfähigkeit und der zunehmenden Bandbreite von Mobilfunknetzwerken sind sie nicht nur stand-alone oder offline einsetzbar, sondern können als Clients im verteilten Unternehmensnetzwerk eingesetzt werden. Es ist möglich, größere Anwen-

30

dungen auf ihnen auszuführen und auf Ressourcen im Unternehmensnetzwerk zuzugreifen. So sind nicht nur die klassischen PIM-Daten auf mobilen Endgeräten verfügbar, sondern alle im Unternehmen bereitgestellten Informationen, wie z.B. Dateien auf Dateiservern, Datenbankinhalte von Datenbankservern und auch dynamische von Applikationsservern bereitgestellte Daten. Lotus Domino [Ibm03a], [Ibm03d] und Lotus Notes [Ibm03e] werden in vielen Unternehmen als Groupware-Lösung eingesetzt. Neben PIM- und E-Mail-Datenbanken wurden häufig weitere Anwendungen unter Lotus Notes implementiert. Diese sind zwar am Arbeitsplatzrechner verfügbar, jedoch nicht von mobilen Endgeräten aus. Eine Möglichkeit, diese Datenbanken auch für mobile Endgeräte zur Verfügung zu stellen, soll im Folgenden beschrieben werden.

2

Anforderungen an den PDA-Zugriff auf Lotus Notes Datenbanken

Im Unternehmensnetzwerk verfügbare Lotus-Notes-Datenbanken sollen mit PDAs erreichbar sein. Dies soll weltweit möglich sein. Hierzu können Verbindungen zum Unternehmensnetzwerk durch vorhandene Mobilfunknetzwerke aufgebaut werden. Es sollen keine Änderungen an den vorhandenen Notes-Applikationen nötig sein. Weitere Notes-Datenbanken verfügbar zu machen, muss mit möglichst geringem Aufwand und ohne Programmierkenntnisse möglich sein. Die Darstellung der Daten muss für die kleinen Displays der PDAs angepaßt werden. Für Desktop-Rechner erstellte Ansichten würden bei PDAs dazu führen, dass häufig horizontal und vertikal gescrollt werden müsste. Deshalb sollten Daten, die im mobilen Einsatz nicht benötigt werden, nicht angezeigt werden. Hierbei ist zu berücksichtigen, dass es evtl. mehrere Benutzergruppen einer Notes-Anwendung gibt, die unterschiedliche Daten benötigen. Der Zugriff auf die Notes-Datenbank muss personalisiert erfolgen. Jeder Anwender muss mit seiner eigenen Benutzer-ID auf die Notes-Datenbank zugreifen, nicht über eine zentrale Benutzer-ID, die von allen Anwendern für den Zugriff verwendet wird. Somit ist sichergestellt, dass die in der Notes-Umgebung festgelegten Sicherheits-Maßnahmen nicht umgangen werden können. Der Dominoserver bietet zwei Möglichkeiten zur Authentifizierung: Entweder per Notes-Passwort unter Verwendung der Notes-ID-Datei oder unter Verwendung des Internet-Passworts. Da die Notes-ID-Datei typischerweise auf dem Arbeitsplatzrechner des Anwenders liegt und nicht für das mobile Endgerät oder für einen Serverprozeß zur Verfügung steht, sollte die Authentifizierung mittels Internet-Passwort erfolgen. Hierfür wird die Notes-ID-Datei nicht benötigt. Auf dem mobilen Endgerät dürfen aus Sicherheitsgründen keine unternehmenskritischen Daten zwischengespeichert werden. Dadurch besteht keine Gefahr, dass Daten in falsche

31

Hände gelangen, falls das Gerät verloren geht. Im Gegensatz dazu stellt das Zwischenspeichern nicht unternehmenskritischer Daten kein Sicherheitsrisiko dar.

3

Technologien und Schnittstellen für den Noteszugriff

Für die Realisierung des Noteszugriffs stehen die im Folgenden betrachteten Technologien zur Verfügung. Durch ihre Verwendung ist eine relativ schnelle und einfache Umsetzung möglich, da hierfür Werkzeuge existieren. 3.1

IBM WebSphere Portal Server

Beim IBM WebSphere Portal Server [Ibm03c], [Ibm03g] handelt es sich um einen Internet-Portalserver. Er stellt Portalinhalte auf mehreren Seiten bereit. Die Seiten können zu Seitengruppen zusammengefaßt werden. Jede Seite kann mehrere rechteckige Bereiche zur Darstellung von Informationen enthalten. Diese sogenannten Portlets sind also Teil einer Webseite, die Informationen in rechteckigen Bereichen auf der Seite darstellen können.

Abbildung 1: IBM WebSphere Portal Server

Der IBM WebSphere Portal Server kann personalisiert werden. Seiten und Seitengruppen können benutzerabhängig definiert werden. Auch Konfigurationen von Portlets können benutzerabhängig gespeichert werden.

32

Durch den Portalserver werden Inhalte durch Authentifizierung geschützt. Nur berechtigte Anwender erhalten Zugang zum Portal. Der Portalserver bietet für Portlets die Möglichkeit, Daten persistent abzulegen. So wird z.B. die Konfiguration von Portlets persistent im Portal gespeichert. 3.2

IBM WebSphere Everyplace Access

IBM WebSphere Everyplace Access [Ibm03b], [Ibm03f] ist eine Erweiterung des IBM WebSphere Portal Servers. Im Gegensatz zum Portal Server, der Portalinhalte für Desktop-Rechner zur Verfügung stellt, kann der Everyplace Access Server Webseiten geräteabhängig auch für WAP-Geräte, iMode-Geräte und PDAs darstellen. Portlets können ihre Inhalte nicht nur als HTML darstellen, sondern auch als WML oder cHTML. Für PDAs können Inhalte speziell angepasst werden, also z.B. weniger Informationen dargestellt oder auf mehrere Seiten verteilt werden. Der IBM WebSphere Everyplace Access Server bietet neben der Möglichkeit des Onlinezugriffs auch die Möglichkeit, Portalinhalte auf PDAs für einen Offlinezugriff zu synchronisieren. Dadurch ist es ohne Programmieraufwand möglich, ein Portlet, das für Online-Zugriff entwickelt wurde, offline verfügbar zu machen. Außerdem stehen viele weitere Features zur Verfügung, wie e-Mail- und PIM-Synchronisation, Datenbank-Synchronisation oder Intelligent Notification, die aber in diesem Zusammenhang nicht benötigt werden. 3.3

Java Server Pages (JSP) Abbildung 2: WebSphere

Die Technologie der Java Server Pages [Sun03], Everyplace Access, Zugriff von [RR00] wird verwendet, um dynamische Webinhalte PocketPC anzuzeigen. Hierbei können statische Teile von Webseiten in HTML definiert werden. Die dynamischen Teile werden durch Java-Befehlssequenzen beschrieben. Vor der Ausführung von JSPs werden diese in Java-Klassen übersetzt und können so zur Laufzeit aufgerufen werden. Sie liefern dann die gesamte Webseite, also statische und dynamische Inhalte, zurück. Bei der Entwicklung von Portlets kann JSP verwendet werden, um die dynamischen Informationen als HTML-, cHTML- oder WML-Seiten auszugeben. 3.4

Notes-API

Zum Zugriff auf die Notes-Datenbank stellt Lotus die Notes-API zur Verfügung. Hierüber kann eine Verbindung zu einem Domino-Server aufgebaut und auf eine Datenbank

33

zugegriffen werden. Von der Datenbank können die zur Verfügung gestellten Ansichten sowie die darin enthaltenen Datensätze abgefragt werden. Zu jedem Datensatz kann das zugehörige Dokument mit den enthaltenen Feldern ermittelt werden. Für den Zugriff aus einer IBM WebSphere Anwendungsumgebung muss die JavaBibliothek NCSOW.jar verwendet werden. Diese stellt die Klassen lotus.domino.* zur Verfügung. 3.5

IBM WebSphere Everyplace Access Notes Portlets

IBM liefet mit dem Everyplace Access Server bereits Portlets für den Notes-Zugriff aus. Allerdings ist bei diesen keine Anpassung der Inhalte an die kleinen Displays von PDAs möglich, da nur die vorhandenen Notes-Ansichten dargestellt werden können. Es müssten also spezielle Notes-Ansichten für die PDA-Ausgabe angelegt werden. Damit wäre eine Änderung an der Notes-Datenbank unumgänglich. Da ein generischer Datenbank-Zugriff auf alle Notes-Datenbanken ohne Anpassungen innerhalb der Notes-Umgebung möglich sein soll, wurde ein eigenes Portlet entwickelt. Mit diesem ist es möglich, ohne Programmierung, also nur durch Konfiguration, beliebige Notes-Datenbanken für PDAs verfügbar zu machen und dabei die Inhalte für kleine Displays anzupassen.

4

Webbrowser

Architektur

Das NotesViewer-Portlet läuft im IBM WebSphere Portal Server. Der Webbrowser des PDAs greift mittels HTTP auf den Portal Server zu. Dieser liefert die angefragten Seiten als HTML-, cHTML- oder WML-Seiten an den Browser zurück, abhängig von den Fähigkeiten des Browsers. Um die Datenbankinhalte anzuzeigen, greift er auf das NotesViewer-Portlet zu.

IBM WebSphere Portal Server

NotesViewerPortlet

JSP

Notes-API

Lotus Domino

DB Das NotesViewer-Portlet ermittelt die angeforderten Daten, indem per Notes-API unter Verwendung des Domino-Internet-Inter-ORBProtokolls (DIIOP) eine Verbindung zum Domino-Server aufgebaut und auf die Datenbank zugegriffen wird. Die Ergebnisse der Anfrage werden mittels Java ServerPages dargestellt.

Abbildung 3: Architektur

34

5

Generisches Lotus-Notes-Zugriffsportlet

Eine Notes-Datenbank besteht typischerweise aus mehreren sogenannten Views. Für jede dieser Ansichten von Datenbanktabellen sind die darzustellenden Spalten, Selektions- und Sortierkriterien in der Notes-Datenbank definiert. Das NotesViewer-Portlet kann die vordefinierten Ansichten auf Dektop-PCs und auf PDAs bzw. WAP-Mobiltelefonen darstellen. Wird eines der angezeigten Dokumente ausgewählt, so werden weitere Details zu diesem Dokument angezeigt.

Abbildung 4: Darstellung einer Mail-Datenbank mit dem NotesViewer-Portlet auf Desktop-PC

Bei der Konfiguration des Portlets wird zunächst die darzustellende Datenbank angegeben:

Abbildung 5: Konfiguration der anzuzeigenden Domino-Datenbank

Hierfür wird der DNS-Name bzw. die IP-Adresse, der Name des Domino-Servers sowie der Pfad unter dem die Datenbank auf dem Domino-Server erreichbar ist, eingetragen. Für den Zugriff wird der Benutzername sowie ein Passwort benötigt. Anschließend wird aus der Liste aller in der Datenbank verfügbaren Ansichten die gewünschte ausgewählt. Zusätzlich kann eine Einschränkung der darzustellenden Spalten getroffen werden, um den Anforderungen einer sinnvollen Darstellung auf kleinen Displays von PDAs gerecht zu werden. Es sollte darauf geachtet werden, dass nur so

35

viele Spalten angezeigt werden, dass nicht horizontal, sondern nur vertikal gescrollt werden muss.

Abbildung 6: Auswahl der anzuzeigenden Ansicht und der Spalten

Wird eines der angezeigten Dokumente ausgewählt, so werden Details zu diesem Dokument angezeigt. Auch hierfür kann definiert werden, welche Felder angezeigt werden sollen.

Abbildung 7: Auswahl der in der Dokumentenansicht darzustellenden Felder

Da die Labels der Felder für die Darstellung eines Dokumentes nicht über die Notes-API aus der Notes-Datenbank auszulesen sind, können diese im NotesViewer-Portlet definiert werden. Dadurch können sinnvolle Bezeichner statt kryptischer Feldnamen angezeigt werden.

36

6 6.1

Anforderungen an die Datensicherheit Sicherheit der Portlet-Umgebung

Da mit dem NotesViewer-Portlet auf PDAs auch sicherheitsrelevante Daten verarbeitet werden sollen, ist der Sicherheitsaspekt bei der Realisierung des Portlets sehr wichtig. Folgende Sicherheitsmaßnahmen wurden getroffen bzw. sollten bei der Anwendung des Portlets beachtet werden: Der PDA sollte so konfiguriert werden, dass bei jedem Einschalten eine Authentifizierung mittels Passwort durchgeführt werden muss. Der Cache des Browsers sollte ausgeschaltet werden, um zu vermeiden, dass sicherheitsrelevante Daten bei Verlust oder Diebstahl eines Gerätes in falsche Hände geraten. Hierfür stehen evtl. separate Tools zur Verfügung, wie z.B. die Microsoft Internet Explorer Tools for Pocket PC [Ms03].

Abbildung 8: Darstellung einer Mail-Datenbank mit dem NotesViewer-Portlet auf PDA

Die Einwahl der PDAs ins Unternehmensnetzwerk sollte über vertrauenswürdige Netzwerkbetreiber ggf. unter Verwendung eines Virtual Private Networks (VPN) und über eine Firewall erfolgen. Die Authentifizierung am Portal stellt sicher, dass ein Anwender nur die für ihn freigegebenen Seiten und die für ihn freigegebenen Portlets verwenden kann. Die Benutzerverwaltung des Portals erfolgt auf Basis von Benutzergruppen. Der Zugriff auf den Domino-Server erfolgt durch Authentifizierung mit dem NotesBenutzernamen des Anwenders, so dass alle im Domino-Server bzw. in der NotesDatenbank getroffenen Sicherheitsmaßnahmen Verwendung finden. Dadurch ist u.a. sichergestellt, dass der Anwender nur auf die für ihn freigegebenen Daten Zugriff erhält. 6.2

Sicherheitsvorkehrungen des Portlets

Im NotesViewer-Portlet kann der Administrator Einstellungen bzgl. der zu verwendenden Datenbank oder der anzuzeigenden Ansicht vornehmen. Er kann festlegen, ob die von ihm vorgegebenen Einstellungen vom Anwender geändert werden können oder ob dieser sich an die Vorgaben halten muss.

37

Abbildung 9: Security-Einstellungen

Erhält der Anwender nicht alle Rechte, so werden die Menüpunkte zur Konfiguration der entsprechenden Einstellungen ausgeblendet. Der Anwender erhält also keine Möglichkeit, die Einstellungen zu ändern.

7

Zusammenfassung

Mit dem neu entwickelten Portlet ist es möglich, auf beliebige Lotus Notes Datenbanken von mobilen Endgeräten aus zuzugreifen. Durch die Synchronisationsmöglichkeiten von IBM WebSphere Everyplace Access ist neben dem Online- auch ein Offlinezugriff möglich. Durch die Möglichkeiten der Personalisierung des IBM Portal Servers erfolgt der Zugriff benutzerabhängig. Dadurch kommen alle Notes-Sicherheitsmaßnahmen zur Anwendung. Für die klassischen Groupware-Anwendungen, wie PIM und e-Mail existieren andere Synchronisationslösungen für PDAs. Für alle weiteren Applikationsdatenbanken kann das NotesViewer-Portlet eingesetzt werden. Somit sind aktuelle Auswertungen, Berichte, etc. ständig für den Anwender verfügbar.

8

Referenzen

[CB02]

Jeff Calow, Roy W. Bowen: AD101 Building a J2EE Application for Domino and WebSphere, Lotusphere 2002 http://www.ibsi-us.com/IBSYS/LOTUS/LS2002PR.nsf/main

[Ibm03a]

IBM Deutschland GmbH: Lotus Produkte (Stand 24.07.2003) http://www.lotus.com/world/germany.nsf/va_second/Produkte

[Ibm03b]

IBM Deutschland GmbH: WebSphere Everyplace Suite (Stand 24.07.2003) http://www.ibm.com/de/software/websphere/webserver/everyplace.html

[Ibm03c]

IBM Deutschland GmbH: WebSphere Portal Server (Stand 24.07.2003) http://www.ibm.com/de/software/websphere/webserver/portal.html

38

[Ibm03d]

International Business Machines Corporation: Lotus Domino (Stand 24.07.2003) http://www.lotus.com/domino

[Ibm03e]

International Business Machines Corporation: Lotus Notes (Stand 24.07.2003) http://www.lotus.com/notes

[Ibm03f]

International Business Machines Corporation: WebSphere Everyplace Access (Stand 24.07.2003) http://www.ibm.com/software/pervasive/products/mobile_apps/ ws_everyplace_access.shtml

[Ibm03g]

International Business Machines Corporation: WebSphere Portal for Multiplatforms (Stand 24.07.2003) http://www.ibm.com/software/webservers/portal

[Ms03]

Microsoft Corporation: Power Toys for the Pocket PC, (Stand 24.07.2003) http://www.microsoft.com/windowsmobile/resources/downloads/pocketpc/ powertoys.mspx

[RR00]

Lars Röwekamp, Peter Roßbach: Quattro Stagioni. JSP-Tutorial, Teil 1: Grundlagen der JavaServer Pages, iX 7/2000, S. 152: Webprogrammierung http://www.heise.de/ix/artikel/2000/07/152

[Sun03]

Sun Microsystems, Inc.: JavaServer Pages™ Technology (Stand 24.07.2003) http://java.sun.com/products/jsp

39

¨ Uberblick und Vergleich von Technologien zur Realisierung einer Middleware f¨ur mobile Informationssyteme Sven Apel

Marco Plack

Institut f¨ur Technische und Betriebliche Informationssysteme Otto-von-Guericke-Universit¨at Magdeburg Universit¨atsplatz 2 39106 Magdeburg [email protected]

METOP GmbH An-Institut der Otto-von-Guericke-Universit¨at Magdeburg Sandtorstraße 23 39106 Magdeburg [email protected]

Abstract: Leistungsf¨ahige mobile Ger¨ate wie z. B. Mobiltelefone, Smartphones oder PDAs (Personal Digital Assistant) sind aus dem t¨aglichen Leben nicht mehr wegzudenken. Moderne Konzepte wie ubiquitous und pervasive computing beschreiben eine neue Qualit¨at der Verf¨ugbarkeit von Informationen an jedem Ort zu jeder Zeit mit beliebigen mobilen Ger¨aten. Bereits jetzt stehen mit GSM/GPRS und WLAN moderne Kommunikationsverfahren zur Verf¨ugung, die den Zugang zu Informationen nahezu fl¨achendeckend erm¨oglichen. Das leistungsf¨ahigere breitbandige UMTS wird in Zukunft (2004/2005) GSM/GPRS u¨ ber kurz oder lang ersetzen. Neben der technischen M¨oglichkeit zwischen Ger¨aten Informationen auszutauschen, ist jedoch auch eine Integration von Anwendungen und Diensten ger¨ate¨ubergreifend erforderlich. Ein probater Ansatz zu solch einer Integration ist eine Middleware-Plattform, welche alle daf¨ur n¨otigen Funktionalit¨aten bereitstellt. Die Middleware erm¨oglicht die transparente Kommunikation zwischen mobilen Anwendungen bzw. mobilen Informationssystemen. In diesem Beitrag werden Technologien vorgestellt, welche als Grundlage f¨ur eine solche Middleware dienen k¨onnen. Diese Technologien werden anhand ihrer Eigenschaften klassifiziert und ihr Nutzen abgesch¨atzt. Es werden ein Testszenario sowie gewonnene Erkenntnisse und Ergebnisse vorgestellt.

1

Einleitung

Eine Perspektive der Informationsgesellschaft liegt in der Mobilit¨at der Endger¨ate bzw. des Nutzers. Die Vision ist, dass Informationen immer und u¨ berall zug¨anglich sind bzw. bereitgestellt werden k¨onnen. Eine Vielzahl neuer Endger¨ate und die damit verbundenen M¨oglichkeiten werden zweifellos unser t¨agliches Leben ver¨andern [Wei93]. Begriffe wie ubiquitous oder pervasive computing sind derzeit in der Fachwelt in aller Munde. Diese Begriffe spiegeln die Chancen und M¨oglichkeiten der neuen Mobilit¨at wieder. Mobilit¨at betrifft hierbei den Anwender, die Endger¨ate wie PDAs oder Smartphones sowie die Dienste selbst. Wegen des wachsenden Bedarfs von informationszentrierten Anwendungen wird es immer wichtiger, neben herk¨ommlichen mobilen Anwendungen auch mobile

40

verteilte Informationssysteme zu etablieren. Zur Datenhaltung und Datenverwaltung der Informationssysteme sind auf den mobilen Ger¨aten und auf station¨aren Servern DBMS im verteilten System gekoppelt. Ein probater Ansatz zur Integration der u¨ berall im System verteilten, von den mobilen und station¨aren Informationssystemen bereitgestellten, Dienste ist eine Middleware-Plattform. Diese erm¨oglicht die transparente Kommunikation zwischen herk¨ommlichen mobilen Anwendungen, mobilen Informationssystemen und standalone DBMS im verteilten System1 . Dazu muss die Verteilung der Informationen der mobilen DBMS, die transparente Kommunikation der mobilen Informationssysteme und die Zusammenarbeit mit den mobilen verteilten DBMS realisiert werden. M¨ogliche Anwendungen wie mobile Touristenf¨uhrer, welche ortsabh¨angig Informationen liefern, sind auf Basis der derzeitigen Hardware bereits m¨oglich. Die Entwicklung einer grundlegenden Software-Infrastruktur in Form einer Middleware und in Form von mobilen verteilten DBMS muss noch vorangetrieben werden. Dazu m¨ussen viele Probleme im Bereich der Softwaretechnik gel¨ost sowie auch Verbesserungen im Bereich der Hardware vorgenommen werden. Die Middleware-Plattform integriert grundlegende Dienste, bietet Standardschnittstellen an und erleichtert damit die Entwicklung von mobilen verteilten Informationssystemen. Die Informationssysteme befinden sich dabei auf verschiedensten mobilen und auch station¨aren Ger¨aten. Im verteilten System werden die Informationssysteme als Dienstnutzer und Diensterbringer betrachtet. Um f¨ur die Kommunikation n¨otige Details wie z. B. das Kommunikationsprotokoll oder der Synchronisationsmechanismus brauchen sie sich nicht zu k¨ummern. Auch das Vorhandensein der mobilen verteilten DBMS ist f¨ur die Informationssysteme transparent. Die Middleware befindet sich zwischen Betriebssystem und der Anwendungsebene. Sie ist stark verzahnt mit den mobilen verteilen DBMS. In Abbildung 1 ist verdeutlicht, wie die Middleware mit mobilen DBMS zusammenarbeitet. Die DBMS tauschen untereinander, unter Nutzung der Funktionen der Middleware-Infrastruktur, Daten aus und erm¨oglichen so die transparente Kommunikation zwischen den mobilen Informationssystemen. Weiterhin greift die Middleware auf Funktionalit¨aten der mobilen DBMS zur¨uck. Alle innerhalb der Middleware anfallenden Daten, sowie die f¨ur die mobilen Informationssysteme relevanten Daten werden im mobilen DBMS verwaltet. Der Zugriff der Anwendungslogik eines mobilen Informationssystems auf spezielle Daten anderer Informationssysteme ist transparent. Es spielt dabei keine Rolle ob die Informationssysteme sich auf demselben Ger¨at befinden oder auf verschiedenen Ger¨aten verteilt sind. Weiterhin kann die Anwendungslogik eines Informationssystems auf entfernte DBMS auf mobilen oder station¨aren Servern zugreifen. Im weiteren Beitrag wird in Abschnitt 2 ein m¨ogliches Anwendungsszenario vorgestellt. Ausgehend von diesem Anwendungsszenario werden in Abschnitt 3 die Zielsysteme festgelegt. In Abschnitt 4 werden daf¨ur verf¨ugbare Softwarel¨osungen diskutiert. Weiterhin wird in Abschnitt 5 ein Testszenario pr¨asentiert. Neben der verwendeten Hardware und Software wird eine exemplarische Beispielanwendung vorgestellt. Danach werden die aus den Testszenarien resultierenden Erkenntnisse und Ergebnisse diskutiert. Abschließend werden eine Zusammenfassung und ein Ausblick gegeben. 1 Der Begriff Informationssystem bezeichnet dabei ein DBMS mit Anwendungslogik. Im weiteren Verlauf wird bzgl. der Middleware nur noch von Informationssystemen gesprochen. Die Middleware integriert auch herk¨ommliche mobile Anwendungen, diese werden aber im weiteren Beitrag nicht explizit Erw¨ahnung finden.

41

mobiles Gerät

DBMS

App

App

stationärer Server

Betriebssystem

DBMS

Betriebssystem

Middleware

App

Middleware

Middleware

App

mobiles Gerät

DBMS

Betriebssystem

Kommunikationsmedien

Abbildung 1: Integration von mobilen Anwendungen und mobilen und station¨aren DBMS durch eine Middleware-Architektur

2

Ein Anwendungsszenario

In diesem Abschnitt wird eine E-Learning Applikation als ein m¨ogliches Anwendungsszenario vorgestellt. Die Idee des E-Learning Szenarios ist, dass Studenten einer Universit¨at die M¨oglichkeit haben, mittels mobiler und auch station¨arer Ger¨ate Informationen auszutauschen. Dazu k¨onnen Lerngruppen gebildet werden, in denen sich die Studenten anhand ihrer Interessen virtuell zusammenfinden. Neben dem Austausch von aktuellen Lerninhalten zwischen den Studenten mittels mobiler Ger¨ate, sollen auch zentrale Datenbankserver Informationen bereitstellen. Auf dem Campus steht ein Zugangspunkt f¨ur die drahtlose Kommunikation bereit. Es wird also ein Infrastruktur-Netzwerk mit drahtlosen ¨ sowie drahtgebundenen Ubertragungsstrecken aufgebaut. Die E-Learning Anwendung soll nat¨urlich auch funktionieren in dem Falle, dass sich die mobilen Ger¨ate nicht in Reichweite des Netzzugangspunktes befinden. Das System soll beispielsweise auch außerhalb des Campus funktionieren. Hierzu sollen spontan Ad-hoc-Netzwerke zwischen den einzelnen mobilen Ger¨aten aufgebaut werden. In Abbildung 2 ist das E-Learning Szenario dargestellt. Es ist zu beachten, dass ein Infrastruktur-Netzwerk und Ad-Hoc-Netwerke aufgebaut werden. In Hinblick auf dieses Szenario m¨ussen einige Anforderungen an die Endger¨ate sowie an die verwendeten Technologien der Middleware gestellt werden. Die mobilen Ger¨ate m¨ussen eine gewisse Leistungsf¨ahigkeit besitzen und u¨ ber gewisse Ressourcen verf¨ugen. Die Speicherung, Verarbeitung und Pr¨asentation von Lerninhalten in Form von Textdokumenten, graphisch anspruchsvollen Pr¨asentation bis hin zu Multimediadokumenten verlangt nach einer gewissen Leistungsf¨ahigkeit. Das betrifft nicht nur den Hauptspeicher und die Geschwindigkeit des Prozessors sondern auch die Laufzeit bei Batteriebetrieb,

42

Abbildung 2: Das E-Learning Szenario

das Display sowie das verwendete Kommunikationsmedium und die entsprechenden Protokolle. In diesem Zusammenhang sind auch Ereignisse wie Schwankungen der Bandbreite, h¨aufige Verbindungsabbr¨uche und Positionswechsel der mobilen Ger¨ate zu beachten. Diese geh¨oren eher zum normalen Verhalten von mobilen verteilten Systemen als das sie als Fehlverhalten interpretiert werden. Die Middleware und insbesondere das Kommunikationprotokoll m¨ussen auf diese Besonderheiten zugeschnitten sein.

3

Zielsysteme

Verschiedene Zielplattformen und Betriebssysteme sind derzeit sehr vielversprechend (Tabelle 1) und k¨onnten in dem beschriebenen E-Learning Szenario eingesetzt werden. DeskEndger¨at Mobil

Plattform ARM, XScale

Station¨ar

Desktop PC, Workstation

Betriebssystem Microsoft PocketPC 2002, Embedix Linux (Kernel 2.4) Microsoft Windows, Linux (Kernel 2.4), UNIX

¨ Tabelle 1: Uberblick u¨ ber die Zielplattformen

toprechner besitzen heutzutage meist Prozessoren der x86 Familie oder kompatible Modelle. G¨angige weitverbreitete Betriebssysteme sind Microsoft Windows und Linux. Im Bereich der PDAs existieren mehrere Varianten. Das Betriebssystem Palm OS ist derzeit am meisten verbreitet, und es existieren Implementierungen f¨ur verschiedene Prozessoren. Innerhalb dieses Papiers werden Palm OS Systeme nicht als potentielle Zielsysteme

43

ber¨ucksichtigt, da derzeitige Endger¨ate f¨ur geplante Anwendungen nicht u¨ ber gen¨ugend Leistungsverm¨ogen und freie Ressourcen verf¨ugen. Aktuelle Palm PDAs verf¨ugen u¨ ber bis zu 16 MB RAM und Prozessoren mit 33 MHz - 144 MHz. Es stehen in der Regel keine Compact Flash Slots zur Verf¨ugung. Weiterhin ist die Programmierschnittstelle und die angebotenen Betriebssystemfunktionen f¨ur geplante Anwendungen sowie f¨ur den Einsatz mobiler Informationssysteme, wie das E-Learning Szenario nicht ausreichend. Durch die fehlenden Erweiterungsm¨oglichkeiten ist die Flexibilit¨at der Ger¨ate außerdem sehr eingeschr¨ankt. Bei einer weiteren Gruppe von PDA-Systemen werden ARM-Prozessoren und XScaleProzessoren eingesetzt, und dabei dienen derzeit Embedix Linux oder Microsoft Pocket PC 2002 als Betriebssysteme. Diese Systemkonfigurationen sind derzeit sehr vielversprechend und zeichnen sich durch ein hohes Leistungsverm¨ogen aus. Aktuelle Modelle haben bis zu 64 MB RAM und bis zu 48 MB ROM. Die Prozessoren arbeiten dabei mit bis zu 400 MHz. Sie sind erweiterbar durch SD Slots und CF Slots (z. B. IBM Microdrive 1 GB). Dadurch ist es m¨oglich die Systeme an die Anwendungsf¨alle anzupassen. Hier sind neben Sekund¨arspeicher auch Erweiterungen der Kommunikationsf¨ahigkeit gemeint (GSM/GPRS, GPS, WLAN, ...). Ein Vorteil ist, dass verschiedenste Bibliotheken (z. B. QT embedded, MFC, ODBC, ...) auf diesen Systemen zur Verf¨ugung stehen. Weiterhin wird f¨ur jedes System eine JVM2 angeboten. Diese neue Klasse von Ger¨aten erm¨oglicht die Entwicklung von einer neuen Klasse von mobilen Anwendungen. Es ist m¨oglich nunmehr komplexere Anwendungen auf diesen Ger¨aten zu betreiben. Aus diesen Gr¨unden eigenen sich genannte Ger¨ate als Zielsysteme um komplexe Anwendungen, wie z. B. mobile DBMS oder Multimedia-Anwendungen, zu beherbergen und auszuf¨uhren. Alle weiteren nicht erw¨ahnten Systeme, welche weniger Leistungsverm¨ogen und Ressourcen zu Verf¨ugung haben, werden nicht weiter betrachtet.

4

Vorhandene Softwarel¨osungen

F¨ur die ausgew¨ahlten Zielsysteme existiert eine Vielzahl von Softwarel¨osungen zur Entwicklung von verteilten Systemen. Entfernte Funktions- bzw. Objektaufrufe sind hier die zugrundeliegende Technik. Diverse Klassen- oder Funktionsbibliotheken sind verf¨ugbar, welche eine Programmierschnittstelle zur Implementierung von entfernten Aufrufen erleichtern. Teilweise kommen Generatoren zum Einsatz, welche anhand einer Beschreibungssprache die Kommunikationsbasis eines verteilten Systems fertigen. Wichtige interne Strategien sind die Interprozesskommunikation, verschiedene Synchronisationsmechanismen, Nebenl¨aufigkeit sowie Konsistenzwahrung. Alle diese Aspekte sind f¨ur den Nutzer der entfernten Aufrufe im allgemeinen transparent. Dennoch gibt es zum Teil verschiedene M¨oglichkeiten, interne Strategien wie z. B. den Synchronisationsmechanismus auszuw¨ahlen. 2 Java

Virtual Machine

44

4.1

RPC-Systeme

RPC3 -Systeme bieten die M¨oglichkeit zum Entwurf und zur Implementierung von klassischen verteilten Systemen. Ihnen liegt das request/response-Kommunikationsmodell zugrunde. Parameter werden an die Zielfunktion u¨ bertragen und nach der Abarbeitung wird das Ergebnis zur¨uck¨ubermittelt. Die Kommunikation ist synchron und bidirektional. Dabei existiert nur ein unicast-Mechanismus wobei immer genau ein Sender mit einem Empf¨anger kommuniziert. Weitverbreitet sind z. B. CORBA [Vos97], DCOM [BK98], SUN-RPC [Sri95] und RMI [Eck00]. Werden diese Systeme im mobilen Kontext eingesetzt, treten Probleme auf. Die Systeme enthalten sehr viel Funktionalit¨at und sind sehr m¨achtig. Viele Features werden jedoch nicht im mobilen Bereich ben¨otigt. Die Ressourcenknappheit und damit m¨ogliche Leistungseinbußen bei mobilen Ger¨aten spielen hier eine große Rolle. Weiterhin ist Portabilit¨at und Interoperabilit¨at gerade in heterogenen Netzwerken enorm wichtig. Sie ist bei den genannten Systemen nicht immer gew¨ahrleistet. Die genutzten Low Level-Kommunikationsprotokolle tauschen Informationen in bin¨arer Form aus. Sie sind nicht zu jeweils anderen Protokollen kompatibel und es existieren nicht immer offene Standards. Es sind zwar Implementierungen f¨ur verschiedene Plattformen verf¨ugbar, aber wenn beispielsweise in einem Knoten im verteilten System DCOM genutzt wird, so m¨ussen alle anderen Knoten mit Windows laufen. Wird CORBA genutzt, so muss jede Anwendung den selben ORB4 nutzen. Es gibt zwar F¨alle in denen CORBA beispielsweise mit DCOM zusammenarbeitet, aber diese Interoperabilit¨at l¨asst sich nicht auf High Level-Dienste wie Transaktionsverwaltung, Authentifizierungsmechanismen oder Naming ¨ u¨ bertragen. Durch die verbindungsorientierte Ubertragung kommt es bei hoher Netzlast und Bandbreitenschwankungen zu Problemen. In Mobilfunknetzwerken tritt dies h¨aufig auf [Rot02] und ist damit nicht zu vernachl¨assigen. Im Zielszenario sind viele mobile Endger¨ate untereinander und mit station¨aren Ger¨aten im verteilten System gekoppelt. Da bei herk¨ommlichen f¨ur den station¨aren Bereich konzipierten RPC-Systemen eine starke Bindung zwischen Sender und Empf¨anger besteht, kann nur schlecht bzw. gar nicht auf teilweise h¨aufige Standortwechsel mobiler Endger¨ate reagiert werden. Wie im Abschnitt 2 vorgestellt, spielt die Mobilit¨at der Endger¨ate eine wichtige Rolle und sollte daher auch unterst¨utzt werden. Weitherhin birgt der Einsatz von Firewalls und Proxies im verteilten System Probleme, da evtl. wichtige Ports gesperrt sind. Dies behindert einen reibungslosen globalen Einsatz von klassischen RPC-Systemen in massiv heterogenen Netzwerken.

4.2

XML-Nachrichtensysteme

XML5 -Nachrichtensysteme wie SOAP [Box00] und XMLRPC [Win99] kommunizieren ¨ via XML-Nachrichten. Ahnlich wie in RPC-Systemen werden Parameter und Resultate zwischen aufrufender Funktion und Zielfunktion u¨ bertragen. Allerdings gibt es meh3 Remote

Procedure Call Request Broker 5 eXtensible Markup Language 4 Object

45

rere Interaktionsmuster (1:1, 1:n, n:m) zwischen Sendern und Empf¨angern6 . Ein oder mehrere Sender k¨onnen mit ein oder mehreren Empf¨angern Nachrichten austauschen. Die Verbindung muss nicht zwingend bidirektional sein. Weiterhin gibt es mehrere Sychronsiationsmethoden. RPC-Systeme k¨onnen hinsichtlich dieser Funktionalit¨at als echte Untermenge der XML-Nachrichtensysteme bezeichnet werden. Im allgemeinen sind XML-Nachrichtensysteme sehr schlank und leichtgewichtig. Weiterhin sind sie portabel, interoperabel, Plattform- und Programmiersprachunabh¨angig konzipiert. Das Transportprotokoll ist frei w¨ahlbar. Dies erh¨oht die Flexibilit¨at. Die Kommunikation erfolgt verbindunglos und nachrichtenorientiert. Diese Eigenschaften kommen Problemen wie tempor¨aren Verbindungsunterbrechungen und Bandbreitenschwankungen sowie h¨aufigen Standortwechseln entgegen. Im Allgemeinen ist die Kommunikation mit den unterschiedlichen Synchronisationsmechanismen und den verschiedenen Interaktionsmustern sehr flexibel. In Bezug auf die vorgestellte E-Learning Anwendungen ist eine flexible Kommunikation sehr wichtig. Die verschiedenen Iteraktionsmuster der Kommunikation werden in unterschiedlichen F¨allen genutzt. Ein Broadcast oder Multicast-Mechanismus ist gerade bei Gruppenkommunication in virtuelle Lerngruppen von enormen Vorteil. Es existieren aber auch Probleme beim Einsatz von XML-Nachrichtensystemen. Da sehr oft HTTP [FGM+ 97] als Transportprotokoll eingesetzt wird und Port 80 f¨ur die Kommunikationsverbindung genutzt wird, ist es sehr einfach Sicherheitsbarrieren von Firewalls zu umgehen. Da die Nachrichten oftmals in XML-Klartext u¨ bertragen werden, ist auch die M¨oglichkeit des Mith¨orens Dritter gegeben.

4.3

RPC-Systeme versus XML-Nachrichtensysteme

In Tabelle 2 sind einige Informationen zu RPC-Systemen und XML-Nachrichtensystemen zusammengetragen. Anhand der Tabelle wird deutlich, dass die XML-Nachrichtensysteme gegen¨uber den klassischen RPC-Systemen hinsichtlich des Einsatzes im mobilen Bereich einige Vorteile haben. Gerade die verbindungslose, nachrichtenorientierte, quasi Proxyfreundliche Kommunikation ist ein wesentlicher Vorteil. Diese Kommunikationeigenschaften sind sehr gut f¨ur den Einsatz in der Dom¨ane der potentiellen Zielszenarien geeignet. Ein weiterer wichtiger Grund f¨ur den Einsatz der XML-Nachrichtenssysteme ist die, gegen¨uber den klassischen RPC-Systemen, schlanke und leichtgewichtige Implementierung. Dies ist besonders wichtig beim Einsatz auf den teilweise extrem resourcenbeschr¨ankten mobilen Ger¨aten. Nicht zuletzt spielt auch die Unabh¨angigkeit von Plattform, Betriebssystem und Programmiersprache gerade im massiv heterogenen Netzwerk eine entscheidene Rolle. Alle diese Gr¨unde veranlassen dazu XML-Nachrichtensysteme zur Realisierung einer Middleware f¨ur mobile Informationssysteme zu nutzen. 6 Mehrere

m¨ogliche Interaktionsmuster sind nur beim SOAP-Protkoll vorhanden.

46

Vertreter allgemein

Kommunikation

¨ Ubertragungsformat Probleme

RPC-Systeme CORBA, Sun-RPC, DCOM, RMI ∗ Hoher Funktionsumfang ∗ Sehr m¨achtig ∗ Weit verbreitet ∗ Verbindungsorientiert ∗ Synchron ∗ Bidirektional ∗ 1:1 Interaktion ∗ bin¨ar ∗ Mangelnde Interoperabilit¨at ∗ Standortwechsel ∗ Einsatz von Proxies & Firewalls ∗ Große Datenmengen

XML-Nachrichtensysteme XMLRPC, SOAP ∗ Schlank, leichtgewichtig ∗ Portabel, Interoperabel ∗ Plattform-, Sprachunabh¨angig ∗ Transportprotokoll frsei w¨ahlbar ∗ Verbindungslos ∗ Nachrichtenorientiert ∗ Synchron & Asynchron ∗ Bidirektional & Unidirektional ∗ 1:1, 1:n, n:m (SOAP) ∗ XML ∗ Sicherheitsprobleme (Port 80) ∗ Evtl. Klartext¨ubertragung ∗ Nachteil bei Performance

Tabelle 2: Technologievergleich

4.4

XMLRPC versus SOAP

XMLRPC und SOAP sind zwei bereits relativ weit verbreitete XML-Nachrichtensysteme. Trotz Gemeinsamkeiten, bestehen dennoch wichtige Unterschiede. XMLRPC ist ein reines request/response-Protokoll, d. h. die Kommunikation wird immer von einem Client initiiert. Der Server wartet auf solche Anfragen und antwortet. Durch die sehr geringe Komplexit¨at ist das XMLRPC-Protokoll leicht zu erlernen und zu bedienen. Es existieren viele Implementierungen, die sehr schlank entworfen und realisiert sind. Allerdings k¨onnen nur Grunddatentypen wie Skalare, Felder und namenlose Strukturen u¨ bertragen werden. Das Protokoll ist dahingehend nicht erweiterbar und wenig flexibel. Derzeit existiert keine M¨oglichkeit Transaktionen zu nutzen, Daten zu verschl¨usseln oder Authentifizierungsmechanismen einzubeziehen. Diese komplexeren Mechanismen werden jedoch in Szenarion wie der E-Learning Anwendung dringend ben¨otigt. SOAP ist ebenfalls ein schlankes System. Neben dem request/response-Mechanismus wird auch one-way- und multicast- Kommunikation unterst¨utzt. Im Gegensatz zu XMLRPC k¨onnen getypte Parameter anhand ihres Namens u¨ bertragen werden. Neben den Grunddatentypen k¨onnen anwenderspezifische Datentypen und Namespaces frei definiert werden. Das Protokoll ist erweiterbar und anpassbar. F¨ur die Kommunikation sind mehrere Parameter w¨ahlbar, wie das darunterliegende Transportprotokoll oder der Kodierungsstandard. Weiterhin existiert die M¨oglichkeit das Protokoll um Transaktions- Authentifizierungsund Verschl¨usslungsmechanismen zu erweitern. Ein Vorteil ist auch, dass derzeit verschiedene Adapter zu anderen Protokollen wie DCOM oder CORBA verf¨ugbar oder in Entwicklung sind. Ein weiterer Grund SOAP zu nutzen ist die m¨ogliche Anbindung an die heutzutage immer beliebteren Web Service Plattformen [AAB+ 02].

47

Vorteile

Nachteile

XMLRPC ∗ Geringe Komplexit¨at ∗ Effizienz ∗ Hohe Geschwindigkeit ∗ Große Bandbreite ∗ Einfache Wartung & Fehlersuche

∗ Nur Grunddatentypen ∗ Nicht erweiterbar ∗ Wenig flexibel ∗ 1:1 Interaktion (request/response) ∗ Keine Transaktionen ∗ Keine Authentifizierung ∗ Keine Verschl¨usselung

SOAP ∗ Flexible Nachrichtendienste (1:1,1:n,n:m) ∗ Umfassende Beschr. der Kommunikation ∗ Anwenderspezifische Datentypen ∗ Erweiterbares, Anpassbares Protokoll ∗ Transaktionsunterst¨utzung ∗ Authentifizierungsmechanismen ∗ Verschl¨usselung ∗ Anbindung an Web Services Plattformen ∗ H¨ohere Komplexit¨at ∗ Gewisser Overhead ∗ Schwer erlernbar ∗ Durchsetzung des Standards (W3 C)

Tabelle 3: Vorteile von SOAP und XMLRPC

Da die Middleware m¨oglichst flexibel, erweiterbar, skalierbar und komfortabel gestaltet sein soll, ergibt sich aus Tabelle 3, dass sich der Einsatz von SOAP anbietet. Gerade hinsichtlich der Realisierung von komplexen Anwendungen sowie des massiven Einsatzes von softwaretechnischen Strategien zur Konfigurierbarkeit und Erweiterbarkeit sind die Eigenschaften von SOAP von großem Nutzen. SOAP ist modular aufgebaut, leicht erweiterbar und es erm¨oglicht eine umfassende Beschreibung der Daten und der Kommunikation. Von vielen Anwendungen ben¨otigte Mechanismen, wie Verschl¨usselung von Daten, Transaktionsverwaltung oder sichere Authentifizierung k¨onnen innerhalb von SOAP realisiert werden. Eine weitere Beispielanwendung ist ein Online-Parkscheinautomat. Mittels mobiler Endger¨ate k¨onnte es erm¨oglicht werden Parkscheine innerhalb einer Stadt online anzufordern und auch gleich zu bezahlen. Die Anwendung ben¨otigt die genannten Mechanismen, welche SOAP bereitstellt. Neue komplexere Mechanismen k¨onnen dem Protokoll einfach hinzugef¨ugt werden. Aufgrund der vielf¨altigen Vorteile werden die Nachteile bei Effizienz oder Wartbarkeit gegen¨uber XMLRPC in Kauf genommen. Als gew¨unschte Programmierschnittstellen wurden C++ und Java ausgew¨ahlt, da sie sich hervorragend f¨ur die Realisierung von großen Softwareprojekten eignen. Das umgesetzte objektorientierte Paradigma ist dabei sehr hilfreich und erlaubt modular, skalierbar, erweiterbar und komfortabel zu programmieren. Außerdem existieren viele n¨utzliche Bibliotheken und Schnittstellen, wie Datenbankanbindungen oder Bibliotheken f¨ur Standardprobleme sowie n¨utzliche Algorithmen.

48

5

Testszenario

In diesem Abschnitt wird ein Testszenario betrachtet. Zuerst werden die Endger¨ate ausgew¨ahlt und eine Beispielanwendung vorgestellt. Die Beispielanwendung ist sehr einfach gehalten. Dennoch sind die Ergebnisse in Hinsicht Realisierbarkeit und in Hinsicht der Evaluierung eingesetzter Software und Hardware verwendbar. Die Ergebnisse und gewonnene Erkenntnisse werden im weiteren diskutiert.

5.1

Endger¨ate

Als Testger¨ate dienen verschiedene PDAs und Desktoprechner. Sie wurden anhand der in Abschnitt 3 festgelegten Zielsysteme ausgew¨ahlt. Als Kommunikationsmedium dient ¨ Wireless LAN [CWKS97]. Prinzipiell w¨aren auch andere Ubertragungsstandards m¨oglich. In Tabelle 4 sind die ausgew¨ahlten Testger¨ate zu finden. Sie entsprechen den Vorgaben, die durch die Definition der Zielsysteme gegeben sind. Endger¨at Toshiba e740 WiFi Sharp Zaurus SL-5500G Desktopsysteme

Plattform Intel XScale ARM x86

Betriebssystem Microsoft PocketPC 2002 Embedix Linux (Kernel 2.4) Microsoft Windows 2000, Linux (Kernel 2.4)

¨ Tabelle 4: Uberblick u¨ ber die ausgew¨ahlten Testsysteme

Jedes der Testger¨ate wird die Rolle des Clients sowie des Servers u¨ bernehmen. Die Abbildungen 3 und 4 enthalten die m¨oglichen Konstellationen. Es ist zu beachten, dass im Fall der Kommunikation zweier PDAs ein ad-hoc-Netzwerk und im Fall der Kommunikation zwischen PDA und Desktoprechner ein Infrastruktur-Netzwerk aufgebaut wird. Beim Infrastruktur-Netzwerk wird ein Wireless Access Point als Kopplung zwischen WLAN und LAN genutzt.

WLAN

Abbildung 3: Ad-hoc-Netzwerk zwischen PDAs

49

Access Point

WLAN

LAN

































Abbildung 4: Infrastruktur-Netzwerk zwischen PDA und Desktoprechner

5.2

Beispielanwendung - Der Warenhaus-Dienst

Da die Realisierung des in Abschnitt 2 vorgestellten Szenarios zu komplex ist wurden zur Evaluierung der Technologien ein anderes Szenario gew¨ahlt. Als Beispielanwendung wird ein elektronisches Warenhaus implementiert. Diese ist eine einfache Anwendung und hat in der implementierten Form keine praktische Relevanz. Dennoch eignet sich diese Anwendung, um Aussagen f¨ur praktisch relevante Anwendungen hinsichtlich der Realisierbarkeit zu machen. Durch die geringe Komplexit¨at der Beispielanwendung k¨onnen keine verl¨asslichen Aussagen u¨ ber die Performance get¨atigt werden. Die Beispielanwendung kann aber als Grundlage f¨ur reale Anwendungen dienen. Das elektronische Warenhaus verwaltet in einer Datenbank verschiedenste Artikel. Es werden die eindeutige Artikelnummer und die vorhandene St¨uckzahl verwaltet. Der Warenhaus-Dienst wartet auf Anfragen von Klienten. Der Klient u¨ bergibt bei einer Anfrage die Artikel-Nummer und die gew¨unschte Anzahl des Artikels. Der Warenhaus-Dienst sucht in der Datenbank Informationen zum angeforderten Artikel und anhand dieser wird der Lieferstatus (komplett verf¨ugbar / partiell verf¨ugbar / nicht verf¨ugbar) sowie die Anzahl des verf¨ugbaren Artikels als Resultat zur¨uckgegeben. Der Warenhaus-Dienst soll als nebenl¨aufiger Server implementiert werden und an einem festgelegten Port lauschen. Der Dienst wird als eine Funktion implementiert, d. h. Anfragen werden mittels entferntem Funktionsaufruf get¨atigt.

5.3

Ergebnisse

Die gew¨ahlte Sprachschnittstelle und gleichzeitig die Programmiersprache f¨ur die Testanwendung ist vorerst C++. Der Warenhaus-Dienst wurde mit mehreren C++ basierten SOAP-Implementierungen getestet7 . Allerdings ließen sich nicht alle SOAP-Implementierungen auf allen gew¨unschten Testplattformen nutzen. In Tabelle 5 sind alle getesteten Implementierungen dargestellt. Neben den unterst¨utzten Plattformen sind verschiedene Anmerkungen aufgef¨uhrt. Diese beziehen sich in erster Linie auf Probleme mit den 7 Es

wurden nur C++ Implementierungen getestet. Ein Test von Java Implementierungen sowie ein Vergleich mit den C++ Implementierungen steht noch aus und konnte deswegen nicht mit in dieses Papier genommen werden (siehe Abschnitt 6).

50

Name eSOAP PocketSOAP gSOAP Ms SOAP Toolkit XSOAP++ easySOAP++ WhiteMesa SimpleSOAP WASP-C++

Win 2000 √ √ √ √ √ √ √ √ √

Pocket PC √ √

Linux √

√

√ √

√

√

Anmerkungen nutzt Standard C-Bibliothek COM/DCOM-Anbindung Stub- und Skeletoncompiler nutzt ATL, COM nutzt Ausnahmen nutzt Standard C-Bibliothek nutzt COM nur Visual C++ komplex (≈300 Klassen)

Tabelle 5: C++-basierte SOAP-Implementierungen (einzelne Implementierungen sind unter http://www.soapware.org/ zu finden)

einzelnen Testplattformen. Zwischen einzelnen SOAP-Implementierungen existieren erhebliche Unterschiede (Tabelle 5) bzgl. der Unterst¨utzung einzelner Plattformen. Die meisten Probleme gibt es bei Ger¨aten, welche das Betriebssystem Microsoft Pocket PC 2002 nutzen. Die verschiedenen Implementierungen konnten nicht unter Pocket PC 2002 u¨ bersetzt werden, da keine vollst¨andige C++ Standard Template Library (STL) verf¨ugbar ist. Die STL nutzt unter anderem massiv Ausnahmen und Ausnahmebehandlungen, welche nicht von Microsoft Pocket PC unterst¨utzt werden. Es gibt zwar einige unvollst¨andige Versionen8 , die aber wichtige, von den SOAP-Implementierungen ben¨otigte Funktionen nicht enthalten. Werden Ausnahmen verwendet, ist die Anwendung meist nicht m¨oglich. Weiterhin sind nicht alle ben¨otigten C-Headerdateien bzw. die n¨otigen Bibliotheksdateien vorhanden (Bsp. time.h). Durch die unvollst¨andige STL und die fehlenden C-Header fallen eine große Zahl von Implementierungen heraus und k¨onnen somit nicht genutzt werden. Ein weiteres Problem ist die Nutzung bzw. Anbindung von COM-Komponenten, der Active Template Library (ATL) oder anderen windowsspezifischen Headerdateien und Bibliotheken. Da diese nicht f¨ur Linuxsysteme verf¨ugbar sind, fallen die betreffenden SOAP-Implementierungen heraus. Nur die Implementierungen WASP-C++9 und gSOAP10 waren auf allen Plattformen verf¨ugbar bzw. ließen sich f¨ur diese u¨ bersetzen. WASP-C++ bietet einen nebenl¨aufigen Server und eine Klassenbibliothek f¨ur die Klienten [Rot02]. Weiterhin stehen einige WSDL-Werkzeuge zur Beschreibung der Dienste zur Verf¨ugung [CCMW01]. Das Problem an WASP-C++ ist die hohe Komplexit¨at. Es existieren ca. 300 C++ Klassen f¨ur den Anwendungsprogrammierer. Große Teile werden zur Implementierung der Middleware-Plattform nicht ben¨otigt und verkomplizieren die Nutzung unn¨otig. gSOAP ist im Gegensatz zu WASP-C++ keine reine Programmierschnittstelle [Rot02]. gSOAP liefert einige komfortable Generatorwerkzeuge. Der Generator erh¨alt als Eingabe eine C++ Headerdatei, welche die Schnittstelle des Dienstes beschreibt. Daraus werden client stubs und service skeletons erzeugt. Der Anwender verwendet diese zur Implementierung von Klient und Dienst. Der generierte Quelltext ist sehr effizient. Es wird ein moderner XML Pull Parser verwendet, so dass im Gegensatz zu einem DOM Parser kein Speicherplatz 8 http://users.libero.it/g.govi/index.html 9 http://www.systinet.com/ 10 http://gsoap2.sourceforge.net/

51

Anwender

Entwicklung

Laufzeit

Beschreibung der Schnittstelle (C++ Headerdatei)

Quelltext des Dienstes mit RPC−Implementationen

automatisch

return gSOAP Generator

WSDL

C++ Quelldateien

C/C++ Compiler

call

RPC Skeletons

gSOAP Runtime Lib. Transportprotokoll + XML Anhang−Verwaltung

service response

client request

Abbildung 5: Aufbau und Funktion eines gSOAP-Dienstes

verschwendet wird. Der erzeugte Dienst kann iterativ oder nebenl¨aufig arbeiten und als standalone oder CGI basierter Server in Betrieb genommen werden. Wegen der Portabilit¨at, des Komforts und der Effizienz bietet sich die gSOAP-Implementierung als Grundlage der Middleware-Plattform an. In Abbildung 5 ist der Aufbau eines Dienstes dargestellt. Es sind die Teile, die der Anwendungsentwickler und die der Generator erzeugen, zu erkennen. Aus der C++ Schnittstellenbeschreibung erzeugt der Generator eine WSDL Beschreibung und C++ Quelltext. Der erzeugte Quelltext wird vom Anwender mit Funktionalit¨at angereichert. Die erzeugten Skeletons (de-)serialisieren u¨ bergebene Parameter und nutzen die gSOAP Runtime Library zur Kommunikation mit den Klienten. Im Falle eines Klienten (Abb. 6) wird anhand einer Dienstbeschreibung (WSDL) C++ Quelltext generiert. Die vom C++ Compiler erzeugten Stub-Routinen werden dann vom Klienten zur Kommunikation genutzt und serialisieren bzw. deserialisieren die u¨ bergebenen Parameter. Die Stub-Routinen nutzen ihrerseits die Funktionen der Runtime Library und treten so mit dem Dienst in Verbindung. So komfortabel ein Generator auch sein mag, so existiert doch ein Nachteil. Da aus einer Schnittstellenbeschreibung der Dienst und der Klient erzeugt werden, ist es schwer auf die¨ sen im Sinne von Programmfamilien [Par79] aufzubauen. Jede Anderung der Schnittstelle ¨ w¨urde eine Anderung in der Hierarchie darauf aufbauender Funktionen hervorrufen. So ist es schwer, ein m¨oglichst erweiterbares, skalierbares und wiederverwendbares System zu konstruieren.

52

Anwender

Entwicklung

Laufzeit

WSDL

Quelltext des Klienten ruft RPC−Stubs auf

call

automatisch

C++ Headerdatei (Schnittstelle der RPC−Funktionen)

return

WSDL Importeur

RPC Stubs

gSOAP Generator

gSOAP Runtime Lib. C++ Quelldateien

C/C++ Compiler

Transportprotokoll + XML Anhang−Verwaltung

client request

service response

Abbildung 6: Aufbau und Funktion eines gSOAP-Klienten

6

Zusammenfassung und Ausblick

Es existieren verschiedene Technologien zum Entwerfen und Implementieren von verteilten Systemen. Die Gruppe der klassischen RPC-Systeme eignet sich nicht f¨ur die massiv heterogenen, hoch dynamischen Netzwerke, die entstehen, indem mobile Endger¨ate integriert werden. Die Gruppe der XML-Nachrichtensysteme eignet sich hier besser, da sie sich durch ihre Portabilit¨at und die schlanke Implementierung auszeichnet. Sie sind pr¨adestiniert f¨ur den Einsatz in verteilten Systemen aus mobilen Endger¨aten. SOAP ist ein schlankes, komfortables und erweiterbares Protokoll und ist in einigen wichtigen Punkten XMLRPC u¨ berlegen. Der Vergleich einiger C++ basierter SOAP-Implementierungen ergab, dass nur zwei SOAP-Implementierungen f¨ur alle Testplattformen verf¨ugbar sind. Als geeignete Variante stellte sich gSOAP heraus. ¨ Als n¨achster Schritt steht ein Uberblick und der Vergleich mehrerer Java-basierter Implementierungen sowie die Realisierung der hier besprochenden Beispielanwendung an. Anhand der Beispielanwendung wird entschieden, welche Java-basierten Implementierungen sich eignen. Es bleibt zu pr¨ufen, welchen Funktionsumfang die speziellen virtuellen Maschinen auf den Zielsystemen haben, und ob dieser den Anspr¨uchen der SOAPImplementierungen gen¨ugt. Dann werden alle geeigneten C++-basierten und Java basierten Implementierungen hinsichtlich Komfort, Performance, Interoperabilit¨at und Portabilit¨at verglichen. Auch die zur Verf¨ugung stehenden Bibliotheken und Schnittstellen werden mit einbezogen. Anhand die-

53

ser Ergebnisse ist es m¨oglich eine Auswahl der zu nutzenden Programmiersprache zur Implementierung einer Middleware-Plattform f¨ur mobile verteilte Informationssysteme und Anwendungen zu treffen.

Literatur [AAB+ 02] K. Apshankar, D. Ayala, C. Browne, V. Chopra, T. McAllister, and P. Sarang. Professional Open Source Web Services. Wrox Press Ltd, 2002. [BK98]

N. Brown and C. Kindel. Distributed Component Object Model protocol: DCOM/1.0, January 1998.

[Box00]

D. Box. Simple Object Access Protocol (SOAP) 1.1, W3 C Note 08 May 2000.

[CCMW01] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Services Description Language (WSDL) 1.1, W3 C Note 15 March 2001. [CWKS97] B. P. Crow, I. Widjaja, J. G. Kim, and P. T. Sakai. IEEE 802.11: Wireless Local Area Networks. IEEE Communications Magazine, 35(9):116–126, 09 1997. [Eck00]

Bruce Eckel. Thinking in JAVA. Prentice Hall, 2nd edition, 2000.

+

[FGM 97] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee. IETF RFC 2068: Hypertext Transfer Protocol – HTTP/1.1, January 1997. Available at: http://www.ietf.org/rfc/rfc2068.txt (Informational). [Par79]

D. L. Parnas. Designing Software for Ease of Extension and Contraction. IEEE Transaction on Software Engineering, SE-5(2), 1979.

[Rot02]

J. Roth. Mobile Computing: Grundlagen, Technik, Konzepte. dpunkt-Verlag, 1. edition, 2002.

[Sri95]

R. Srinivasan. RFC 1831: RPC: Remote Procedure Call Protocol Specification Version 2, August 1995. Status: PROPOSED STANDARD., ftp://ftp.internic.net/rfc/rfc1831.txt, ftp://ftp.math.utah.edu/pub/rfc/rfc1831.txt.

[Vos97]

G. Vossen. The CORBA Specification for Cooperation in Heterogeneous Information Systems. In P. Kandzia and M. Klusch, editors, Proceedings of the First International Workshop on Cooperative Information Agents, volume 1202 of LNAI, pages 101–115, Berlin, February 26–28 1997. Springer.

[Wei93]

M. Weiser. Hot Topics: Ubiquitous Computing. IEEE Computer, October 1993.

[Win99]

D. Winer. XML-RPC Specification, 1999. http://www.xmlrpc.com/spec.

54

¨ mobile Ad-hoc-Prozesse∗ Flexible Fehlerbehandlung fur Klaus Haller1 1

2

Heiko Schuldt1,2

Can T¨urker1

Eidgen¨ossische Technische Hochschule Z¨urich Institut f¨ur Informationssysteme CH-8092 Z¨urich, Switzerland

Private Universit¨at f¨ur Medizinische Informatik und Technik Tirol (UMIT) Abteilung Information and Software Engineering ¨ A-6020 Innsbruck, Osterreich {haller,schuldt,tuerker}@inf.ethz.ch

Abstract: Durch die inh¨arente Mobilit¨at und Dynamik moderner Dienstanbieter und -nutzer werden Informationssysteme zunehmend dezentral, auf dem Peer-to-Peer-Paradigma basierend, organisiert. Gleichzeitig werden die Benutzeranforderungen immer individueller. Daher verwenden wir Ad-hoc-Prozesse, die Dienste verschiedener Anbieter b¨undeln, um damit individuelle Benutzerbed¨urfnisse zu erf¨ullen. Solche Adhoc-Prozesse zeichnen sich dadurch aus, dass sie – im Gegensatz zu Gesch¨aftsprozessen mit hoher Wiederholfrequenz – jeweils vom Benutzer individuell zusammengestellt beziehungsweise konfiguriert werden und daher nur einmal oder wenige Male zur Ausf¨uhrung kommen. Mobile Agenten werden dabei zur Prozessausf¨uhrung eingesetzt, um auch ein tempor¨ares Entkoppeln der Benutzer w¨ahrend der Ausf¨uhrung ih¨ rer Prozesse zu unterst¨utzen. In diesem Beitrag bieten wir einen Uberblick u¨ ber unsere Ausf¨uhrungsinfrastruktur und zeigen m¨ogliche Fehlerf¨alle auf, die bei der Ausf¨uhrung von Prozessen durch mobile Agenten zu beachten sind. Ferner diskutieren wir, wie Recovery bzw. flexible Fehlerbehandlung und Mobilit¨at von Anwendungen zusammengef¨uhrt werden k¨onnen.

1

Einleitung

Mit der stetig zunehmenden Mobilit¨at von Anwendern (Dienstnutzern) und Datenquellen (Dienstanbietern) und dem zunehmenden Einsatz mobiler Sensoren zeichnet sich ein Wandel in der Informationsverarbeitung ab. Anwendungsentwicklung erfolgt durch das Zusammensetzen bestehender Dienste zu Prozessen (Workflows), die in einer verteilten Umgebung angeboten werden. Anwendungen beschr¨anken sich jedoch nicht mehr ausschließlich auf vordefinierte Prozessmuster. Sie bestehen vielmehr aus individuellen, benutzerspezifischen Kombinationen von Dienstaufrufen, die h¨aufig sogar ad hoc zusammengestellt werden. Als Folge dieser Individualisierung werden solche Anwendungsprozesse nur einmal (oder einige wenige Male) instanziert. Wir sprechen hier daher von Adhoc-Prozessen. Solche finden sich in verschiedenen Bereichen, so unter anderem auch im Gesundheitswesen (beispielsweise in Krankenhausinformationssystemen [Rei00]). Sie ∗ Teile

der Arbeit wurden durch den Schweizer Nationalfond im Rahmen des Projektes MAGIC gef¨ordert.

55

zeichnen sich dadurch aus, dass es zwar standardisierte Prozessmuster gibt, trotzdem aber die M¨oglichkeit, diese Muster individuell anzupassen, entscheidend ist. Dabei kann die Systemkonfiguration einschließlich der Dienstanbietern (oft) als statisch angesehen werden. Mit der zunehmenden Verkn¨upfung von Informationssystemen muss aber immer o¨ fter auch die Dynamik der zugrunde liegenden Infrastruktur ber¨ucksichtigt werden. Neue Dienstanbieter k¨onnen hinzukommen, existierende Anbieter weitere Dienste anbieten beziehungsweise existierende modifizieren. Solche Ver¨anderungen erfordern eine flexible Prozessausf¨uhrung, welche die aktuell verf¨ugbaren Dienste ber¨ucksichtigt. Traditionelle Infrastrukturen zur Prozessausf¨uhrung bestehen aus einer zentralen Workflow-Engine. Bei dieser Engine sind die Prozessbeschreibungen hinterlegt, so dass sie die Prozessausf¨uhrung komplett steuern kann, wie dies zum Beispiel bei MQSeries [MQS03] geschieht. Aufgrund der Verteilung und Heterogenit¨at der Dienstanbieter und der Dynamik von Ad-hoc-Prozessen sind solche zentralisierten Ans¨atze nicht optimal. Neuere Entwicklungen hin zu verteilten Infrastrukturen zur Prozessverwaltung sind darauf ausgerichtet, standardisierte Prozesse mit hoher Wiederholfrequenz – nicht jedoch individuelle Ad-hoc Prozesse – korrekt und m¨oglichst effizient auszuf¨uhren. In diesen Systemen werden die jeweiligen Komponenten (Peers) des Informationssystems, die Teile eines Prozesses ausf¨uhren (k¨onnen), mit vordefinierten Prozessbeschreibungen und sonstigen Metadaten (optimal) konfiguriert [SSSW02]. Insbesondere m¨ussen diese Peers die nachfolgenden Aktivit¨aten eines Prozesses kennen. Kommen neue Anwendungsprozesse in das System, erfolgt eine dynamische Rekonfiguration, indem die Prozessbeschreibung mit den zugeh¨origen Metadaten auf den betroffenen Peers verteilt bzw. repliziert wird. Der mit der Replikation verbundene Aufwand zahlt sich dann nicht mehr aus, wenn ein Prozess eingerichtet wird, der nur einmal bzw. einige wenige Male instanziert wird. Daher bietet es sich bei Ad-hoc-Prozessen an, die Prozessbeschreibung mit der Prozessinstanz durch das Netzwerk wandern zu lassen. Dienstaufrufe bzw. Prozessschritte werden dazu direkt lokal ausgef¨uhrt. Da in diesem Fall die jeweiligen Peers nicht vorkonfiguriert werden k¨onnen (da a priori noch nicht bekannt ist, wie ein Ad-hoc-Prozess spezifiziert ist), m¨ussen alle f¨ur den Dienstaufruf ben¨otigten Informationen zusammen mit der Prozessbeschreibung zum Dienstanbieter geschickt werden. Die Infrastruktur muss lediglich die Funktionalit¨at f¨ur die verl¨assliche Ausf¨uhrung von Ad-hoc-Prozessen bereitstellen. Dazu geh¨oren Basisroutinen zur Koordination von Ad-hoc-Prozessen ebenso wie spezielle Fehlerbehandlungsmechanismen. Diese Mechanismen m¨ussen ber¨ucksichtigen, dass sich Dienstanbieter tempor¨ar bewusst abmelden oder unbewusst ausfallen k¨onnen. In diesem Papier skizzieren wir die Architektur einer Infrastruktur, wie sie im AMORProjekt (Agents, MObility, tRansactions) f¨ur die Ausf¨uhrung und Fehlerbehandlung von Ad-hoc-Prozessen eingesetzt wird. Technisch gesehen werden Ad-hoc-Prozesse als mobile Agenten realisiert, die von Peer zu Peer migrieren, um einen Ad-hoc-Prozess auszuf¨uhren. Die AMOR-Infrastruktur unterst¨utzt die Intra-Prozessparallelit¨at durch das Klonen von Agenten. Damit k¨onnen mehrere Klone gleichzeitig auf verschiedenen Peers Dienste in Anspruch nehmen und somit den Gesamtprozess parallel und unabh¨angig vorantreiben. Alle Agenten werden hierzu mit einer zus¨atzlichen Funktionalit¨at ausgestattet. Diese erm¨oglicht es den Agenten, eine korrekte Synchronisation ohne einen zentralen Koordinator durchzuf¨uhren. Mit anderen Worten realisieren wir eine vollst¨andig dezentrali-

56

sierte Prozessverwaltung, welche trotzdem eine korrekte Ausf¨uhrung sicher stellt, indem sie transaktionale Ausf¨uhrungsgarantien gew¨ahrleistet. Dieser Beitrag ist wie folgt gegliedert: Kapitel 2 skizziert die Spezifikation von Ad-hocProzessen und m¨ogliche Fehler bei der Ausf¨uhrung solcher Prozesse. Kapitel 3 erl¨autert die Ausf¨uhrung von Ad-hoc-Prozessen einschließlich der ben¨otigten Infrastruktur. Die Fehlerbehandlung wird separat in Kapitel 4 behandelt. Verwandte Arbeiten werden in Kapitel 5 diskutiert. Kapitel 6 beschließt dieses Papier mit einer Zusammenfassung und geht auf aktuelle und geplante Erweiterungen der pr¨asentierten Infrastruktur ein.

2 2.1

Ad-hoc-Prozesse Spezifikation

Ad-hoc-Prozesse bestehen aus einer Menge von Schritten. Wie Abbildung 1 zeigt, gibt es verschiedene Arten von Schritten: Aktivit¨aten, Verzweigungen und Synchronisationsschritte. Auf diesen Schritten ist eine partielle Ordnung definiert, das heißt verschiedene Schritte bzw. Prozesspfade k¨onnen als parallel ausf¨uhrbar spezifiziert werden, was durch Parallelit¨atsschritte explizit modelliert wird. Dies setzt nat¨urlich voraus, dass kein Informationsfluss zwischen den Pfaden stattfindet. Schritt {abstract}

Aktivität

Verzweigung

{abstract}

{abstract}

Benutzeraktivität

Dienstaktivität

Join-Schritt (Synchronisation)

Fork-Schritt (AND)

Alternativ-Schritt (OR)

Abbildung 1: Arten von Prozessschritten

Abbildung 2 enth¨alt einen einfachen Beispielprozess, welcher mittels weiteren Aktivit¨aten zu einem Ad-hoc-Prozess erweitert werden kann. Die Prozessdefinition legt fest, wie auf einen ankommenden Notfallpatienten im Krankenhaus reagiert wird. Im ersten Schritt werden die Patientendaten aufgenommen. F¨ur solche Benutzerinteraktionen steht der Typ Benutzeraktivit¨at zur Verf¨ugung. Aktivit¨aten dienen dazu, den System- oder Prozesszustand zu ver¨andern. Die zweite Aktivit¨atsart stellen die Dienstaktivit¨aten dar. Diese bieten Anwendungsdienste an, beispielsweise das Speichern der eingegebenen Patientendaten im Krankenhausinformationssystem. Neben solchen einfachen Diensten werden auch komplexere unterst¨utzt, die mehrere Kommunikationsschritte/-phasen enthalten. Ein spezieller Dienst muss aber nicht der Einzige seiner Art im System sein. Es k¨onnen

57

Benutzeraktivität Eingabe Patientendaten Dienstaktivität Speichere Patientendaten im Krankenhausinformationssytem

Alternativ-Schritt

Fork-Schritt Dienstaktivität Operationsteam reservieren

Dienstaktivität Operationsraum reservieren

Dienstaktivität Zu anderem Krankenhaus verlegen

Join-Schritt Benutzeraktivität Eingabe Operationsverlauf Dienstaktivität Rechnung erstellen

Abbildung 2: Spezifikation eines Ad-hoc-Prozesses

auch weitere, semantisch a¨ quivalente Dienste existieren (von der Ontologienproblematik wollen wir hier abstrahieren). So bieten zum Beispiel alle Krankenh¨auser einen a¨ quivalenten Dienst ’Operationsteam reservieren’ an. Da verschiedene Krankenh¨auser unterschiedliche Spezialisten haben, kann das Ergebnis bei diesen Dienstaufrufen auch unterschiedlich sein. Daher kann in der Prozessspezifikation angegeben werden, ob und gegebenenfalls wie viele verschiedene Dienste gleichzeitig (durch verschiedene Agentenklone) kontaktiert werden sollen, um die Anwendungsbed¨urfnisse optimal zu erf¨ullen. Die dadurch entstehende Parallelit¨at bezeichnen wir als Dienstparallelit¨at. Eine zweite Art von Parallelit¨at ist die Prozessparallelit¨at, die durch Fork- und JoinSchritte spezifiziert wird. Nur Fork-Schritte d¨urfen mehrere ausgehende, parallel auszuf¨uhrende Aktionen haben. Sie erm¨oglichen es in unserem Beispiel, parallel nach einem Operationsraum und einem Operationsteam zu suchen. Bei der Prozessparallelit¨at m¨ussen alle Pfade erfolgreich ausgef¨uhrt werden, w¨ahrend bei Dienstparallelit¨at nur mindestens einer der Pfade erfolgreich sein muss. Verzweigungspunkte erlauben es, alternative Ausf¨uhrungspfade zu spezifizieren. Diese k¨onnen verwendet werden, falls die Ausf¨uhrung eines Pfades fehlschl¨agt. Falls in unserem Beispiel der Notfallpatient mangels Verf¨ugbarkeit von Team und R¨aumlichkeiten nicht

58

behandelt werden kann, wird er in ein anderes Krankenhaus verwiesen. Die Reihenfolge, in welcher diese Varianten versucht werden, kann dabei statisch definiert sein oder aber der Prozess entscheidet bei der Ausf¨uhrung des Verzweigungspunktes aufgrund des Prozesszustandes, welche Variante er w¨ahlt.

2.2

Fehlerf¨alle

Bei der Ausf¨uhrung von Prozessinstanzen k¨onnen zur Laufzeit verschiedene Fehler auftreten. Im Folgenden klassifizieren wir die Fehler danach, ob sie durch das Laufzeitmodell des AMOR-Systems abgefangen werden k¨onnen/sollen oder ob sie Wissen u¨ ber die Anwendungssemantik erfordern und daher auf der Ebene der Prozessspezifikation zu behan¨ deln sind. Einen ersten Uberblick hierzu liefert Tabelle 1. Fehlerart Dienstfehler Providerfehler Ausf¨uhrungsmodellbedingte Fehler Isolationsverletzung Infrastrukturfehler

Behandlung . . . durch die Prozessspezifikation . . . transparent durch das System

Tabelle 1: Fehlerklassifikation und Zust¨andigkeiten f¨ur Fehlerbehandlung

Infrastrukturfehler sind transparent vom System zu behandeln. Beispiele f¨ur solche Fehler sind ungeplante Unterbrechungen (nicht aber geplante, da diese im Ausf¨uhrungsmodell ber¨ucksichtigt werden k¨onnen) in Folge von Netzwerkfehlern. Auch der Absturz eines Agenten geh¨ort zu dieser Fehlerklasse. Daneben gibt es Fehler, die auftreten k¨onnen, wenn mehrere Prozesse gleichzeitig aktiv sind. Auch wenn die einzelnen Prozesse erfolgreich ihre Aktivit¨aten ausf¨uhren, k¨onnen sie derart interferieren, dass sie das gew¨ahlte Concurrency-Control-Korrektheitskriterium verletzen (Isolationsverletzung). In unserem System verwenden wir das Korrektheitskriterium Konfliktserialisierbarkeit [BHG87].1 Eine Isolationsverletzung liegt vor, wenn der Serialisierungsgraph einen Zyklus enth¨alt. In diesem Fall muss das System verhindern, dass die in den Zyklus involvierten Prozesse (scheinbar) erfolgreich terminieren. Hierzu signalisiert das System eine Isolationsverletzung. Ferner gibt es Fehler, die auf das Ausf¨uhrungsmodell zur¨uckzuf¨uhren sind. Bei zentralisierten Workflow-Engines reduziert sich diese Frage darauf, wie das Recovery bei einem Absturz der Workflow-Engine durchgef¨uhrt wird. Falls man aber Workflows dezentral ausf¨uhrt, so wie in unserem Fall, kann ein Ausf¨uhrungspfad (ein Agent) ’verschwinden’. Hier muss das Ausf¨uhrungsmodell garantieren, dass das ganze System wieder in einen konsistenten Zustand u¨ berf¨uhrt wird. Allen bisher diskutierten Fehlern ist gemeinsam, dass ihr Auftreten in keinem direkten 1 Genauer handelt es sich um Konfliktserialisierbarkeit im Zusammenhang mit semantisch reichen Operationen [VHBS98].

59

Zusammenhang mit der Anwendungssemantik steht. Weder der Anwendungsentwickler bei der Programmierung noch der Anwender zur Laufzeit sollten sich daher mit solchen Fehlern auseinander setzen m¨ussen. Außerdem muss das Ausf¨uhrungsmodell sicherstellen, dass es mit diesen Fehlern umgehen kann – und wenn m¨oglich nicht die Prozessausf¨uhrung abgebrochen wird. Da das Ausf¨uhrungsmodell unabh¨angig von der genauen Anwendungssemantik ist, kann es keine Fehler l¨osen, die im Zusammenhang mit der Anwendungssemantik stehen. Stattdessen muss die Prozessspezifikation festlegen, wie mit Fehlern umzugehen ist. Diese Fehler k¨onnen wir in zwei Klassen einteilen: Dienst- und Providerfehler. Beide treten nur im Zusammenhang mit der Ausf¨uhrung von Dienstaktivit¨aten auf. Bei einem Providerfehler kann kein Anbieter f¨ur einen bestimmten Dienst gefunden werden. In unserem Krankenhausbeispiel k¨onnte es im Zusammenhang mit der Verlegung eines Kranken sein, dass – zum Beispiel wegen einer Netzwerkpartitionierung – kein anderes Krankenhaus gefunden wird. Bei Dienstfehlern wird zwar ein Dienstanbieter gefunden, allerdings kann dabei das durch die Anwendungssemantik erforderliche Ziel nicht erreicht werden. So w¨urde bei unserem Beispielprozess zwar ein Anbieter f¨ur den Dienst ’Operationsteam reservieren’ gefunden, allerdings sind bereits alle passenden Teams ausgebucht. An diesem Beispiel wird auch deutlich, weshalb die Unterscheidung zwischen Providerund Dienstfehlern sinnvoll ist: Im letztgenannten Fall k¨onnten die Kriterien aufgeweicht ¨ werden (’lieber ein unerfahrenes Arzteteam nehmen als eine dringend notwendige Operation zu verschieben oder ausfallen zu lassen’), w¨ahrend eine solche Aufweichung der Kriterien nicht sinnvoll ist, wenn man u¨ berhaupt keine Dienstanbieter findet.

3 3.1

¨ Ausfuhrung von Ad-hoc-Prozessen im AMOR-System Systemarchitektur

Unsere Systemarchitektur (siehe Abbildung 3) basiert auf einem Peer-to-Peer-Netzwerk. Die Peers stellen die eigentlichen Dienstanbieter, wie zum Beispiel medizinische Infor¨ mationssysteme oder Patientendatenbanken niedergelassener Arzte, dar. Die Dienste der einzelnen Peers werden von Ad-hoc-Prozessen genutzt. Eine Aufgabe der Peers ist es, eine einheitliche Schnittstelle anzubieten, um von der Komplexit¨at und Heterogenit¨at der darunter liegenden Datenquellen zu abstrahieren. Dies geschieht mit der Dienstorientierung. Die Peers verbergen mit Hilfe von Diensten beispielsweise, ob die Abrechnung in einem Krankenhaus mittels SAP oder mit einem anderen Produkt realisiert wird. Auf jedem Peer befindet sich eine lokale Koordinationsschicht, die unter anderem Metadaten zur aktuellen Systemkonfiguration speichert. Das Dienstrepository verwaltet Informationen u¨ ber die lokal verf¨ugbaren Dienste. Das Netzwerkrepository hingegen notiert die Verbindungen zu anderen Peers im Netzwerk. Beide Repositories zusammen erlauben es den Prozessen, Dienste sowohl lokal als auch auf anderen Peers zu finden [HS01]. Zur Beschleunigung solcher Suchvorg¨ange besteht die M¨oglichkeit, Informationen u¨ ber Dienste auf anderen Peers zwischenzuspeichern und damit bei sich oft wiederholenden Anfragen einen deutlichen Geschwindigkeitsgewinn zu erzielen. In statischen Konfigurationen w¨are dieser Ansatz identisch mit einem (replizierten) Yellow-Pages-Ansatz.

60

Ad-hoc-Prozess Ad-hoc-Prozess Ad-hoc-Prozess Zustand

Ad-hoc-Prozess Ad-hoc-Prozess Ad-hoc-Prozess Zustand

Definition

Definition

Aktive Aktivitäten:

Aktive Aktivitäten:

Variablenbelegung: {destination="Zürich"}

Variablenbelegung: {destination="Zürich"}

Prozess-Koordinationsschicht Prozess-HDB-Schicht Prozess-HDB-Schicht Aktivitäts Dienste Prozess

Prozess Board

Peer

Board

Querying

Prozess-Koordinationsschicht Prozess-HDB-Schicht Prozess-HDB-Schicht Dienste Aktivitäts Prozess

Prozess Sync

Sync

Lokale Koordinationsschicht

Lokale K.-Schicht

Dienste Netzwerk Prozess Rep. Rep. Sync

DR NR PSync

Dienste

Dienste

Querying

Board

Lokale K.-Schicht

...

Peer

Board

DR NR PSync

Dienste

Peer

Abbildung 3: Aufbau des AMOR-Systems

Das Dienstrepository wird also f¨ur die Realisierung der Querying-Funktionalit¨at durch die Dienste-Querying-Komponente der Ad-hoc-Prozessinstanzen verwendet. Diese Komponente kontaktiert die lokale Koordinationsschicht, wenn ein Dienstanbieter ben¨otigt wird. Damit muss der Ad-hoc-Prozess u¨ ber die Prozessbeschreibungen verf¨ugen, um einen passenden Dienstanbieter suchen lassen zu k¨onnen. Weiterhin verwaltet jeder Prozess seinen aktuellen Ausf¨uhrungszustand. Dies erm¨oglicht der Prozesskoordinationsschicht, die eigentliche Prozessausf¨uhrung zu steuern. Hierzu verwendet die Koordinationsschicht noch weitere, spezialisierte Komponenten, wie beispielsweise ein Prozessboard. Ein Prozessboard verwaltet eine Menge an Objekten, die u¨ ber ihre Namen adressiert werden. Damit realisiert das Prozessboard den Informationsfluss zwischen verschiedenen – unter Umst¨anden auch parallelen – Schritten eines Prozesses, da jeder Schritt neue Eintr¨age (Instanzvariablen) in das Prozessboard veranlassen bzw. lesend oder schreibend auf diese zugreifen kann. Sichtbar sind diese Prozessboardeintr¨age allerdings nur innerhalb einer Prozessinstanz. Im Falle der Dienstparallelit¨at klonen sich die mobilen Agenten. Danach k¨onnen die jeweiligen Klone semantisch a¨ quivalente Dienste verschiedener Peers aufrufen. Sp¨ater synchronisieren sich diese Klone u¨ ber ihre Aktivit¨atsboards. Der Aufbau eines Aktivit¨atsboards ist a¨ quivalent zu dem eines Prozessboards. Ein Aktivit¨atsboard enth¨alt eine Menge an Objekten, deren Sichtbarkeit allerdings auf die Klone genau einer Aktivit¨at beschr¨ankt ist. Innerhalb der Aktivit¨aten gleichen die verschiedenen Klone ihre Eintr¨age an Synchronisationspunkten ab. Damit wird es zum Beispiel m¨oglich, das bestqualifizierte Operationsteam zu reservieren. Hierzu w¨urden im ersten Teil der Dienstaktivit¨at die verschiedenen

61

Peers kontaktiert. Anschließend w¨urden dann – sofort oder bei Netzwerkunterbrechungen verz¨ogert – die einzelnen Klone ihre Informationen austauschen, so dass anschließend die Reservierung des am besten geeigneten Operationsteams erfolgen kann. Sowohl die Peers als auch die Ad-hoc-Prozessinstanzen sind mit Prozesssynchronisationskomponenten ausgestattet. Diese realisieren die Isolationseigenschaft mittels eines verteilten Transaktionsprotokolls2 , das korrekte parallele Abl¨aufe garantiert. Sobald eine Isolationsverletzung erkannt wird, wird den beteiligten Ad-hoc-Prozessinstanzen signalisiert, welche Schritte zur Behandlung dieses Fehlers zur¨uckzusetzen sind.

3.2

¨ Ausfuhrung von Schritten

Wie bereits erkl¨art, k¨onnen Aktivit¨aten auf das Prozessboard und auf die Dienste verschiedener Peers zugreifen. Ist in der Prozessspezifikation angegeben, dass Dienstparallelit¨at gew¨unscht ist – also gleichzeitig mehrere semantisch a¨ quivalente Dienste genutzt werden sollen – repliziert sich die Prozessinstanz. Hierzu klont sich der entsprechende Agent. Jeder dieser Klone migriert dann zu dem von ihm zu kontaktierenden Peer. Da in einem dynamischen Peer-to-Peer-Netzwerk die aktuelle Verf¨ugbarkeit der einzelnen Peers nicht zum Programmierzeitpunkt bekannt ist, m¨ussen die Peers (genauer die Dienste) zur Laufzeit gesucht werden. Hierzu kontaktiert die Prozessinstanz die lokale Koordinationsschicht des jeweiligen Peers, auf dem sie sich gerade befindet. Die lokale Schicht u¨ berpr¨uft daraufhin ihr Dienstrepository nach den auf diesem Peer verf¨ugbaren Diensten und leitet die Anfrage gegebenenfalls an andere Peers weiter. Die bei Aktivit¨aten angewandte Technik, Parallelit¨at mittels Klonen zu realisieren, wird ebenfalls bei der Ausf¨uhrung von Fork-Schritten – also bei Prozessparallelit¨at – angewendet. Bei der Ausf¨uhrung eines solchen Fork-Schrittes wird f¨ur jeden ausgehenden Prozesspfad ein Klon erzeugt, so dass die Prozesspfade parallel und unabh¨angig voneinander ausgef¨uhrt werden k¨onnen. Jeder Klon verf¨ugt hierbei u¨ ber eine Kopie des Aktivit¨ats- und des Prozessboards. Damit k¨onnen sie im Falle von vor¨ubergehenden Netzwerkunterbrechungen weiterarbeiten. Das System stellt f¨ur den Programmierer transparent sicher, dass trotzdem keine Inkonsistenzen auftreten. Falls diese Klone dann den korrespondierenden Join-Schritt erreichen, synchronisieren sie sich wieder und w¨ahlen genau einen Klon aus, der ihren Ausf¨uhrungspfad weiter ausf¨uhren soll. Alle anderen Klone hingegen terminieren. Ein Benutzerinteraktionsschritt erm¨oglicht die Interaktion zwischen Anwender und mobilen Agenten w¨ahrend der Prozessausf¨uhrung. Um dem Benutzer Zwischenergebnisse der bisherigen Prozessausf¨uhrung pr¨asentieren zu k¨onnen, greifen Benutzerinteraktionsschritte auf die Prozessboardeintr¨age zu. Daneben ist auch ein schreibender Zugriff m¨oglich. Damit kann eine Prozessinstanz die Ergebnisse der bisherigen Prozessausf¨uhrung dem Anwender mitteilen. Andererseits kann ein Benutzerinteraktionsschritt auch schreibend auf das Prozessboard zugreifen. Dies erm¨oglicht dem Benutzer, Daten dem Prozess mitzuteilen, unter anderem um unter verschiedenen Optionen zu w¨ahlen. Falls beispielsweise verschiedene Operationsteams zur Verf¨ugung stehen, k¨onnte der Anwender den operie2 Genauere

Informationen hierzu finden sich in [HS03].

62

renden Arzt seines Vertrauens ausw¨ahlen. Ein weiterer Aspekt ist bei der Interaktion mit einem Benutzer zu beachten. Ein Benutzer verwendet nicht immer den gleichen Rechner, sondern verf¨ugt beispielsweise u¨ ber einen Rechner im B¨uro und einen PDA, mit dem er auf dem Arbeitsweg zu erreichen ist. Jeder dieser Rechner verf¨ugt u¨ ber die Information, welcher Benutzer gerade eingeloggt ist. Daher kann ein Benutzerinteraktionsschritt zum Ausf¨uhrungszeitpunkt ermitteln, wo sich der Anwender befindet, der informiert werden soll beziehungsweise von dem Angaben ben¨otigt werden. Daraufhin migriert der Agent zu dem entsprechenden Peer.

4

Fehlerbehandlung

Die Fehlerbehandlung des AMOR-Systems zeichnet aus, dass sie dezentral realisiert ist und flexibel auf die verschiedenen Fehlersituationen eingeht. In Fehlersituationen wird nur partiell zur¨uckgesetzt, also nur soweit, wie es notwendig ist, um den Fehler zu beheben. Anschließend wird die Ausf¨uhrung mit einem alternativen Pfad (falls vorhanden) fortgesetzt. Anders als bei klassischen Datenbanktransaktionen u¨ blich, wird somit der Prozess nur in Ausnahmef¨allen vollst¨andig zur¨uckgesetzt. Prozess 1

Prozess 2 Benutzerinteraktionsschritt Eingabe Patientendaten

Ausführungsschritt Lese Reservierung für Operationssaal

A

Auführungsschritt

Fork-Schritt

Speichere Patientendaten im B Krankenhausinformationssytem

1

Alternativen-Schritt

Fork-Schritt Ausführungsschritt Operationsraum reservieren

C

Ausführungsschritt Operationsteam reservieren

X

Ausführungsschritt 2 Lese Patientendaten

Y

Ausführungsschritt Transportiere ersten Patient Z in Operationssaal

2 Benutzerinteraktionsschritt Alternative Krankenhäuser auswählen

F

Ausführungsschritt Zu anderem Krankenhaus verlegen

E

D

1: P1 3: P2

Konflikt

Abbildung 4: Beispiel f¨ur das R¨ucksetzen

Abbildung 4 dient als Illustration f¨ur das partielle R¨ucksetzen. Das erweiterte Beispielszenario besteht aus einem Peer und zwei Prozessen. Prozess 1 entspricht dem Beispielprozess in Abbildung 2. Prozess 1 hat gerade die Schritte C und D erfolgreich ausf¨uhrt, w¨ahrend Prozess 2 die Schritte Y und Z ebenso erfolgreich beendet hat. Beide Prozesse haben dabei jeweils einmal einen Dienst auf dem Peer aufgerufen, wobei beide Dienstaufrufe in Konflikt zueinander stehen. Wir nehmen nun an, dass die Ausf¨uhrung des entsprechenden Klons nach Schritt C scheitert. Bei einem einfachen Transaktionsmodell w¨urde dies bedeuten, dass Prozess 1 ganz zur¨uckzusetzen ist (was nat¨urlich in dem Anwendungskontext keinen Sinn macht). Da aber Prozess 2 nach Prozess 1 eine konfligierende Aktion auf diesem Peer ausgef¨uhrt hat, w¨are auch Prozess 2 (vollst¨andig) zur¨uckzusetzen. Durch die Einf¨uhrung von Alternativpfaden [SABS02] verhindern wir einen Teil der Pro-

63

bleme. So wird in unserem Fall ausgeschlossen, dass Prozess 1 nach den Schritten C und D auch die Schritte A und B zur¨ucksetzt. Stattdessen kann Prozess 1 die Ausf¨uhrung mit Schritt F fortsetzen. Trotzdem w¨are es immer noch erforderlich, Prozess 2 vollst¨andig zur¨uckzusetzen. Um dies zu vermeiden, k¨onnte Schritt Y zur¨uckgesetzt und sp¨ater wieder neu ausgef¨uhrt werden. W¨ahrend dieser Unterschied auf den ersten Blick vernachl¨assigbar erscheint, a¨ ndert sich die Situation, wenn man folgende Aspekte ber¨ucksichtigt: 1. Die Prozesse k¨onnen komplex sein und gleichzeitig viele Schritte enthalten und damit viele Peers in Anspruch nehmen. 2. Einzelne Schritte k¨onnen l¨angere Zeit zur Ausf¨uhrung ben¨otigen, entweder weil sie Benutzerinteraktionen beinhalten oder rechenintensiv sind. 3. Ein Benutzer sollte m¨oglichst nur dann eine Eingabemaske ein weiteres Mal pr¨asentiert bekommen, wenn sich die dort dargestellte Information ver¨andert hat, etwa wenn ein von ihm gew¨ahltes Operationsteam auf einmal doch nicht verf¨ugbar ist.

4.1

¨ Ermitteln der Rucksetzmenge

Die theoretische Grundlage f¨ur die Ermittlung der R¨ucksetzmenge liefert die Unified Theory for Concurrency Control and Recovery [VHBS98], welche das Korrekheitkriterium Serializability with ordered termination (SOT) definiert. Dieses Kriterium ber¨ucksichtigt gleichzeitig Concurrency Control und Recovery – gerade auch f¨ur semantisch reiche Operationen. Wir verwenden dieses Kriterium, um im Fehlerfall zu ermitteln, welche Dienstaufrufe kaskadierend aufgrund von Konflikten zwischen Dienstaufrufen zur¨uckzusetzen und in welcher Reihenfolge hierzu inverse Dienste aufzurufen sind. Wie bereits erl¨autert, beschr¨anken wir hier die Diskussion auf einige Fehlerarten: Provider- und Dienstfehler sowie Isolationsverletzungen. ¨ Initiale Rucksetzgrenze. Die initiale R¨ucksetzgrenze gibt an, wie weit ein Prozess mindestens zur¨uckgesetzt werden muss, um einen vorliegenden Fehler zu beheben. Diese Grenze wird zu Beginn der Recovery-Phase ermittelt und ist abh¨angig von der Art des aufgetretenen Fehlers. Wie bereits vorher erl¨autert, m¨ussen Provider- und Dienstfehler durch die Prozessspezifikation abgedeckt werden. Eine solche Spezifikationsm¨oglichkeit stellen die Verzweigungspunkte dar. Falls die Ausf¨uhrung scheitert, so wird so weit zur¨uckgesetzt, bis ein solcher Verzweigungspunkt gefunden wird, der u¨ ber einen noch unversuchten Alternativpfad verf¨ugt. Nur falls kein solcher Pfad gefunden wird, scheitert die Prozessausf¨uhrung endg¨ultig. In unserem Beispiel in Abbildung 4 ist der Verzweigungspunkt der initiale R¨ucksetzschritt. Dieser Ansatz reflektiert, dass es in unserem Beispiel kaum sinnvoll ist, endlos nach einem Operationsteam zu suchen, sondern dass irgendwann eine andere L¨osung gefunden, n¨amlich der Patient verlegt werden muss. Neben den explizit im Prozess sichtbaren Alternativen k¨onnen auch Benutzerinteraktionsaktivit¨aten Alternativen bieten, n¨amlich dann, wenn der Benutzer eine Auswahl getroffen hat, die letztlich f¨ur das sp¨atere Scheitern der Ausf¨uhrung verantwortlich war. Falls ein

64

Patient verlegt werden soll und das ausgew¨ahlte, bestgeeignete Krankenhaus ihn nicht aufnehmen kann, k¨onnte der Benutzer weitere (weniger geeignete) Krankenh¨auser zulassen. Somit sind beim Ermitteln der initialen R¨ucksetzgrenze Benutzerinteraktionsschritte (unter der Voraussetzung, dass der Benutzer dort eine Wahl treffen konnte) genauso wie Verzweigungspunkte zu behandeln. Zus¨atzlich muss dem Benutzer zur Laufzeit erkl¨art werden, weshalb er noch einmal eine (andere) Wahl treffen soll. Bei einer Isolationsverletzung sieht die Situation anders aus. Die Ausf¨uhrung der einzelnen Prozesse ist zwar isoliert gesehen erfolgreich, allerdings gibt es gesamthaft Wechselwirkungen und Abh¨angigkeiten zwischen den Prozessen, die zu einem nicht-serialisierbaren – und damit inkorrekten – Ablauf f¨uhren. Dies ist in unserem Ansatz immer dann der Fall, wenn als Konsequenz des optimistischen Concurrency-Control-Ansatzes ein Zyklus im Serialisierungsgraphen entsteht. In diesem Fall muss man durch Kompensation der ausgef¨uhrten Schritte so weit zur¨uckzusetzen, bis die Isolationseigenschaft wieder hergestellt wird. Ein solches R¨ucksetzen kann durch einen Agenten ausgel¨ost werden, wenn er selbst feststellt, zur¨ucksetzen zu m¨ussen. Es kann aber auch sein, dass ein anderer Agent diese Notwendigkeit zuerst erkennt und Ersteren dar¨uber informiert. ¨ Transitive Rucksetzschritte. Zum Beheben von Fehlern kann es notwendig sein, dass transitiv mehrere Schritte kompensiert werden m¨ussen. Diese nennen wir transitive R¨ucksetzschritte. F¨ur ihre Ermittlung ist es unwesentlich, welcher Fehler das Zur¨ucksetzen ausgel¨ost hat. Als transitive prozessinterne R¨ucksetzschritte bezeichnen wir die Schritte, die innerhalb des r¨ucksetzenden Prozesses kompensiert werden m¨ussen, um sicherzustellen, dass der Prozess entsprechend der Spezifikation ausgef¨uhrt wird. So sind parallele Schritte auch dann zur¨uckzusetzen, falls die R¨ucksetzschranke vor dem korrespondierenden ForkSchritt liegt. Falls in unserem Beispiel das Reservieren eines Operationssaals scheitert, reicht es nicht einfach aus, nur den Schritt ’Patient verlegen’ auszuf¨uhren. Zus¨atzlich muss der Schritt ’Operationsteam reservieren’ kompensiert werden. Als zweiter Grund f¨ur das transitive R¨ucksetzen kommen andere Prozesse in Frage. Die daraufhin zur¨uckzusetzenden Aktivit¨aten bezeichnen wir als transitive prozess¨ubergreifende R¨ucksetzschritte. Sei aR eine zur¨uckzusetzende Aktivit¨at. Unter der Annahme, dass genau dann, wenn Aktivit¨at a im Konflikt zu b steht, auch die inverse Operation a−1 mit b konfligiert, muss eine Aktivit¨at a0 vorher zur¨uckgesetzt werden, falls ar und a0 im Konflikt stehen und aR < a0 gilt. Falls also in Abbildung 4 der Schritt B von Prozess 1 kompensiert wird, so muss auch Schritt Y von Prozess 2 zur¨uckgesetzt werden.3 F¨ur die transitiven R¨ucksetzschritte gilt, dass die Regeln zur Ermittlung von transitiven R¨ucksetzschritten unter Umst¨anden mehrfach angewendet werden m¨ussen. 3 Voraussetzung hierf¨ ur ist, dass alle Agenten u¨ ber einen erweiterten Serialisierungsgraphen verf¨ugen. In diesem ist jede Kante mit der/den Aktion/en annotiert, welche die Kante(n) verursacht hat/haben. In dem Beispiel in Abbildung 4 w¨urde Prozess 1 Prozess 2 informieren, dass Letzterer eine Kante zur¨uckzunehmen hat. Prozess 2 schaut dann in seinem Serialisierungsgraphen nach und stellt fest, dass eben Schritt Y die Kante verursacht hat und somit Y die (lokale) initiale R¨ucksetzgrenze ist.

65

4.2

¨ Rucksetzen

Nachdem die Menge der zu kompensierenden Schritte (vorl¨aufig) ermittelt ist, kann das eigentliche R¨ucksetzen beginnen. Das R¨ucksetzen verl¨auft sehr a¨ hnlich zur Vorw¨artsausf¨uhrung: Falls eine Dienstaktivit¨at zur¨uckgesetzt wird, die auf verschiedenen Peers ausgef¨uhrt wurde, so werden Klone erzeugt. Diese migrieren zu den entsprechenden Peers, um dort die Kompensationsoperationen auszuf¨uhren. Dabei kann das Problem auftreten, dass eine Operation nicht direkt kompensiert werden darf. Dies ist der Fall, falls nach der urspr¨unglichen Operation eine weitere Operation ausgef¨uhrt wurde, die mit der Kompensationsoperation in Konflikt steht. In diesem Fall muss der zur¨ucksetzende Prozess den anderen Prozess auffordern, partiell zur¨uckzusetzen und abwarten, bis dies erfolgt ist. In unserem Beispiel kann Prozess 1 also erst dann Schritt B zur¨ucksetzen, nachdem – auf seine Anforderung hin – Prozess 2 den Schritt Y kompensiert hat. Die Join-Schritte und Fork-Schritte wechseln in der Recovery-Phase ihre Funktionen: Bei einem Join-Schritt werden nun Klone gebildet, w¨ahrend bei einem Fork-Schritt die Klone aufeinander warten und schließlich verschmelzen. Bei einem Benutzerinteraktionsschritt ist der Anwender u¨ ber das R¨ucksetzen und den Grund daf¨ur aufzukl¨aren.

5

Verwandte Arbeiten

Das AMOR-Projekt ist an der Schnittstelle zwischen mobilen Agenten, Workflow-Management und Transaktionsverwaltung angesiedelt. In diesem Papier stand speziell die Systemarchitektur f¨ur die Prozessausf¨uhrung mittels mobiler Agenten und die flexible Fehlerbehandlung im Vordergrund. Besonders sind wir auf unsere flexible Fehlerbehandlungsstrategie eingegangen. Wichtige Arbeiten im Bereich Fehlerbehandlung bei Workflows sind [KR98] und [EL96]. Die letztgenannte Arbeit legt ihr Gewicht dabei weniger auf den Bereich ConcurrencyControl, sondern konzentriert sich eher auf die zuverl¨asissige Workflowausf¨uhrung. Die St¨arke dieser Arbeit liegt dabei in der Kombination einer Klassifikation von Workflowarten und von Recovery-Konzepten speziell f¨ur einzelne Workflowarten, allerdings wird keine einheitliche, gemeinsame Betrachungsweise entwickelt. Ein weiterer, entscheidender Unterschied ist das zentralistische Ausf¨uhrungsmodell, welches auch der zweiten Arbeit [KR98] zugrunde liegt. Letztere pr¨asentiert ein detailliertes Konzept, bei dem der Benutzer genau angeben kann/muss, wie weit zur¨uckzusetzen ist bzw. welche Abh¨angigkeiten innerhalb eines Prozesses speziell beim R¨ucksetzen zu beachten sind. Somit wird dort – anders als in AMOR – die Information, was zu kompensieren ist, nicht automatisch aus der Prozessbeschreibung ermittelt. Die Ausf¨uhrung von Workflows durch mobile Agenten wurde erstmalig in [CGN96] diskutiert. In dieser fr¨uhen Arbeit werden noch keine transaktionalen Garantien ber¨ucksichtigt. Diesen Aspekt ber¨ucksichtigen erst sp¨atere Arbeiten, darunter [SP98], in welcher insbesondere mittels Replikation eine fehlertolerante Ausf¨uhrung erreicht wird. W¨ahrend sich diese Arbeit eher mit dem Problem der Atomarit¨at besch¨aftigt, behandelt [SAE01] als weitere wichtige Arbeit auch Fragen der Isolation, wobei aber der Recovery-Ansatz nicht konsequent diskutiert wird.

66

Falls man nicht nur auf mobile Agenten fokussiert, sondern auch den Zugriff von nichtmobilen Agenten auf Datenbanken ber¨ucksichtigt, so ist hier [PB95] zu nennen. Die Arbeit bietet gute, abstrakte Diskussion der M¨oglichkeiten des Zugriffs auf Datenbanken durch Agenten. Ein anderer Ansatz beschreibt [CD00]. Dieses Papier behandelt, wie mehrere nicht-mobile Agenten kooperieren k¨onnen, um Transaktionen atomare auszuf¨uhren. Weiterhin ist die Arbeit von [Nag01] zu nennen. Diese Arbeit behandelt, wie die im KI-Umfeld oft eingesetzten, nicht-mobilen BDI-Agenten ausgef¨uhrt werden k¨onnen. Das Schwergewicht liegt dabei, diese ’robust’ gegen¨uber Fehlern der Umgebung zu machen. Das AMOR-System basiert auf einem Peer-to-Peer-Netzwerk. Vorangetrieben durch die Popularit¨at von File-Sharing-Anwendungen wie Gnutella [Gnu] wird auf dem Gebiet der Peer-to-Peer-Netzwerke in j¨ungster Zeit sehr intensiv geforscht. Die akademische Forschung in diesem Bereich konzentriert sich vor allem auf effiziente Zugriffsmethoden, wie zum Beispiel dem P-Grid [Abe01]. Solche Methoden sind dabei orthogonal zu der Richtung des AMOR-Projektes und k¨onnten zur Effizienzsteigerung in den Prototypen integriert werden.

6

Zusammenfassung und Ausblick

In diesem Papier haben wir erl¨autert, wie Ad-hoc-Prozesse mittels mobiler Agenten in Peer-to-Peer-Netzwerken ausgef¨uhrt werden k¨onnen. Hierzu haben wir die notwendige Infrastruktur vorgestellt. Wir sind ausf¨uhrlich auf den Aspekt der Fehlerbehandlung eingegangen, indem wir die verschiedenen potentiellen Fehlerf¨alle skizziert haben. Wesentlich dabei ist die Unterscheidung, ob ein Fehler von dem Ausf¨uhrungsmodell zu behandeln oder bei der Prozessspezifikation zu ber¨ucksichtigen ist. Das eigentliche R¨ucksetzen erfolgt partiell. W¨ahrend bei Isolationsfehlern der gleiche Ausf¨uhrungspfad erneut versucht wird, w¨ahlt das System bei Provider- oder Dienstfehlern einen alternativen Pfad. Die in diesem Papier beschriebenen Strategien f¨ur zuverl¨assige Umgebungen sind bereits im Rahmen des AMOR-Projektes der Datenbankgruppe der ETH Z¨urich implementiert. In aktuellen Arbeiten, die bereits weitgehend Eingang in unseren Prototypen gefunden haben, untersuchen wir die Auswirkungen dynamischer und unzuverl¨assiger Umgebungen. Damit beziehen wir Abst¨urze, Netzwerkpartitionierungen und auch geplante Unterbrechungen in unser Ausf¨uhrungsmodell ein. Dies wirft zun¨achst die Frage auf, wie Fehlerf¨alle, die aus solchen ungeplanten Verbindungsfehlern entstehen, entdeckt und behandelt werden k¨onnen, w¨ahrend f¨ur geplante Unterbrechungen eine erweiterte Strategie notwendig ist, da nur so bei Bedarf eine geeignete Fehlerbehandlung initiiert werden kann. Sie besteht dabei aus dem Starten eines neuen Agenten, der den begonnenen Prozess fortsetzt. Um eine potentiell doppelte Ausf¨uhrung einer Prozessinstanz zu vermeiden, muss das System ausschließen, dass ein verloren geglaubter Agent pl¨otzlich wieder auftaucht und seine Prozessausf¨uhrung fortsetzt. Um trotz all dieser potentiellen Probleme unsere Prozesse nicht nur korrekt, sondern auch m¨oglichst effizient ausf¨uhren zu k¨onnen, ber¨ucksichtigen wir daher weiterhin verschiedene Quality-of-Service-Parameter bei der Ausf¨uhrung.

67

Literatur [Abe01]

K. Aberer. P-Grid: A Self-Organizing Access Structure for P2P Information Systems. In 9th Int. Conf. on Cooperative Information Systems, Trento, Italy, 2001.

[BHG87]

P. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987.

[CD00]

Q. Chen and U. Dayal. Multi-Agent Cooperative Transactions for E-Commerce. In 7th Int. Conference on Cooperative Information Systems, Eilat, Israel, 2000.

[CGN96]

T. Cai, P. Gloor, and S. Nog. DartFlow: A Workflow Management System on the Web using Transportable Agents. Technical Report TR96-283, Dartmouth College, 1996.

[EL96]

J. Eder and W. Liebhart. Workflow Recovery. In Proceedings of the First IFCIS International Conference on Cooperative Information Systems (CoopIS’96) , Brussels, Belgium, 1996.

[Gnu]

Gnutella. http://www.gnutella.com.

[HS01]

K. Haller and H. Schuldt. Using Predicates for Specifying Targets of Migration and Messages in a Peer-to-Peer Mobile Agent Environment. In 5th Int. Conf. on Mobile Agents (MA), Atlanta, GA, 2001.

[HS03]

K. Haller and H. Schuldt. Consistent Process Execution in Peer-to-Peer Information Systems. In CAiSE’03, Velden, Austria, 2003.

[HSS03]

K. Haller, H. Schuldt, and H.-J. Schek. Transactional Peer-to-Peer Information Processing: The AMOR Approach. In 4th International Conference on Mobile Data Management, Melbourne, Australia, 2003.

[KR98]

M. Kamath and K. Ramamritham. Failure Handling and Coordinated Execution of Concurrent Workflows. In ICDE, Orlando, Florida, USA, 1998.

[MQS03]

MQSeries Workflow – Version 3, Release 3.2, 2003. IBM, International Business Machines Corporation, http://www-3.ibm.com/software/ts/mqseries/workflow/v332/ index.html.

[Nag01]

K. Nagi. Transactional Agents – Towards a Robust Multi-Agent-System, LNCS 2249. Springer, 2001.

[PB95]

E. Pitoura and B. Bhargava. A framework for providing consistent and recoverable agent-based access to heterogeneous mobile databases. SIGMOD Record, 24(3):44–49, 1995.

[Rei00]

M. Reichert. Prozessmanagement im Krankenhaus - Nutzen, Anforderungen und Visionen. das Krankenhaus, 11(92), 2000.

[SABS02] H. Schuldt, G. Alonso, C. Beeri, and H.-J. Schek. Atomicity and Isolation for Transactional Processes. ACM Transactions on Database Systems (TODS), 27(1), 2002. To appear. [SAE01]

R. Sher, Y. Aridor, and O. Etzion. Mobile Transactional Agents. In 21st Int. Conf. on Distributed Computing Systems, Phoenix, AZ, 2001.

[SP98]

A. Silva and R. Popescu-Zeletin. An Approach for Providing Mobile Agent Fault Tolerance. In 2d Int. Workshop on Mobile Agents, Stuttgart, Germany, 1998.

[SSSW02] H.-J. Schek, H. Schuldt, C. Schuler, and R. Weber. Infrastructure for Information Spaces. In Proceedings of Advances in Databases and Information Systems, 6th East European Conference, ADBIS 2002, Bratislava, Slovakia, 2002. [VHBS98] R. Vingralek, H. Hasse-Ye, Y. Breitbart, and H.-J. Schek. Unifying Concurrency Control and Recovery of Transactions with Semantically Rich Operations. Theoretical Computer Science, 190(2), 1998.

68

Asynchronous Service Discovery in Mobile Ad-hoc Networks Khaled Nagi

Birgitta König-Ries

Computer Science Department. Faculty of Engineering. Alexandria University El-Shatby, Alexandria, Egypt. [email protected]

Institute for Program Structures and Data Organization. Universität Karlsruhe. D-76128 Karlsruhe, Germany. [email protected]

Abstract: The wide availability of mobile devices equipped with wireless communication devices paves the way for building highly dynamic communities of ad-hoc networks. For an asynchronous service discovery in this environment, we suggest the use of mobile agents. Here, we concentrate on file sharing and exchanging services. We adopt a new asynchronous approach for discovering and locating these files, since the availability of files in this particular domain will change significantly over time when nodes constantly join and leave the network. In this paper, we present a typical application scenario, highlight the main components of the system architecture and discuss the technical challenges facing us while trying to port main infrastructural features of traditional database management systems to our mobile light-weight software agents.

1. Introduction Nowadays, almost all new mobile devices are equipped with wireless communication devices. A consequence of this availability is that users - moving within their enterprise or institution - can easily build highly dynamic ad-hoc networks and can exchange information and services among these devices on the basis of mutual collaboration. In large institutions with several thousands of members, e.g., students in a university or employees in a big company, the need for this informal exchange of information and digital services is born. The ideal pattern for cooperation in these situations would be similar to the Peer-To-Peer (P2P) network paradigm that originally emerged on the Internet for exchanging files (e.g., mp3 files in the music exchange community) and later digital services (e.g., web services in e-Commerce) and multi-agent systems in research labs. Common to all these P2P networks is the need for service discovery in a non-monolithic environment. This can be accomplished using centralized yellow/white pages services as in CORBA [1], FIPA [2] or completely decentralized as in Gnutella [3].

69

However, the environment of mobile ad-hoc networks differs in two important aspects from these: First, users disconnect themselves more often and remain offline for much longer times. Second, ad-hoc networks are characterized by the lack of an underlying infrastructure; thus, a centralized approach to service discovery is not feasible. Most of the work done in the area of service discovery in ad-hoc networks is to locate resources on the network, such as connectivity to a broader area network, access to printers, scanners, screen projectors, etc. This is usually done in the network layer by modifying the routing protocols [4] or is integrated in the application layer [5]. In some scenarios, such as file sharing and exchanging, it is also sufficient for them to receive the requested service in a later point in time. This requires the service discovery process to be asynchronous; a new approach for service discovery. This has also been noticed in the SOUL project [6]. There, users send off mobile agents with service requests and offers which meet in a market place, a geographic area with a high device density, negotiate there and then return to their owners. In contrast to our approach introduced below, SOUL does not combine synchronous and asynchronous service discovery and does not support complex service descriptions. The rest of the paper is organized as follows. In Section 2, we present the application scenario drawn from everyday situation facing our students. Section 3 presents our asynchronous approach for service discovery using mobile agents and highlights the advantages of using mobile agents in this scenario. The system architecture and the implementation platform are described in Section 4. A comparison of our approach with approaches, which are purely based on static DBMS on mobile devices, is highlighted in Section 5. Finally, Section 6 summarizes the paper and outlines the future work.

2. Application Scenario The following application scenario from the DIANE project [7] illustrates the need for asynchronous service discovery. Anna is a computer science student. She has to pass her database exam in a two-week’s time. That is why she is looking for solutions to all SQL exercises and unofficial summaries of lectures made by her colleagues. In this academic environment, students are willing to exchange their knowledge but there is no platform for this exchange and hence there cannot be a centralized approach for service discovery. Anna might first try a synchronous service search, i.e., she will propagate her service request in the ad-hoc network using the mechanisms provided by the DIANE platform [8]. However, it is quite likely that at any given point in time not everybody who would be able to provide some information to her will be logged on to the net. Thus, in order to obtain a full set of results, Anna should use asynchronous service discovery.

70

In our scenario, Anna is supposed to state her requirements “I need all notices about SQL lectures and exercises. Deadline: 15th of January 2003. Contact information: I am daily at the library from 14:00 to 16:00, or you can mail me the document at [email protected]”. This information is saved on her PDA and she needs to propagate it to all students she comes across in order to increase her chance of getting as many documents as possible before the exam. She would transfer this information to Bob’s PDA upon meeting him at lunch break, which, in turn, will autonomously forward this request to Allen’s and Marc’s PDA during their usual evening get-together. If Marc has a relevant document, he already has Anna’s contact information; he would send her the document. However, answering these many requests manually for people he does not know does not sound to be appealing. Marc would rather have a piece of software that handles the request, autonomously identifies the required document and then asks him for permission to send the document. If the request arrives after the 15th of January, the software will automatically remove this pending request and performs the necessary garbage collection. If it arrives before the 15th of January, it would be ready for propagation to the next PDA with the same hosting platform.

3. Asynchronous Service Discovery Using Mobile Agents A search operation, in its most general case, is composed of data about the request and the code implementing the search. For the search to be carried out, the data must be propagated through the network, whereas propagating the code is very dependent on the nature of the application. Migrating both data and code is the basic definition of mobile agents. In our work, we make use of mobile agents to propagate search requests without loss of generality. 3.1 The degree of agency Choosing the right degree of agency in the system depends on the following factors. • The non-monolithic nature of the system: Recently, more and more developers are moving away from providing large monolithic systems [9] A non-monolithic system has the following implications for our application: The power of the code performing the navigation to find the required document has to depend on the node that dispatches this request not on the nodes on the course of navigation or even the node that owns the requested documents. This promises more flexibility and a better selectivity of the search request. Moreover, different nodes on the network have heterogeneous capabilities. They have different power and storage constraints. Each node can install only the capabilities that satisfy its needs. Having a non-monolithic system means that changing the system, e.g., upgrading the search algorithm, in one node does not eventually lead to upgrading the system on all

71

nodes that are joining or even may join the network in the future. This does not pose any further constraint on nodes joining the network to install special software to exchange files with other nodes. On the other hand, it is harder to tune the overall performance of fully decentralized non-monolithic systems. •

The need for dynamic code adaptation: Mobile agents can sense their execution environment and react autonomously to its changes by adapting their code dynamically. In our application scenario agents propagate through the network changing their search plan according to the intermediate search results they find. For example, an intelligent agent may autonomously change its plan during the course of the search switching it from an exact match search to relevance search, if it suspects the presence of very relevant documents not included in the original search request. Another example would be an agent deciding to search for a distiller after finding the requested document in postscript format, only.

•

Definition of search plans: A search plan can be formulated as a partially ordered graph of simple actions. If these actions are somehow well defined and standardized, their code can be installed on all nodes, resulting in a rather monolithic system. In this case, only the graph of the search plan must be propagated as part of the data of the search request. However, for smaller search requests, developers – in our case computer science students- tend to prefer writing simple search scripts over defining declarative and rather formal search plans. This, in turn, favors a more agent-oriented approach. In our application scenario (and also all similar scenarios without a centralized instance to undertake the development and the coordination of the system), we assume that the users would tend to the latter approach.

3.2 Advantages of mobile agents Furthermore, there are several typical characteristics of the mobile agent paradigm that make it most appealing for this application environment. •

Mobility: we use code migration to overcome the continuous disconnections in the ad-hoc network. In this application scenario, being connected to a neighboring PDA occurs for short periods followed by long disconnections.

•

Agent cloning: together with code migration, agent cloning enables the user to discover this virtual ad-hoc network in an asynchronous manner.

•

Persistence: mobile devices have a severe physical limitation, which is their sparse power supply. In order to save power, they are in hibernating mode for long period of times. The persistence and self-invocation nature of mobile agents enable them to overcome this limitation autonomously.

•

Decentralization: Mobile agents are by nature decentralized and do not rely on a central device or an infrastructural component as every agent is treated in the same way.

72

•

Autonomy: minimizes the need for system management from the part of the hosting system under the assumption that the mobile agents have no harmful intentions.

•

Intelligence: the paradigm enables the users themselves to enhance the search capabilities of their mobile agent by individually developing more intelligent algorithms to deal with the inherent heterogeneity of the service description.

3.3 Difference to typical Peer-To-Peer applications The main difference between our approach and typical Peer-To-Peer (P2P) systems used in the Internet is the asynchronous behavior. The asynchronous nature of mobile agent extends the search to nodes that may join the network at different times or even within several days. Furthermore, a direct implementation of these P2P file exchange systems over ad-hoc networks is not possible for the following reasons: •

The highly dynamic topology of ad-hoc networks: Nodes can move arbitrarily. This implies that nodes that are physically close, e.g., in one-hop distance at one point of time may well be at different sides of the network at another point of time. This makes it hard to maintain efficient overlay structures. Also, nodes are connecting and disconnecting from the network all the time, so that it is not possible to rely on the existence of any given node.

•

The limited resources of the nodes in terms of power and memory capacity as most of the hosts rely on batteries for supplying power. Since sending is very energy demanding, this restricts severely the amount of messages that can be send. The lack of memory prevents the extensive replication of information across the nodes.

•

The limited bandwidth: In a wireless environment, bandwidth is usually restricted and therefore the traffic that is needed for the maintenance of the network as well as the traffic caused by applications must be kept minimal.

4. System Architecture 4.1 Main components of a mobile agent Figure 1 illustrates the main components of the mobile agent. The service discoverer resides at the heart of the agent. Here, the search intelligence is implemented. Since each node has its own semantics concerning the representation of meta-information about the documents, we use a representation of a domain specific ontology. We base this representation on work done within the DIANE project [10]. Using the description of the

73

required service and a cached subset of the domain-specific ontology, the agent communicates with the hosting environment for service discovery through the interaction manager. Having discovered an interesting service, the contact information is sent to the hosting environment to establish the Peer-To-Peer communication and the information interchange (either synchronous through file transfer using the wireless communication interface or asynchronous using mail). The persistence manager is responsible for serializing the agent before entering the hibernation mode or before migrating to another device. In general, it is responsible for managing the life-cycle of the agent, killing itself upon completion of its task or cloning itself before the migration. The migration manager is responsible for establishing the negotiation before code cloning and transfer whenever a new device is in the neighborhood. Mobile agent Contact info

Service Discoverer

Description of required service

Subset of domain – specific ontology

Interaction Manager

Migration Manager

Persistence Manager

Hosting Environment

Figure 1. The main components of a mobile agent

4.2 Architecture of the hosting environment Figure 2 illustrates the main components of the hosting platform and the life-cycle of an agent in this platform. The hosting platform encapsulates the runtime environment for the agents to execute. It maintains a directory of information services that the owner of the mobile device is willing to publish and share with other users in the ad-hoc network community. For the matching process, a domain ontology must be always present on the hosting platform to support the search process [10]. The query processor is responsible for answering the search requests coming through the interaction manager of the mobile agent. The communication manager interacts with the outside world. It receives migrating agents into and out of the system coming from the transport layer. It also interfaces with the email system for establishing the offline contact to the service requester.

74

Searchable metadata of published services

4

Ontology

Query Processor

2

Agent Agent 1

n

3 5

1 Transport layer Communication manager

Hosting Plattform

Email system

...

Figure 2. Hosting Platform and typical life-cycle of a mobile agent

Using these components in the hosting platform, a typical life-cycle of a mobile agent can be summarized as follows. The migrating agent arrives from the transport layer through the communication layer (step 1). Then, it is allowed to reside in the hosting platform and perform its search for information by querying the directory of published services (step 2). If an interesting service is found, the user is asked for permission before establishing contact with the information requester, usually via email (step 3). Following deadline and resource consumption constraints, the agent may clone itself (step 4) and migrate to other devices upon their presence in the physical neighborhood (step 5).

4.3 Implementation platform Our mobile agents will be hoping between different platforms: notebooks, PDAs, tabletPCs, smartphones, etc. in order to guarantee total interoperability, we sought a hosting environment, which is available on all their hardware platforms, and operating system. Our decision was to use Java. The Java platform is becoming the standard platform for deploying agents as compared to earlier LISP and other typical AI languages. Several Java-based platforms, such as FIPA-OS [11] and JADE [12], are becoming a defacto standard in the world of static agents. MicroFIPA-OS [13] and LEAP [14] are their counterpart for PDA and other light weight devices.

75

The Java 2 Micro Edition (J2ME) [15] is now available on almost all the lightweight platforms and is compatible with the Java 2 Standard Edition (J2SE) found on more powerful notebooks. J2ME provides a light version of the most popular Java libraries. It defines standard interfaces for exchanging messages over wireless networks, telephony systems, lightweight graphics, etc. To facilitate development, several emulators are available for programming and testing on the standard PC.

5. Database-like Infrastructural System Requirements In contrast to an approach purely based on static DBMS on mobile devices, our proposed solution for asynchronous service discovery is certainly a very flexible one and promises a wider search potential. However, this approach poses lots of design challenges. In order not to end up with a virus-like system spreading across the mobile devices and consuming their scarce resources, almost every infrastructural support offered by traditional DBMS and distributed systems in general must be revisited, embedded in our mobile agents or hosting platform, and optimized for use in this new paradigm. Here, we outline some of these requirements and compare them to standard approaches used in Distributed Database Management Systems and Distributed Systems. •

Persistence services: we definitely need low cost persistence services for serializing the mobile agents before hibernations. This infrastructural support is present since the early days of object-oriented database management systems and seems to be one of its few components that commercially survived.

•

Agent replication: we need replication management for cloned agents. The algorithms for managing cloning have their roots in the distributed database systems. However, since the consistency constraints are far more relaxed, these algorithms must be, in turn, simplified.

•

Agent coordination: another usage of agent cloning is to assign different agents subtasks in a distributed information retrieval process. The coordination of these spawned agents can be easily modeled using open nested transactions. In our work done on static agents [16], we deomsntrated the feasibility and the beinfits of using a variation of the open-nested transaction model to model agent coordination and govern both their cooperative and competitive behavior.

•

Ontology modeling: in this highly decentralized system with no standardizing instance, ontology modeling becomes a difficult task as opposed to well-defined database schemes. Here, we base our solution on work previously done within the DIANE project [10].

76

•

Security: Security issues in the field of mobile agents are much more complex than in the the field of distributed database management systems. Here, it is a two-fold problem. Taking the side of the hosting nodes, executing the foreign code of a mobile agent certainly represents a security threat. Although user authentication and authorization as in DBMS seem to be an appealing solution, it is practically very difficult to achieve due to the large flexibility and execution possibilities of a mobile agent as compared to simple SQL statements. In the past few years, many research efforts concentrated on protecting the hosting platform from malicious agents. This protection varies from the use of authentication and authorization to a complete monitoring of the execution of the agent. Considering the side of the mobile agent, revealing its plans by expressing it in a declarative way to the hosting platform for execution is the security threat. Malicious nodes can manipulate the honest agent turning it to a virus-like piece of software spreading through the network. In our scenario, we assume the honesty of both agents and hosting nodes; a realistic assumption for a community of students or employees of the same organization having a common interest of sharing information among them.

•

Scalability: is the most crucial design challenge in this scenario. “How many agents can reside in the mobile device with its limited resources” is the decisive question, whose answer will tune the operating parameters of the system. Simulation models extracted from the world of distributed information systems form the basis for our simulation study.

•

Predictability: is a very difficult problem on the level of the macro agent society. Similar to scalability, simulation is our only means to improve the predictability of the system. Our experience [16] in this area, shows that here too, many simulation parameters have their roots in the simulation models of distributed information systems.

6. Summary and future work Mobile ad-hoc networks offer new possibilities for users to share information. In such environments, service discovery cannot always be done synchronously. In this paper, we present an approach for asynchronous service discovery based on mobile agents. We present the reasons for choosing mobile agents for our approach. Then, we highlight the basic architectural components of the system and present the required infrastructure that must be adopted from the well-established database technology.

77

Beside the developement of a functional protytype based on the J2ME, we are currently working on an extensive simulation model to analyze the behavior of the system. In our analysis, we concentrate on performance metrics, such as the degree of propagation of agents within the network as compared to the purely synchronous approach. We also investigate the impact of each of the control parameters on the performance of the mobile agents and the resource consumption in the network in terms of superfluous migrations. Here, we target some good settings of the control parameters before the actual deployment.

References [1] CORBA Trading Object Service http://www.omg.org/technology/documents/formal/trading_object_service.htm [2] The Foundation for Physical Agents. http://www.fipa.org [3] Gnutella File Sharing. http://gnutella.wego.com [4] R. Koodli and C. Perkins. Service Discovery in On-Demand Ad-Hoc Networks, MANET Working Group Internet Draft, October, 2002. [5] J. Wu and M. Zitterbart. Service Awareness and its Challenges in Mobile Ad-Hoc Networks. In: Proc of the GI Jahrestagung 2001, Volume 1, Vienna, Austria, 2001. [6] SOUL Project. Self-Organized Ubiquitous Learning. http://bowmore.unitrier.de/soul/publikationen.htm [7] DIANE: Dienste in Ad-hoc-Netzen. http://www.ipd.uni-karlsruhe.de/DIANE [8] M. Klein, B. König-Ries. Multi-Layer Clusters in Ad-hoc Networks - An Approach to Service Discovery. In: Proc. of the International Workshop on Peer-To-Peer Computing. Pisa, Italy, May 2002. [9] D. Kotz. Future Directions for Mobile Agent Research, available at: http://dsonline.computer.org/0208/f/kot.htm [10] B. König-Ries, M. Klein. Information Services to Support E-Learning in Ad-hoc Networks In: Proc. of. First International Workshop on Wireless Information Systems (WIS2002), Ciudad Real (Spain), April 2002. [11] The FIPA-OS platform, http://fipa-os.sourceforge.net/ [12] The JADE (Java Agent DEvelopment Framework), http://sharon.cselt.it/projects/jade/ [13] Supporting software agents on small devices. In Proc. of the first international joint conference on Autonomous agents and multiagent systems, Bologna, Italy, 2002. [14] The LEAP (Lightweight Extensible Agent Platform), http://leap.crm-paris.com/ [15] Java 2 Micro Edition, http://java.sun.com/j2me/

[16] K. Nagi. Transactional Agents: Towards a Robust Multi-Agent System. Lecture Notes on Computer Science (LNCS 2249), Springer-Verlag. 2001.

78

Verwaltung replizierter Daten bei nutzerdefinierter Replikation Christoph Gollmick, Gennadi Rabinovitch Friedrich-Schiller-Universit¨at Jena, Institut f¨ur Informatik Ernst-Abbe-Platz 2, 07743 Jena {gollmick,gennadi}@informatik.uni-jena.de

Kurzfassung: Ein Dienst zur Replikation und Synchronisation von Daten ist f¨ur mobile Datenbankl¨osungen unverzichtbar. Das Konzept der nutzerdefinierten Replikation erlaubt dabei die anwendungsgesteuerte, dynamische Auswahl relationaler Datenbankinhalte f¨ur die Replikation. Die Realisierung eines solchen Dienstes erfordert eine effiziente Verwaltung von Replikationsanforderungen tausender mobiler Clients. Der Beitrag stellt eine L¨osung vor, die auf der Gruppierung von semantisch zusammengeh¨orenden Daten zu Datenfragmenten basiert. Wir gehen dabei auf einen Algorithmus zur Bildung geeigneter Fragmentmengen sowie die Verwaltung von Fragmenten ein.

1 Einfuhrung ¨ und Motivation Dank der Fortschritte im Bereich der Hardware mobiler Ger¨ate, k¨onnen diese heute mit relationalen Datenbanksystemen ausgestattet werden. Kommerzielle mobile Datenbankl¨osungen [Fan00] erlauben dabei sowohl eine isolierte Arbeit mobiler Clients als auch ihre Integration in eine kooperative Datenverwaltung mit Workstation- und GroßrechnerDBS. Solche mobilen Client/Server-Datenbankumgebungen bestehen aus einem zentralen Datenbank-Server, einem oder mehreren mobilen Datenbank-Clients und einer Komponente, die den Datenabgleich (Synchronisation) regelt. Mobile Ger¨ate sind dabei abh¨angig von unterwegs verf¨ugbaren Kommunikationsmitteln und einer mobilen Energieversorgung. Beide Voraussetzungen sind heute und auch in naher Zukunft noch mit erheblichen Einschr¨ankungen versehen. Der Stand der Technik bietet zwar ad¨aquate drahtlose Kommunikationsmittel wie WLAN oder UMTS, diese sind aber noch nicht weit verbreitet, teuer und energieintensiv in der Benutzung. Außerdem sind sie prinzipbedingt nicht so leistungsstark und sicher gegen Angriffe von Dritten wie feste Netze. Neben der klassischen Client/Server-Kommunikation ist deshalb f¨ur den jederzeitigen, sicheren und kosteng¨unstigen Zugriff lokaler Anwendungen auf Datenbankinhalte ein geeigneter Dienst ¨ zur Replikation und Synchronisation von Daten notwendig [ OV99, HHB96]. Wie ein solcher Replikationsdienst ausgestaltet werden muß, h¨angt maßgeblich von den Anforderungen des angenommenen Anwendungsszenarios ab. Die hier zugrundegelegte Anwendung ist das interaktive mobile Reiseinformationssystem H ERMES [Bau03]. H ER -

79

MES hat die Aufgabe, seine Nutzer bei der Reiseplanung zu unterst¨ utzen und ihnen unterwegs ortsabh¨angige Informationen bereitzustellen. Im Unterschied zu klassischen Touristenf¨uhrern werden aber nur die Basisdaten, wie Name, Einwohnerzahl oder Historie von Orten, zentral bereitgestellt. Der weitaus gr¨oßte Teil wird von den mobilen Nutzern selbst und in der Regel vor Ort erg¨anzt und aktualisiert (z. B. Reiseberichte, Speisekarten von Restaurants). Offensichtlich sind die Zugriffsprofile der H ERMES-Nutzer abh¨angig vom Aufenthaltsort, der Zeit und der Situation, in der sie sich befinden. Eine Konsequenz daraus ist, daß die Auswahl der Daten f¨ur die Replikation nicht zentral vorgegeben werden kann. Vielmehr m¨ussen wir der H ERMES-Client-Anwendung die M¨oglichkeit geben, Replikate bezogen auf Nutzer- und Client-Bed¨urfnisse zur Laufzeit anzufordern und wieder freizugeben.

Leider unterst¨utzen aktuelle kommerzielle mobile Datenbankl¨osungen eine Auswahl von Replikaten durch die Anwendung nur in sehr eingeschr¨anktem Maße (z. B. einmalige Auswahl aus einer Liste vordefinierter Sichten und Ersetzen von Platzhaltern). Zur Realisierung des unverbundenen Arbeitens von H ERMES und verwandten Anwendungen wurde deshalb ein Dienst zur nutzerdefinierten Replikation (NR) entwickelt, der auf einer vorhandenen mobilen Client/Server-Datenbankumgebung aufsetzt [Gol03a, Gol03b]. Die ArPSfrag replacementsbeit mit dem nutzerdefinierten Replikationsdienst geschieht in zwei, in verbundenem Zustand auszuf¨uhrenden, Schritten, der Replikationsschemadefinition und der Replikatdefinition (Abbildung 1). Anwendung/Client-DB

Administrator/Server-DB Replikationsschemadefinition

Replikatdefinition

Transaktion (T )

T (R(d)) ≡ R(T (d))

Abbildung R(d), Parametrisierung

Freigabe von Daten zur Replikation, Schemaerweiterung um Konfliktbehandlung verbunden

nur lokales Commit, Wiederausf¨uhrung n¨otig unverbunden

Abbildung 1: Ablauf der nutzerdefinierten Replikation

Das Replikationsschema wird i. d. R. einmalig vom Administrator auf dem Server erzeugt und beschreibt den Ausschnitt der Quelldatenbank, der f¨ur alle mobilen Clients zur Replikation freigegeben ist, erweitert um Konfliktbehandlungsmethoden. Darauf bezugnehmend kann ein mobiler Client bevor er die Verbindung trennt ein oder mehrere Replikate definieren. Dies geschieht mit Hilfe einer an die SQL-Sichtdefinition angelehnten Syntax (CREATE REPLICATION VIEW), erweitert um einen Modus (optimistisch a¨ nderbar, exklusiv a¨ nderbar, nur lesbar) und Parameter f¨ur die Konfliktbehandlung (z. B. Anzahl der

80

Schl¨ussel f¨ur Einf¨ugungen). Nach erfolgreicher Synchronisation 1 kann unverbunden mit den Mitteln des Client-DBMS auf den Replikationssichten gearbeitet werden. Nat¨urlich k¨onnen Replikationssichten auch wieder gel¨oscht werden. Dies signalisiert dann dem Replikationsdienst, daß er die von der Sicht referenzierten Daten, sofern sie keine andere Sicht mehr ben¨otigt, l¨oschen kann. Die Menge der definierten Replikationssichten bildet ein Fenster“ durch das ein bestimm” ter Ausschnitt der Quelldatenbank sichtbar“ ist. Solange die Transaktionen der mobilen ” Anwendung nur durch dieses Fenster auf die Daten zugreifen (also die Replikationssichten benutzen), soll f¨ur sie Replikattransparenz gelten. Replikattransparenz heißt, daß unver¨ bunden durchgef¨uhrte Anfragen und Anderungen an Daten dieselbe Ergebnismenge bzw. dasselbe Ergebnis haben, als w¨urden sie, isoliert von anderen Nutzern, auf entsprechenden Sichten der Quelldatenbank ausgef¨uhrt (T (R(d)) ≡ R(T (d)), Abbildung 1). Durch Replikattransparenz werden falsche Entscheidungen der Anwendung und Reintegrationskonflikte vermieden, die durch unvollst¨andige Daten und eine rein nachgelagerte, also bei ¨ der Reintegration der Anderungen durchgef¨uhrte, Integrit¨atssicherung entstehen k¨onnen. 2 Die einfachste M¨oglichkeit, Replikattransparenz zu erzielen, ist, die ganze Quelldatenbank inklusive aller Integrit¨atsbedingungen auf den Client zu replizieren. Allerdings wird dies nur in wenigen Ausnahmef¨allen, in denen die Datenbank klein genug ist, m¨oglich und sinnvoll sein. Eine zentrale Aufgabe unseres Replikationsdienstes ist es also, anhand der Replikationssichtdefinitionen unter Ber¨ucksichtigung bereits auf dem Client vorhandener Daten eine geeignete Menge (neu) zu replizierender bzw. zu l¨oschender Daten zu bestimmen. Das erfordert eine entprechende Metadaten-Verwaltung von Replikaten und Replikatdefintionen f¨ur die Synchronisation durch den Replikationsdienst. Im Abschnitt 2 erl¨autern wir die Grundlagen f¨ur die Replikatverwaltung und f¨uhren anschließend den Fragment-Begriff in Abschnitt 3 ein. Ein Algorithmus zur initialen Fragmentbildung wird in Abschnitt 4 vorgestellt. Anschließend erl¨autern wir in Abschnitt 5 die Funktionsweise des Fragmentierungsalgorithmus anhand eines Beispiels und gehen auf eine Realisierung des Fragment-Konzepts ein. Abschnitt 6 schließt mit einer Zusammenfassung und einem Ausblick.

2 Grundlagen der Replikatverwaltung Ein erster Ansatzpunkt f¨ur eine Replikatverwaltung ist das bereits gut erforschte und im Datawarehouse-Bereich eingesetzte Konzept der materialisierten Sichten [GM99]. Wir w¨urden also das Ergebnis jeder Replikationssichtdefinition als materialisierte Sicht auf dem anfragenden mobilen Client anlegen. Dieses einfache Verfahren hat eine Reihe von Nachteilen, das Aufzeigen der wichtigsten von ihnen soll im folgenden dazu dienen, Ziele und L¨osungen f¨ur eine effiziente Replikatverwaltung zu erarbeiten. Bei u¨ berlappenden Sichtdefinitionen auf einem Client m¨ußte ein u. U. erheblicher Teil 1 F¨ ur die Durchf¨uhrung der Synchronisation und Konfliktbehandlung werden von der NR die Standardkomponenten der Datenbanksysteme der mobilen Client/Server-Datenbankumgebung eingesetzt. 2 Zu beachten ist, daß Konflikte aufgrund konkurrierender Anderungen ¨ verschiedener mobiler Nutzer dadurch nicht verhindert werden k¨onnen [Lie03].

81

der Daten redundant vorgehalten werden. Diese Redundanz impliziert nicht nur die Verschwendung kostbaren Speicherplatzes, sondern auch einen erh¨ohten Synchronisationsaufwand. Ziel muß es also sein, angefragte Daten nur einmal auf den Client zu replizieren, egal, von wie vielen Replikationssichten sie benutzt werden. ¨ Eine Ubertragung und die lokale Pr¨ufung von Integrit¨atsbedingungen (z. B. Fremdschl¨usselbedingung) ist mit materialisierten Sichten nur sehr eingeschr¨ankt m¨oglich (durch die Angabe von WITH CHECK OPTION), da nur genau die von der Sichtdefinition erfaßten Daten repliziert werden. Unser Replikationsdienst muß deshalb in der Lage sein, eventuell f¨ur die Integrit¨atssicherung zus¨atzlich erforderliche Daten mit auf den Client zu u¨ bertragen. Ausgehend von einer client-orientierten Replikatverwaltung (der Replikationsdienst sammelt f¨ur jeden Client w¨ahrend er nicht mit dem Server verbunden ist, alle ihn betreffenden Daten¨anderungen, die dann bei der Synchronisation sofort u¨ bertragen werden k¨onnen) ¨ m¨ußte der Replikationsdienst Anderungen an Daten, die von mehreren mobilen Clients repliziert wurden, redundant vorhalten. Wir brauchen also eine Verwaltung, die auf der Bildung von logischen Verwaltungseinheiten (im folgenden Fragmente) basiert, welche Daten zusammenfassen, die semantisch und nach Auswertung der Zugriffsprofile mobiler Nutzer zusammengeh¨oren. Da sich Zugriffsprofile a¨ ndern k¨onnen, muß eine vorgenommene Fragmentierung zudem a¨ nderbar sein. F¨ur die bei der Replikatdefinition durch die Client-Anwendung spezifizierbaren Modi der Replikation (z. B. exklusives Einf¨ugen) ben¨otigen wir auf Dienstseite eine geeignete Sperrverwaltung. Im Fall konkurrierender materialisierter Sichten entspricht die Aufgabenstellung der bei der Realisierung von Pra¨ dikatssperren [HR01]. Der semantische Vergleich beliebiger Selektionspr¨adikate ist allerdings NP-schwer und demzufolge sehr teu” er“ in der Ausf¨uhrung. Wir greifen deshalb auf das bekannte Konzept der Granulatsperren [GR93] zur¨uck. Sperren oder vergleichbare Attribute werden hierbei nicht f¨ur beliebige Pr¨adikate gesetzt, sondern nur f¨ur eine feste Menge vorgegebener Pr¨adikate. Hierf¨ur bieten sich die Fragmente an, die wir im vorangegangenen Absatz gefordert haben. Dazu m¨ussen wir bei der Bildung von Fragmenten darauf achten, daß sich die Transformation Replikationssicht → Fragmentmenge (siehe Abschnitt 5.3) einfach ausf¨uhren l¨aßt.

3 Fragmente als Verwaltungseinheit Im Unterschied zu Dateisystemen (Dateien) und objektorientierten Datenbanksystemen (Objekte) bieten sich als Fragmentgranulat in relationalen Datenbanken verschiedene logische Verwaltungseinheiten an.3 Eine Verwaltung auf Tabellenebene ist naheliegend aber zu grob, wenn beispielsweise aus einer großen zentralen Tabelle jeweils nur kleine Datenmengen repliziert werden. Eine feinere Auswahl erlauben Tabellenpartitionen [Now01], die u¨ ber Selektion oder Projektion aus einzelnen Datenbanktabellen gebildet werden. Hierbei k¨onnen allerdings Abh¨angigkeiten zwischen verschiedenen Tabellen nicht ber¨ucksichtigt werden. Wir definieren die f¨ur die Replikation (Auswahl zu replizierender Daten) und 3 Physische Verwaltungseinheiten wie Seiten sind f¨ ur eine inhaltsbasierte Verkn¨upfung von Daten denkbar ungeeignet, weswegen wir sie hier nicht weiter betrachten.

82

die Sperrverwaltung (siehe auch Abschnitt 5.1) verwendete Einheit deshalb wie folgt: Ein Fragment ist eine Menge horizontaler, vertikaler oder kombinierter Tabellenpartitionen aus einer oder mehreren Tabellen, angereichert mit Zusatzinformationen (z. B. Beziehungen zu anderen Fragmenten). Prinzipiell kann ein Fragment aus nur einem Tupel (mit einem Attribut) oder aus der gesamten Datenbank bestehen. Es gilt also bei der Fragmentbildung einen Kompromiß zwischen geringer Fragmentanzahl (Fragmente m¨oglichst groß) und zu viel u¨ bertragenen Daten (Fragmente m¨oglichst klein) zu finden. Wir betrachten in diesem Beitrag nur Fragmente, die aus horizontalen Tabellenpartitionen bestehen.

4 Bildung von Fragmenten Die Problemstellung der logischen und physischen Fragmentierung von Daten zur Verbesserung der Skalierbarkeit der Replikatsynchronisation ist indes nicht neu und es wurden bereits verschiedene L¨osungsans¨atze publiziert [YDN00, PB99]. Die zitierten Ans¨atze gehen davon aus, daß dem Administrator das Zugriffsprofil der mobilen Clients detailiert bekannt ist, d. h. welche Daten von welchem Client angefordert werden und welche Zugriffs¨ bzw. Anderungsh¨ aufigkeit die Daten aufweisen. Entsprechend wird ein globales Optimum approximiert und in Form von Indexstrukturen oder einer physischen Partitionierung realisiert. Da das detailierte Zugriffsprofil der mobilen Anwender bei nutzerdefinierter Replikation zun¨achst nicht zur Verf¨ugung steht, verfolgen wir einen zweiphasigen Ansatz. In der In¨ itialisierungsphase vor Inbetriebnahme des Systems oder bei gravierenden Anderungen im Datenschema, wird aus den vorab gegebenen Informationen zun¨achst ein geeigneter, nicht zwingend optimaler, Anfangszustand von Fragmenten erstellt, der anschließend in der Anpassungsphase im laufenden Betrieb automatisch und inkrementell anhand von Zugriffsstatistiken angepaßt wird. Wir konzentrieren uns in diesem Beitrag auf die Beschreibung eines Algorithmus zur initialen Fragmentbildung.4 Die initiale Fragmentbildung erfolgt in zwei Schritten: 1. Im ersten Schritt, der Schemafragmentbildung, werden jeweils Tabellen zu einem Schemafragment zusammengefaßt, die in Beziehung stehen und bei der Replikation immer zusammen u¨ bertragen werden sollen. 2. Im zweiten Schritt, der Datenfragmentbildung, wird jedes Schemafragment in einzelne (Daten-)Fragmente zerlegt, die jeweils Tupel mit gemeinsamen Merkmalen zusammenfassen. Zur Entscheidung, welche Tabellen in einem Schemafragment und welche Tupel in einem Fragment verwaltet werden sollten, k¨onnen Informationen aus dem Datenbankschema (z. B. Fremdschl¨ussel, Ortsattribute, Integrit¨atsbedingungen), den Daten selbst (z. B. 4 Prinzipiell k¨ onnen die dabei verwendeten Techniken bzw. deren Umkehrung auch f¨ur die sp¨atere inkrementelle Anpassung der Fragmente verwendet werden [Rab03].

83

nutzer- oder gruppenbezogene Daten) oder von der Anwendung (z. B. nur-lese Daten, Zugriffsrechte) ausgewertet werden. Die Informationen des Datenbankschemas sind weitgehend automatisch auswertbar und stehen bereits vor Inbetriebnahme des Systems fest. Die Informationen u¨ ber die potentielle Daten- und Anwendungsnutzung m¨ussen vom Anwendungsentwickler bereitgestellt werden, sie stehen aber auch sp¨ater in der Anpassungsphase durch automatische Auswertung der Zugriffsstatistiken zur Verf¨ugung. 4.1 Schemafragmentbildung

Ort Name Jena Erfurt Weimar M¨unchen

Land Th¨uringen Th¨uringen Th¨uringen Bayern

Einw. 100000 220000 62000 1300000

(0, ∗) besitzt (1, 1) Touristenobjekt

PSfrag replacements

Kirche Kirche Name Friedenskirche Stadtkirche St. Peter und Paul Peterskirche

Restaurant Nr Name 1 Zur Noll 2 Poseidon 3 Roter Hirsch 4 Hohe Warte 5 Il Cortile 6 Brotzeitst¨uberl 7 Shanghai 8 Granada

Ort

Ort Jena Jena Jena Erfurt Erfurt M¨unchen Weimar M¨unchen

Restaurant (0, ∗)

e/k e e e k

Arta de el de de it de zh es

Ort Jena Jena Weimar M¨unchen

hat (1, 1) Empfehlung

Empfehlung Von RNr Erwin 1 Egon 1 Egon 4 Alex 6 Maja 7

a Sprachenk¨ urzel

Text gut“ ” na ja“ ” geht so“ ” ok“ ” na ja“ ”

nach ISO 639-1

Abbildung 2: Beispiel: E/R-Diagramm und Daten

Wir beschreiben im folgenden die Schemafragmentbildung anhand der, u. a. f¨ur die sp¨atere ¨ Anderungsf¨ ahigkeit von Replikaten wichtigen, Fremdschl¨usselbeziehung zwischen Tabellen. Es k¨onnen jedoch mit leichten Modifikationen bzgl. der transitiven Partitionierung (siehe Abschnitt 4.2) auch andere Abh¨angigkeiten und Integrit¨atsbedingungen verwendet werden. Zur Illustration des Verfahrens verwenden wir den in Abbildung 2 angegebenen Ausschnitt aus einer H ERMES-Datenbank. Restaurant.Ort und Kirche.Ort sind jeweils Fremdschl¨ussel bzgl. Tabelle Ort, Empfehlung.RNr ist Fremdschl¨ussel bzgl. Restaurant. Wir betrachten die im Schema vorhandenen Tabellen als Knoten (X 1≤i≤n ) und die Fremdschl¨usselbeziehungen als zur Prim¨arschl¨ussel haltenden Tabelle hin gerichtete Kanten eines Graphen (Abbildung 3 zeigt den Graphen f¨ur das Beispielschema). Ziel der Sche-

84

PSfrag replacements

X4

Kirche

X3

SF1

Ort

SF2

X2

Restaurant

Pfad

X1

Empfehlung

Schemafragment Abbildung 3: Beispiel f¨ur Schemafragmentbildung

mafragmentierung ist es, rekursiv die Prim¨arschl¨ussel haltende Tabelle zu den abh¨angigen Tabellen in ein Schemafragment zu gruppieren. Bedingung f¨ur die sp¨atere Durchf¨uhrung der Datenfragmentierung (Abschnitt 4.2) ist, daß jedes Schemafragment h¨ochstens einen Fremdschl¨usselpfad enthalten darf. Die Schemafragmentierung ist nicht eindeutig und i. d. R. Aufgabe eines Administrators. Da wir die zu erwartenden Zugriffsprofile noch nicht im Detail kennen (Wird sich z. B. die Mehrzahl der Reisenden in besuchten Orten eher f¨ur Kirchen oder Restaurants interessieren?), k¨onnen wir die initiale Schemafragmentierung f¨ur eine gegebene Knotenliste automatisch mit dem in Abbildung 4 angegebenen Algo¨ rithmus erzeugen lassen. Uber die Reihenfolge der Knoten in der Eingabeliste, kann der Administrator die Schemafragmentierung steuern. SchemaFrag() 1: 2: 3: 4: 5: 6: 7: 8: 9:

SELECT DISTINCT tabname FROM syscat.tables WHERE tabschema=’HERMES’ AND tabname NOT IN ( SELECT reftabname FROM syscat.references WHERE tabschema=’HERMES’);

for each X1≤i≤n do if not Visited(Xi ) do Visited(Xi ) = true; select Xp = parent(Xi ) with not Visited(Xp ) if exists Xp do SchemaFrag(); SF(Xi ) ∪ SF(Xp ); od; od;

WITH temp (mode, path, len) AS ( SELECT p.tabname, p.tabname, 1 FROM syscat.references p WHERE p.tabname = ’EMPFEHLUNG’ UNION ALL SELECT c.reftabname, p.path || ’+’ || c.reftabname, p.len+1 FROM temp p, syscat.references c WHERE p.mode = c.tabname) SELECT path, len FROM temp ORDER BY len DESC;

Abbildung 4: Algorithmus SchemaFrag und SQL-Anweisungen (DB2-Notation)

85

Zu Beginn des SchemaFrag-Algorithmus bildet jeder Knoten in der Knotenliste ein eigenes Schemafragment. W¨ahrend der Abarbeitung werden die auf einem Pfad liegenden Schemafragmente vereinigt, wobei jeder Knoten nur einmal betrachtet wird. Nach Abschluß des Algorithmus verf¨ugen wir u¨ ber eine Anzahl disjunkter Schemafragmente, deren jeweilige Tabellen u¨ ber einen Fremdschl¨usselpfad verbunden sind (Abbildung 3 zeigt eine m¨ogliche Zerlegung unseres Beispiels in zwei Schemafragmente). Die bei der Zerlegung nicht ber¨ucksichtigten Fremdschl¨usselbeziehungen werden als Zusatzinformationen in die sp¨ateren Fragmente aufgenommen (siehe Abschnitt 5.2). Die Schemafragmentbildung bzgl. Fremdschl¨ussel l¨aßt sich auch leicht u¨ ber SQL-Anfragen an den Datenbankkatalog unterst¨utzen. M¨ogliche Pfadanf¨ange (Tabellen im Schema, auf die keine Fremdschl¨usselreferenz verweist) erh¨alt man mit Hilfe der ersten in Abbildung 4 angegebenen Kataloganfrage. Die zweite, rekursive, Anfrage bestimmt f¨ur die Tabelle Empfehlung alle m¨oglichen Fremdschl¨usselpfade. 4.2 Datenfragmentbildung Der n¨achste Schritt ist die Zerlegung der Schemafragmente anhand der vorhandenen Basisdaten in geeignete Fragmente. F¨ur die initiale Fragmentbildung m¨ussen allgemeing¨ultige Kriterien aus der Anwendung abgeleitet werden. Betrachten wir H ERMES, so ist es f¨ur einen Touristen in Jena wahrscheinlicher, daß er sich f¨ur Jenaer Gastronomiebetriebe und Kulturobjekte interessiert als f¨ur die in M¨unchen. Es gilt also f¨ur Zugriffsprofile von H ERMES-Nutzern eine Ortsabh¨angigkeit im Datenzugriff. Eine weitere Klassifizierung von Daten ist anhand der Anzahl der auf sie (potentiell) zugreifenden Nutzer in nutzerspezifisch (z. B. wenn H ERMES die Verwaltung privater Reiseaufzeichnungen erlaubt) und gemeinsam genutzt m¨oglich. DataFrag(F , fmin, ) 1:

let Ai be the first attribute with (1 ≤ i ≤ n) and more than one distinct value (V ) in corresponding table 2: if exists Ai do i do 3: for each V1≤j≤m 4: if (SELECT count(*) FROM X(Ai ) WHERE Ai = Vji ) ≥ fmin do 5: create new fragment with condition: Condition(F ) AND Ai = Vji “ ” 6: else 7: insert Vji in SetOfResidValues 8: if new fragments were created and SetOfResidValues is not empty do 9: extend F ’s condition to Condition(F ) AND Ai IN (SetOfResidValues)“ ” 0 do 10: for each new or changed fragment F1≤k≤o 11: DataFrag(Fk0 , fmin, ); 12: od;

Abbildung 5: Algorithmus DataFrag

Die genannten Kriterien haben die angenehme Eigenschaft, daß sie in der Regel explizit mit Attributen im Schema verbunden sind (Ortsattribute, Besitzer). Wir k¨onnen damit

86

einen Algorithmus (Abbildung 5) angeben, der bei Eingabe einer Attributliste und eines Grenzwertes (fmin) die Daten eines Schemafragments horizontal in Fragmente zerlegt. Die Attributliste gibt die Reihenfolge der Partitionierungsattribute auf dem Pfad vor, der vom Blatt zur Wurzel durchlaufen wird. F¨ur jeden angenommenen Wert eines Partitio¨ nierungsattributs wird vom Algorithmus ein neues Fragment abgespalten. Uber fmin wird sichergestellt, daß solche Fragmente mindestens eine Tabelle mit ≥ fmin Tupeln enthalten. Die Liste der Partitionierungsattribute f¨ur jede Tabelle kann entweder vom Administrator vorgegeben oder, wenn keine Informationen vorliegen, durch aufsteigende Sortierung aller Attribute der jeweils betrachteten Tabelle auf dem Pfad nach der Anzahl der verschiedenen Attributwerte automatisch ermittelt werden [Rab03].

5 Beispiel und Realisierung 5.1 Beispiel Am Beispiel des Schemafragments 1 (Abbildung 3) aus unserem H ERMES-Schema soll die Funktionsweise von DataFrag demonstriert werden (Attributliste5 : Ort.Land, Restaurant.Ort, Restaurant.Art und fmin = 2). Das erste vom Algorithmus ausgew¨ahlte Partitionierungsattribut ist Ort.Land. Es wird ein neues Fragment (Fragment 1) f¨ur den Wert ’Th¨uringen’ (3 Tupel in Ort 1 ) erzeugt und es verbleibt ein Fragment (Fragment 2) mit Ort.Land =’Bayern’ (Abbildung 6). Ort 1 Name Erfurt Jena Weimar

Ort 2 Name M¨unchen

Land Thuringen ¨ Thuringen ¨ Thuringen ¨

Einwohner 220000 100000 62000

Land Bayern

Einwohner 1300000

Restaurant 1 Nr Name 1 Zur Noll 2 Poseidon 3 Roter Hirsch 4 Hohe Warte 5 Il Cortile 7 Shanghai Restaurant 2 Nr Name 6 Brotzeitst¨uberl 8 Granada

Art de el de de it zh Art de es

Ort Jena Jena Jena Erfurt Erfurt Weimar Ort M¨unchen M¨unchen

Empfehlung 1 Von RNr Erwin 1 Egon 1 Egon 4 Maja 7

Text gut“ ” na ja“ ” geht so“ ” na ja“ ”

Empfehlung 2 Von RNr Alex 6

Text ok“ ”

Abbildung 6: Beispiel f¨ur Fragmentierung – Schritt 1

Im n¨achsten Schritt betrachtet der Algorithmus f¨ur die Fragmente 1 und 2 das Partitionierungsattribut Restaurant.Ort (Abbildung 7). Der Algorithmus spaltet nun zuerst ’Jena’ als neues Fragment (Fragment 1.1) ab. Als n¨achstes spaltet der Algorithmus die Tupel f¨ur Erfurt ab (Fragment 1.2) und bel¨aßt die Tupel f¨ur ’Weimar’ in Fragment 1.3. Das Fragment 2 wird nicht weiter unterteilt, weil das Partitionierungsattribut Restaurant.Ort nur einen Attributwert hat (’M¨unchen’). Anschließend betrachtet der Algorithmus das Partitionierungsattribut Restaurant.Art (Abbildung 8). Es wird ein neues Fragment (Fragment 1.1.1) mit Restaurant.Art = ’de’ vom 5 entspricht

einer Liste, wie sie sich bei automatischer Sortierung der Ortsattribute ergeben w¨urde

87

Ort 1.1 Name Jena

Ort 1.2 Name Erfurt Ort 1.3 Name Weimar

Land Th¨uringen

Land Th¨uringen

Restaurant 1.1 Nr Name 1 Zur Noll 2 Poseidon 3 Roter Hirsch

Einwohner 100000

Einwohner 220000

Land Th¨uringen

Art de el de

Ort Jena Jena Jena

Restaurant 1.2 Nr Name 4 Hohe Warte 5 Il Cortile

Art de it

Ort Erfurt Erfurt

Restaurant 1.3 Nr Name 7 Shanghai

Art zh

Ort Weimar

Einwohner 62000

Empfehlung 1.1 Von RNr Erwin 1 Egon 1

Text gut“ ” na ja“ ”

Empfehlung 1.2 Von RNr Text geht so“ Egon 4 ” Empfehlung 1.3 Von RNr Text Maja 7 na ja“ ”

Abbildung 7: Beispiel f¨ur Fragmentierung – Schritt 2

Fragment 1.2 abgespalten. Die Tupel f¨ur ’el’ verbleiben im Restfragment (Fragment 1.1.2). Die Fragmente f¨ur ’Weimar’ und f¨ur ’M¨unchen’ werden nicht weiter unterteilt. Es ist zu bemerken, daß bei dieser Art der Fragmentbildung sowohl (zun¨achst) leere Tabellenpartitionen entstehen k¨onnen (siehe Empfehlung 1.1.2), als auch ein Tupel in mehreren Fragmenten auftreten kann (siehe Ort 1.1.1 und Ort 1.1.2). Da Datenfragmente somit nicht ¨ disjunkt sein m¨ussen, sind die Uberscheidungen zwischen Fragmenten in einem entsprechenden (hierarchischen) Sperrverfahren zu ber¨ucksichtigen [GR93, Rab03]. Ort 1.1.1 Name Land Jena Th¨uringen Ort 1.1.2 Name Land Jena Th¨uringen

Einwohner 100000

Einwohner 100000

Restaurant 1.1.1 Nr Name 1 Zur Noll 3 Roter Hirsch

Art de de

Ort Jena Jena

Restaurant 1.1.2 Nr Name 2 Poseidon

Art el

Ort Jena

Empfehlung 1.1.1 Von RNr Erwin 1 Egon 1

Text gut“ ” na ja“ ”

Empfehlung 1.1.2 Von RNr Text

Abbildung 8: Beispiel f¨ur Fragmentierung – Schritt 3

Abbildung 9 zeigt am Beispiel des Fragment 1.1.1 die SQL-Anfragen zur Beschreibung der Tabellenpartitionen, die mit Hilfe der von DataFrag generierten Auswahlbedingungen erzeugt wurden. 5.2 Metadaten Die Tabelle Fragments in Abbildung 10 enth¨alt die Metadaten zur Verwaltung der Fragmente. In der Tabelle werden f¨ur jedes Fragment und die darin enthaltenen Tabellen und Attribute, wenn vorhanden, die Auswahlpr¨adikate gespeichert. Wir machen uns dabei die spezielle Struktur der vom DataFrag-Algorithmus erzeugten Pr¨adikate zunutze, die in konjunktiver Normalform (KNF) vorliegen und nur =“-Vergleiche mit Konstanten enthal” ten. Die Spalte Condition enth¨alt jeweils die m¨oglichen Attributwerte (Oder-Verkn¨upfung) in einem String-Format, das die einfache Abfrage mit SQL-LIKE erlaubt. Zur Auswahl der Daten eines bestimmten Fragments aus der Datenbank, m¨ussen alle seine Bedingungen

88

Ort:

SELECT DISTINCT o.Name, o.Land, o.Einwohner FROM (Empfehlung e RIGHT OUTER JOIN Restaurant r ON e.RNr=r.Nr) RIGHT OUTER JOIN Ort o ON r.Ort=o.Name WHERE o.Land=’Thuringen’ ¨ AND r.Ort=’Jena’ AND r.Art=’de’;

Restaurant:

SELECT DISTINCT r.Nr, r.Name, r.Art, r.Ort FROM (Empfehlung e RIGHT OUTER JOIN Restaurant r ON e.RNr=r.Nr) RIGHT OUTER JOIN Ort o ON r.Ort=o.Name WHERE o.Land=’Thuringen’ ¨ AND r.Ort=’Jena’ AND r.Art=’de’;

Empfehlung:

SELECT DISTINCT e.Von, e.RNr, e.Text FROM (Empfehlung e RIGHT OUTER JOIN Restaurant r ON e.RNr=r.Nr) RIGHT OUTER JOIN Ort o ON r.Ort=o.Name WHERE o.Land=’Thuringen’ ¨ AND r.Ort=’Jena’ AND r.Art=’de’; Abbildung 9: SQL-Anfragen f¨ur Fragment 1.1.1 (DB2-Notation)

erf¨ullt sein (Und-Verkn¨upfung). Wenn das vom DataFrag-Algorithmus zur Partitionierung verwendete Attribut ein Prim¨aroder Fremdschl¨usselattribut war, so wird dessen Bedingung zum Condition -String des jeweiligen Beziehungspartners hinzugef¨ugt (z. B. Ort.Name = ’Jena’). Damit wir sp¨ater auch Replikationssichtdefinitionen mit Verbunden effizient ausf¨uhren k¨onnen, speichern wir in der Condition -Spalte neben den Attributwerten m¨ogliche Join-Attribute (auch schemafragment¨ubergreifend) anderer Tabellen. So wird z. B. die Beziehung zwischen den Tabellen Restaurant und Ort einmal beim Fremdschl¨usselattribut Restaurant.Ort (Ort.Name ) und einmal beim Prim¨arschl¨ussel haltenden Attribut Ort.Name (Restaurant.Ort ) in der Fragments -Tabelle gespeichert. Im normalen Betrieb wird eine Anpassung der Tabelle nur dann notwendig, wenn sich die Fragmentierung (z. B. durch Einf¨ugen eines Restaurants mit einer neuen Stilrichtung) oder das Schema a¨ ndern. 5.3 Fragmentauswahl Eine der wichtigsten Aufgaben eines Dienstes f¨ur die nutzerdefinierte Replikation ist die Abbildung einer Replikationssichtdefinition auf eine m¨oglichst minimale Menge von Fragmenten. F¨ur Selektionspr¨adikate in KNF die nur =“-Vergleiche von Attributen mit Kon” stanten oder anderen Attributen (f¨ur Verbunde) enthalten, kann diese Aufgabe von dem in Abbildung 11 dargestellten Algorithmus SimplePred2Frag mit Hilfe der Fragments Tabelle geleistet werden. Wie wir bei der Konzeption von H ERMES feststellen konnten, lassen sich fast alle denkbaren Replikatanforderungen, die ja i. d. R. nicht die normalen“ ” Anfragen an die Datenbank ersetzen, in der geforderten Form darstellen [Bau03]. F¨ur die Ausf¨uhrung von SimplePred2Frag nehmen wir an, daß der f¨ur die erste Auswertung der Replikationssichtdefinition verwendete Parser das Selektionspr¨adikat wie vom Algorithmus gefordert aufbereitet. Beispielsweise werden alle Join-Pr¨adikate der Form Attr1 = Attr2 in die semantisch a¨ quivalente Form Attr1 = Attr2 OR Attr2 = Attr1

89

FId 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3

Table Ort Ort Ort Restaurant Restaurant Restaurant Restaurant Empfehlung Empfehlung Empfehlung Ort Ort Ort Restaurant Restaurant Restaurant Restaurant Empfehlung Empfehlung Empfehlung Ort Ort Ort Restaurant Restaurant Restaurant Restaurant Empfehlung Empfehlung Empfehlung

Attribute Name Land Einwohner Nr Name Art Ort Von Rnr Text Name Land Einwohner Nr Name Art Ort Von Rnr Text Name Land Einwohner Nr Name Art Ort Von Rnr Text

Condition +Jena+Restaurant.Ort+Kirche.Ort+ +Th¨uringen+ – +Empfehlung.Rnr+ – +de+ +Jena+Ort.Name+ – +Restaurant.Nr+ – +Jena+Restaurant.Ort+Kirche.Ort+ +Th¨uringen+ – +Empfehlung.Rnr+ – +el+ +Jena+Ort.Name+ – +Restaurant.Nr+ – +Erfurt+Restaurant.Ort+Kirche.Ort+ +Th¨uringen+ – +Empfehlung.Rnr+ – +de+it+ +Erfurt+Ort.Name+ – +Restaurant.Nr+ –

Abbildung 10: Ausschnitt aus Fragments (Fragmente 1.1.1, 1.1.2, 1.2)

u¨ berf¨uhrt. Der Algorithmus erzeugt f¨ur jede Disjunktion der KNF eine Anfrage an die Tabelle Fragments. Jeder Vergleich Tab.Attr = Value in der Disjunktion wird dem Pr¨adikat der SELECT-Anweisung in der Form Table = ’Tab’ AND Attribute = ’Attr’ AND ( Condition LIKE ’%+Value+%’ OR Condition IS NULL ) mit Oder-Verkn¨upfung hinzugef¨ugt. Die Konjunktionen zwischen den Disjunktionen in der KNF realisieren wir durch Bestimmung der Schnittmenge aus allen Disjunktions-Anfragen (INTERSECT ALL). Die Abarbeitung der KNF erfolgt dabei getrennt f¨ur jedes Schemafragment. Die f¨ur die Schemafragmente erzeugten Anfragen werden u¨ ber UNION ALL verkn¨upft. Die Ausf¨uhrung der generierten Anfrage liefert die Nummern der zum Client aufgrund der Replikationssichtdefinition zu u¨ bertragenden Fragmente. Abbildung 12 zeigt ein Beispiel f¨ur eine Replikationssichtdefinition und Abbildung 13 de¨ ren Ubersetzung in eine Anfrage an die Tabelle Fragments durch den SimplePred2Frag-

90

SimplePred2Frag(preprocessed predicate) returns set of FId’s 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14:

for each schemafragment S do for each disjunction in CNF containing attributes which are also contained in S do for each triple (table, attribute, condition) with (table, attribute) exists in S do if wherecond is not empty then wherecond = wherecond + OR “; ” wherecond = wherecond + (f.table = “ + table + AND f.attribute = “ + ” ” attribute + AND (f.condition LIKE ’%+ “ + condition + +%’ OR ” ” f.condition IS NULL))“; od; if QuerySF is not empty then QuerySF = QuerySF + INTERSECT ALL “; ” QuerySF = QuerySF + (SELECT FId FROM Fragments f WHERE “ + ” wherecond + )“; ” od; QuerySF = (“ + QuerySF + )“; ” ” if Query is not empty then Query = Query + UNION ALL “; ” Query = Query + QuerySF ; od; Executing of Query returns set of FId’s

Abbildung 11: Algorithmus SimplePred2Frag CREATE REPLICATION VIEW dtEssenInJenaUndErfurt SOURCE Hermes FOR SELECT r.Name, e.Text FROM Restaurant r, Empfehlung e WHERE e.RNr=r.Nr AND (r.Ort=’Jena’ OR r.Ort=’Erfurt’) AND r.Art=’de’;

Abbildung 12: Anfragebeispiel

Algorithmus. Die Ausf¨uhrung der Anfrage liefert die Fragmente 1.1.1 (FId = 1) und 1.2 (FId = 3) zur¨uck. Die im Beispiel vorgenommene Fragmentierung ist offensichtlich dann g¨unstig, wenn Nutzer ihre Restaurants in der Regel nach Empfehlungen ausw¨ahlen und sich in diesem Zusammenhang nur wenig f¨ur Kirchen interessieren. Es werden nur solche Anfragen effizient unterst¨utzt, die ihre Datenauswahl mit Hilfe der f¨ur die Fragmentbildung verwendeten Partitionierungsattribute durchf¨uhren. Werden beispielsweise Empfehlungen nach ihrem Urheber selektiert, so erh¨alt die mobile Anwendung das komplette Schemafragment 1! Tritt eine solcher Zugriff h¨aufiger auf, so ist eine Anpassung der Fragmentierung notwendig (Partitionierung der Fragmente des Schemafragments 1 nach Empfehlung.Von ). Nicht unerw¨ahnt bleiben sollen die Schw¨achen der hier vorgestellten Realisierung des Fragmentkonzepts. So ist zwar eine Anpassung der Fragmentierung m¨oglich, jedoch erh¨oht die Zahl der verwendeten Partitionierungsattribute den Overhead bei der Fragmentverwaltung und beim Arbeiten mit der Datenbank. UNIQUE-Attribute wie Prim¨arschl¨ussel oder Attribute deren Werteanzahl starken Schwankungen unterliegt, sind f¨ur eine Partitionie-

91

SELECT DISTINCT * FROM ( SELECT FId FROM Fragments f WHERE (f.Table=’Empfehlung’ AND f.Attribute=’RNr’ AND (f.Condition LIKE ’%+Restaurant.Nr+%’ OR f.Condition IS NULL)) OR (f.Table=’Restaurant’ AND f.Attribute=’Nr’ AND (f.Condition LIKE ’%+Empfehlung.RNr+%’ OR f.Condition IS NULL)) ) INTERSECT ALL ( SELECT FId FROM Fragments f WHERE (f.Table = ’Restaurant’ AND f.Attribute = ’Ort’ AND (f.Condition LIKE ’%+Jena+%’ OR f.Condition IS NULL)) OR (f.Table = ’Restaurant’ AND f.Attribute = ’Ort’ AND (f.Condition LIKE ’%+Erfurt+%’ OR f.Condition IS NULL)) ) INTERSECT ALL ( SELECT FId FROM Fragments f WHERE f.Table=’Restaurant’ AND f.Attribute=’Art’ AND (f.Condition LIKE ’%+de+%’ OR f.Condition IS NULL) ) );

Abbildung 13: Beispiel einer Fragmentanfrage

rung nicht geeignet. Auch unterscheidet der Algorithmus zur Zeit nicht zwischen Anfragen mit reiner Leseabsicht (hierbei kann auf eine Integrit¨atssicherung auf Client-Seite verzichtet werden) und solchen mit Schreibberechtigung. L¨osungsm¨oglichkeiten f¨ur diese Probleme sehen wir in der Einf¨uhrung von Fragmenthierarchien, die analog zu hierarchischen Sperren [GR93] verwendet werden, und der Zulassung vertikaler Partitionen.

6 Zusammenfassung und Ausblick F¨ur die Replikatverwaltung der nutzerdefinierten Replikation haben wir den Einsatz von Fragmenten als Verwaltungsgranulat motiviert, einen Fragmentbildungsalgorithmus vorgestellt und eine m¨ogliche Realisierung angegeben. Bei Verwendung von Fragmenten als Replikationsgranulat muß der Replikationsdienst f¨ur jeden mobilen Client nur die von ihm referenzierten Fragmente speichern. Die Auswertung einer Replikationssichtdefinition reduziert sich auf die Abbildung des angegebenen Pr¨adikats auf die Menge der Fragmente. F¨ur Pr¨adikate in KNF, die nur =“-Vergleiche enhalten, wurde ein Abbildungsalgorithmus ” angegeben. Da bei einer g¨unstigen Fragmentierung die Fragmentmenge stabil und unabh¨angig von der Anzahl der mobilen Clients ist, k¨onnen wir eine gute Skalierbarkeit des Fragmentkonzepts erwarten. Am Beispiel des Reiseinformationssystems H ERMES konnte gezeigt werden, daß bereits mit einem automatischen Verfahren g¨unstige Fragmentierungen erzeugt werden k¨onnen. Die weiteren Ziele sind die Implementierung des Fragmentkonzepts inklusive dynamischer Fragmentanpassung in einem Prototyp f¨ur den nutzerdefinierten Replikationsdienst [M¨ul03], Komplexit¨atsbetrachtungen f¨ur Metadaten und Abbildungsalgorithmen sowie deren Erweiterung um Abbildungsfunktionalit¨at f¨ur komplexere Pr¨adikate.

92

Literaturverzeichnis [Bau03]

K. Baumgarten. Konzeption und Schemaentwurf eines interaktiven mobilen Reiseinformationssystems. Studienarbeit, Institut f¨ur Informatik, Friedrich-Schiller-Universit¨at Jena, Juli 2003.

[Fan00]

T. Fangh¨anel. Vergleich und Bewertung kommerzieller mobiler Datenbanksysteme. Studienarbeit, Institut f¨ur Informatik, Friedrich-Schiller-Universit¨at Jena, September 2000.

[GM99]

A. Gupta und I. Mumick. Materialized Views: Techniques, Implementations, and Applications. The MIT Press, Cambridge, Massachusetts, 1999.

[Gol03a] C. Gollmick. Client-Oriented Replication in Mobile Database Environments. Jenaer Schriften zur Mathematik und Informatik Math/Inf/08/03, Institut f¨ur Informatik, Friedrich-Schiller-Universit¨at Jena, Mai 2003. [Gol03b] C. Gollmick. Nutzerdefinierte Replikation zur Realisierung neuer mobiler Datenbankanwendungen. In Tagungsband der 10. GI-Fachtagung Datenbanksysteme f¨ur Business, Technologie und Web (BTW), Leipzig, Band P-26 aus Lecture Notes in Informatics (LNI), Seiten 453–462, Februar 2003. [GR93]

J. Gray und A. Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufmann Publishers, San Francisco, CA, 1993.

[HHB96] A. Helal, A. Heddaya und B. Bhargava. Replication Techniques in Distributed Systems. Kluwer Academic Publishers, August 1996. [HR01]

T. H¨arder und E. Rahm. Datenbanksysteme – Konzepte und Techniken der Implementierung. Springer-Verlag, 2. Auflage, 2001.

[Lie03]

M. Liebisch. Synchronisationskonflikte beim mobilen Datenbankzugriff: Vermeidung, Erkennung, Behandlung. Diplomarbeit, Institut f¨ur Informatik, Friedrich-Schiller-Universit¨at Jena, Februar 2003.

[M¨ul03]

T. M¨uller. Architektur und Realisierung eines Replication Proxy Server zur Unterst¨utzung neuartiger mobiler Datenbankanwendungen. Diplomarbeit, Institut f¨ur Informatik, Friedrich-Schiller-Universit¨at Jena, April 2003.

¨ [Now01] J. Nowitzky. Partitionierungstechniken in Datenbanksystemen: Motivation und Uberblick. Informatik Spektrum, 24(6):345–356, Dezember 2001. ¨ [OV99]

¨ T. Ozsu und P. Valduriez. Principles of Distributed Database Systems. Prentice-Hall, Inc., 2. Auflage, 1999.

[PB99]

S. Phatak und B. Badrinath. Data Partitioning for Disconnected Client Server Databases. In Proc. of the International Workshop on Data Engineering for Wireless and Mobile Access, Seattle, USA, Seiten 102–109. ACM, 1999.

[Rab03]

G. Rabinovitch. Replikatverwaltung bei der nutzerdefinierten Replikation. Studienarbeit, Institut f¨ur Informatik, Friedrich-Schiller-Universit¨at Jena, 2003. Laufend.

[YDN00] W. Yee, M. Donahoo und S. Navathe. A Framework for Designing Update Objects to Improve Server Scalability in Intermittently Synchronized Databases. In Proc. of 9th Intl. Conference On Information And Knowledge Management, USA, 2000, Seiten 54– 61, 2000.

93

Evaluation of a Criticality-Based Method for Generating Location Updates1 ¨ ur Ulusoy∗ , ˙Ilker Yoncacı∗ , Kam-yiu Lam† Ozg¨ ∗

†

Department of Computer Engineering, Bilkent University, Ankara, Turkey. Department of Computer Science, City University of Hong Kong, Hong Kong.

E-mail: {oulusoy, yoncaci}@cs.bilkent.edu.tr, [email protected] Abstract: In a mobile computing environment, the result of a location-dependent query is determined by the current location of the user who has issued the query, as well as the locations of moving objects on which the query has been issued. If the location-dependent query is submitted as a continuous query, the result of the query changes as the user and/or the queried moving objects move. The result of a locationdependent continuous query (LDCQ) can be provided to the user as a set of tuples < S, begin, end > indicating that object S satisfies the query from time begin to time end. The accuracy and timeliness of results of LDCQs have been studied in a previous work by employing an adaptive monitoring method (AMM) that manages the locations of moving objects. In this paper, we propose a categorized adaptive monitoring method (CAMM) which is based on AMM, and which allows users to specify various criticality levels for LDCQs. The aim of CAMM is to provide higher levels of accuracy for query results as the criticality of the query increases, without significantly increasing the wireless bandwidth requirements. We provide a simulation model with multiple criticality levels for LDCQs and evaluate the performance of the proposed method.

1 Introduction A typical mobile database system can be characterized by a database server, a collection of moving objects and clients which can move while retaining their network connection through wireless links. Mobile clients represent users equipped with mobile units that can communicate and generate queries to be processed by the database server. When a user submits a location-dependent query, the answer to the query depends on both the location of the user and the locations of the moving objects on which the query has been issued [Si97, Wo97]. A location-dependent query can become more difficult to process when it is submitted as a location-dependent continuous query (LDCQ) for which the answer changes as the user and/or the queried objects move. Such a query is evaluated continuously by the database server for a specified period of time and the results changing dynamically can be transmitted to the requesting user. Although there exist a considerable amount of work in the literature exploring LDCQs, none of those works investigates the issue of processing LDCQs that might be characterized by different priorities or criticalness. In our work, we deal with the processing of LDCQs based on a categorization of the queries according to their user-defined criticality. We believe that some of the queries in a mobile computing environment may need to produce more accurate answers than the others, and thus they are considered to be more 1 This

¨ ˙ITAK) under grant number 102E021. research is supported by the Research Council of Turkey (TUB

94

critical. For example, the LDCQ “check for a free ambulance within 5 kilometers (to pick up a patient) of the hospital” should be more critical than the LDCQ “check for a free taxi within 10 kilometers (to pick a passenger)”. In the former case, in order to cope with the emergency as soon as possible, the correct determination of ambulance locations is very crucial. Producing accurate results for LDCQs is a difficult goal to achieve in a mobile environment, which requires an efficient management of location information. In this paper, we present a new method to monitor the locations of moving users/objects based on criticality of LDCQs so that higher levels of accuracy can be achieved for the results returned to the queries categorized with higher criticality. We also provide a detailed simulation model of a mobile computing system that supports processing of LDCQs associated with different criticality categories. In the next section, we briefly discuss the background and related work. We describe in the same section a location update generation method, called Adaptive Monitoring Method (AMM) which our work is based on. We introduce the criticality-based Categorized Adaptive Monitoring Method (CAMM) in Section 3. We present the simulation model and performance evaluation results in Section 4. Concluding remarks are provided in the last section.

2 Background and Related Work The problem of data dissemination using data broadcast and some possible solutions to it are studied in [AFZ96, Da97, FR98, IVB97]. The issues in cache invalidation and management are addressed in a number of articles such as [BJ96]. The problems associated with the indexing of dynamic attributes (such as location) in a mobile database system are addressed in [TUW98]. In that work, a variant of the quadtree structure for indexing dynamic attributes is proposed and an algorithm for generating the index periodically that minimizes the CPU and disk access cost is provided. In [KGT99], algorithms are proposed for indexing mobile objects in one and two dimensions using dynamic external memory data. In [WL01], a stochastic model is provided to compute the optimal update boundary for the distance-based location update algorithm. Optimization issues in processing queries in mobile database systems are discussed in [KZ98]. In that work, the authors present a cost model for query optimization incorporating location information. Issues related to location dependent query processing for moving objects have been addressed in a number of studies (e.g., [Si97, DK98, Wo99, RD00, SDK01]). In [Si97, Si98], a data model called M oving Objects Spatio-T emporal (MOST) is introduced for databases containing position information about moving objects. MOST models the position of a moving object as a function of time. Therefore, the answer to the query: “retrieve the current position of the object S” in the MOST data model is different for time points t1 and t2 even if the value of the attribute specifying S’s position has not been explicitly updated.

95

Consider the LDCQ “display motels within 5 miles of my position” issued by a person driving a car. When such a query is entered in the MOST data model, the query is evaluated once and a set of tuples is returned as the answer. The answer set consists of tuples < S, begin, end > indicating that object S is the answer of the query from time begin to time end. Once the answer to the query is computed, a decision has to be made in order to determine the time to send the tuples in the answer set to the user. In [GU00], we present a variety of approaches for the transmission of the tuples in the answer set of a LDCQ. In [La01], we provide the Adaptive M onitoring M ethod (AMM) for managing the locations of moving objects. AMM aims to provide high level of accuracy to the results of LDCQs. In this method, moving objects generate updates to report their current locations to the database server. The database server determines update generation thresholds for the mobile clients that have submitted LDCQs and for the other moving objects in the system. Location of a mobile client is updated more frequently, if it has submitted a LDCQ and the query is still being processed. In determining a location update for a moving object, AMM considers the deviation of the actual and computed location values of the object. If the deviation is greater than a certain update threshold, a location update is generated. AMM uses threshold bounds, called upper and lower threshold bounds to specify an appropriate update threshold value for each object. The objects which satisfy the condition of a LDCQ currently, or will satisfy the condition in the near future are assigned smaller update threshold values. Therefore, the locations of such objects are monitored more closely to get precise answers to the related LDCQs. More specifically, the update threshold of a moving object S is determined based on the begin time of the object, by using the following formula: (1)

H − (H − L) × e−δt where H : Upper Update Threshold bound, L : Lower Update Threshold bound, and δt : begin time of object S - current time.

A moving object might be in the answer set of more than one LDCQ. In that case the update threshold of the object is set to be the minimum of all the thresholds computed from all the related LDCQs. As an example, suppose that a mobile client has submitted a LDCQ, and in the first evaluation of the query at current time 20, the following answer set is generated: {< S1 , 30, 40 >, < S2 , 25, 35 >, < S3 , 50, 60 >, < S4 , 20, 30 >} In Figure 1, the update threshold values of mobile objects S1 , S2 , S3 and S4 determined by using Equation (1) are shown. In the update threshold formula (1), an exponential distribution is assumed for illustration. It is possible to adapt different functions for different systems with the consideration of the location update cost and the cost of missing the information to the clients.

96

Figure 1: Generation of update thresholds in AMM.

3 A Criticality-Based Method for Generating Location Updates If a query result provides false information, either in begin/end times of objects, or in value, the query result is considered to be incorrect. In [La01], the correctness of a result is defined based on the begin time of the result. The actual begin time of an object is defined as the time when the object starts to satisfy the conditions of a query. The actual begin time of an object may be different from the begin time of the corresponding tuple for the same query since the database may contain outdated information about the current location of the object. A mobile client may observe incorrect result if: (1) the actual begin time of an object for a query is earlier than the begin time of the result tuple produced for that object (this problem is called missed inf ormation); or (2) the actual begin time of an object for a query is later than the begin time of the result tuple produced for that object (this problem is called f alse inf ormation). In the first case, although the moving object satisfies the query, the requesting client is not aware of that situation (Figure 2). In the second case, the requesting mobile client is informed that an object meets the condition of its query but actually it does not. Message transmission delays and outdated database state are the major causes for those incorrect results.

97

Figure 2: Missed and false information.

3.1 Motivation Some queries in mobile computing systems can be characterized to be more critical than the others, due to the lower levels of tolerance to the inaccurate query results to mobile clients. In order to cope with the criticality of the underlying application (e.g., ambulatory service of a hospital), timely and accurate results should be provided to such queries. We propose a location update generation method, called Categorized Adaptive M onitoring M ethod (CAMM), for the moving objects with the aim of maintaining high levels of accuracy for the results of LDCQs that are characterized by high levels of criticality. In this method, n criticality levels are defined for the clients generating LDCQs. A client may generate LDCQs with one of the criticality categories of its own criticality level. For example, ambulatory service of a hospital may operate in a mobile environment with criticality level n=4 and may generate a LDCQ with a criticality category of either 1, 2, 3 or 4 in that level. Update threshold values of moving objects in the answer set of a query are determined by the criticality category of the query. Our emphasis in CAMM is providing relatively timely and correct results to LDCQs considering their criticality categories.

3.2 Determination of Location Update Thresholds In implementing our method CAMM, we assume that moving objects generate updates to report their current locations to the database server which maintains a database containing the data items issued with the moving objects (including their location information). Each mobile client may generate LDCQs with different criticality categories. We have defined n=4 levels of criticality for the mobile clients generating LDCQs. The result set produced for the LDCQ of a client in criticality level 1 is exactly same as that produced by AMM. A client with criticality level 2 may generate a LDCQ either with a criticality category 1 or criticality category 2. CAMM can generate more accurate and timely results to a LDCQ with criticality category 2 than that to a LDCQ with criticality category 1.

98

Similar to AMM, CAMM also uses location update threshold bounds for determining update thresholds of moving objects. If the deviation between the actual and computed values of the location of an object is greater than the update threshold of the object, then a location update is generated for that object. Location update threshold of a moving object S is determined by the following formula: (2)

Cup − (Cup − Clw ) × e−δt where, Cup : Criticality Category Upper bound Clw : Criticality Category Lower bound δt : begin time of object S - current time

Cup = H − (Cc − 1)



H −L Cl



(3)

(4)

Clw = L where, H : Upper Update Threshold bound L : Lower Update Threshold bound Cc : Criticality Category of the query generated Cl : Criticality Level of the client generating the query

The idea behind this formulation is to map the threshold bounds interval of AMM to n equal subintervals for n different criticality categories assigned to the queries submitted by a mobile client with criticality level n. As the criticality category increases, the level of the subinterval bounding the update thresholds becomes lower. As an example, suppose that a client with criticality level Cl =4 has submitted a LDCQ with criticality category Cc =2. In the first evaluation of the query at time t=10, the tuples and update thresholds generated for moving objects S1 , S2 and S3 are shown in Figure 3.

4 Performance Experiments We have designed and implemented a detailed simulation model to study the performance of the proposed method, CAMM, as compared to AMM which was already proven to perform better than the well-known approaches for location update generation in mobile systems [La01]. The simulation program was written in CSIM18 [Sc86]. The simulation model and the performance results are presented in the following subsections.

99

Figure 3: An example for the generation of location update thresholds in CAMM.

4.1 Simulation Model We have extended the performance model that we used in our previous work [GU00, La01] to support modeling of processing LDCQs with different criticality categories. Our simulation model consists of three basic components: • Server Model • Wireless Communication Network Manager • Mobile Client Model The server model has two modules corresponding to a query processor and a resource manager. The query processor processes queries received from clients through the wireless communication network. It also updates the answer set of LDCQs whenever a change occurs in location of related objects. The resource manager is responsible for scheduling CPU and database accesses. The wireless communication network manager module carries all the traffic between the server and the client. The mobile client model consists of three components: a resource manager, a query generator, and an update generator. The resource manager models the CPU scheduling at the client machine for processing queries and transmitting them to the server. The query generator generates queries, while the update generator generates location updates of moving objects using the update threshold values determined by CAMM. Key parameters of our simulation model are listed in Table 1 together with their default values used in experiments. The values of the simulation parameters were chosen so as to be comparable to the previous related simulation studies such as [GU00, La01]. It was not intended to simulate a specific application; instead the parameter values were chosen to yield a communication and query processing load high enough to observe the differences

100

PARAMETER Number of moving objects Number of objects which may generate LDCQs Maximum number of objects that can satisfy a query Maximum number of criticality levels Lifetime of a LDCQ Mean think time between queries Message transmission time Time for processing a tuple Lower update threshold limit Upper update threshold limit

VALUE 200 50 20 4 240 - 360 sec 1000 sec 0.1 - 0.2 sec 0.05 - 0.1 sec 5 sec 40 sec

Table 1: Default parameter settings

between the performances of location update methods in providing correct information to LDCQs. In our experiments, we are concerned with performance trends rather than exact performance predictions. Criticality level of a client is chosen randomly from the set of all possible criticality levels. Assignment of criticality category to a query submitted by a client with criticality level i again follows a uniform distribution; i.e., the criticality of the query is chosen randomly from the set {1, ..., i}. A number of simulation experiments have been conducted to study the performance of CAMM as a function of incorrect inf ormation rate (IIR) which is the number of occurrences of false and missed information over the total number of tuples generated. As our main performance measure, IIR indicates the capability of the system in providing correct information to LDCQs generated by mobile clients.

4.2 Evaluation of the Impact of Location Update Threshold We first investigate the performance of our location update method CAMM under varying values of the lower limit of location update threshold by changing the corresponding parameter value from 5 seconds to 40 seconds. Figure 4 presents the incorrect information rate (IIR) results obtained for both AMM and CAMM. It can be observed from the figure that the performance of CAMM is better, in general, than that of AMM, for various criticality levels tried with CAMM. All of the curves displayed are V-shaped, and this situation can be explained as follows. The poor performance obtained with very small threshold values is due to the heavy update workload. Obviously, under such high levels of update workload, most of the system resources are devoted to process the updates from moving objects due to small threshold values and the system is not able to generate timely response to the continuous queries from mobile clients. Consistent with our expectation, this situation causes an increase in incorrect (i.e., missed and false) information rate. When

101

35.0

IIR

AMM CAMM Level 2 CAMM Level 3 CAMM Level 4

25.0

15.0

5

15 25 Lower Update Threshold

35

Figure 4: Incorrect Information Rate vs lower limit of location update threshold

a considerably large threshold value is used, on the other hand, moving objects update their location with larger time intervals and this also causes the probability of providing incorrect information to mobile clients to increase. In general, the best performance in terms of IIR is achieved when CAMM method with criticality level 2 is employed. In Figure 5, IIR evaluation of criticality level 2 is provided to show the difference between the performance of category 1 queries and category 2 queries (which are more critical). Obviously, as expected, criticality category 1, which has higher upper threshold limit, produces higher IIR values than those of criticality category 2. So, more accurate results are provided to more critical category 2 queries.

4.3 Evaluation of the Impact of Continuous Query Lifetime In the experiments of this section, we investigate the performance impact of the lifetime of LDCQs as the lower limit of update threshold is varied. We conducted the first experiment by reducing the lower and upper bounds of query lifetime to 60 and 240 seconds, respectively. In the second experiment, these bounds were increased to 240 and 600 seconds, respectively. The results obtained for CAMM with criticality level 2 are displayed in Figure 6. The results for short and long duration queries are presented together with those obtained with default settings of the lower and upper bounds of query lifetime; i.e., 240 and 360 seconds, respectively. As expected, shorter query lifetime leads to lower IIR results due to the reduced system workload. As the workload decreases, the system resources are devoted to generate more timely response to the continuous queries from mobile clients.

102

30.0 25.0

IIR

20.0 15.0 Category 1 Category 2

10.0 5.0

5

15 25 Lower Update Threshold

35

Figure 5: Incorrect Information Rate values for criticality level 2 queries in two different categories

26.0 CAMM Level 2 CAMM Level 2 with shorter queries CAMM Level 2 with longer queries

IIR

24.0

22.0

20.0

10

20 30 Lower Update Threshold

40

Figure 6: Incorrect Information Rate results obtained with different settings of continuous query lifetime

103

25.0 23.0

IIR

21.0 19.0

AMM CAMM Level 2 CAMM Level 3 CAMM Level 4

17.0 15.0

10

30 50 % of Mobile Clients

70

Figure 7: Incorrect information rate vs the percentage of mobile clients over the total number of moving objects

4.4 Evaluation of the Impact of Number of Mobile Clients We also investigated the performance impact of the number of mobile clients which may generate LDCQs. Figure 7 presents the IIR results obtained when the minimum location update threshold is fixed at 12.5 seconds and the percentage of the number of mobile clients within all mobile objects is varied from 5% to 75%. Our observations with the previous experiments are also valid in this experiment. The best results in terms of IIR are obtained with the criticality level 2 of CAMM. Although CAMM with any criticality level produces a bit higher IIR with larger number of mobile clients, it still beats AMM even with the largest ratios of mobile clients over the total number of moving objects. The relative performance of AMM and different criticality levels of CAMM is not affected by the number of mobile clients.

5 Conclusions In this paper, we have presented a new method, called Categorized Adaptive Monitoring Method (CAMM), for the generation of location updates in mobile computing systems. The method aims to increase accuracy and timeliness of the results of location dependent continuous queries, as the criticality of the queries increases. It enables the system to have criticality levels for both the clients which can submit queries, and the queries submitted, based on the requirement of the level of accuracy for query results. It was shown through performance experiments that a considerable improvement in the performance in terms of incorrect information rate is possible with CAMM, especially when only two levels of criticality are considered.

104

References [AFZ96] Acharya, S.; Franklin, M.; Zdonik, S.: Disseminating Updates on Broadcast Disks. Proc. International Conference on Very Large Databases, 1996, pp.354-365. [BJ96] Bukhres, O.; Jing, J.: Analysis of Adaptive Caching Algorithms in Mobile Environments. Information Sciences, vol.95, no.1, 1996, pp.1-27. [Da97] Datta, A. et. al.: Adaptive Broadcast Protocol to Support Power Conservant Retrieval by Mobile Users. Proc. International Conference on Data Engineering, 1997, pp.124-133. [DK98] Dunham, M.H.; Kumar, V.: Location Dependent Data and its Management in Mobile Databases. Proc. International Workshop of Database and Expert Systems Applications, 1998, pp.414-419. [FR98] Fernandez, J.; Ramamritham, K.: Adaptive Dissemination of Data in Real-Time Asymmetric Communication Environments. Proc. Euromicro Conference on Real-Time Systems, 1998, pp.195-203. ¨ Transmission of Continuous Query Results in Mobile Computing [GU00] G¨ok, H. G.; Ulusoy, O.: Systems. Information Sciences, vol.125, no.1-4, 2000, pp.37-63. [IVB97] Imielinski, T.; Viswanathan, S.; Badrinath, B.R.: Data on Air: Organization and Access. IEEE Transactions on Knowledge and Data Engineering, vol.9, no.3, 1997, pp.353-372. [KGT99] Kollios, G.; Gunopulos, D.; Tsotras, V.J.: On Indexing Mobile Objects. Proc. Principles of Database Systems, 1999, pp.261-272. [KZ98] Kottkamp, H.; Zukunft, O.: Location-Aware Query Processing in Mobile Database Systems. Proc. ACM Symposium on Applied Computing, 1998, pp.416-423. [La01] Lam, K. Y. et. al.: An Efficient Method for Generating Location Updates for Processing of Location-Dependent Continuous Queries. Proc. International Conference on Database Systems for Advanced Applications, 2001, pp.218-225. [RD00] Ren, Q.; Dunham, M.H.: Using Semantic Caching to Manage Location Dependent Data in Mobile Computing. Proc. International Conference on Mobile Computing and Networking, 2000, pp.210-221. [Sc86] Schwetman, H. D.: CSIM: A C-Based, Process-Oriented Simulation Language. Proc. Winter Simulation Conference, 1996, pp.387-396. [Si97] Sistla, A. P. et. al.: Modeling and Querying Moving Objects. Proc. International Conference on Data Engineering, 1997, pp.422-432. [Si98] Sistla, A. P. et. al.: Querying the Uncertain Position of Moving Objects. Temporal Databases: Research and Practice. Lecture Notes in Computer Science (Springer Verlag), vol.1399, 1998, pp.310-337. [SDK01] Seydim, A.Y.; Dunham, M.H.; Kumar, V.: Location Dependent Query Processing. Proc. ACM International Workshop on Data Engineering for Wireless and Mobile Access, 2001, pp.47-53. ¨ Wolfson, O.: A Quadtree Based Dynamic Attribute Indexing [TUW98] Tayeb, J.; Ulusoy, O., Method. The Computer Journal, vol.41, no.3, 1998, pp.185-200. [Wo97] Wolfson, O. et. al.: Location Management in Moving Objects Databases. Proc. International Workshop on Satellite-Based Information Systems, 1997, pp.7-13. [Wo99] Wolfson, O. et. al.: Updating and Querying Databases that Track Mobile Units. Distributed and Parallel Databases, vol.7, no.3, 1999, pp.257-287. [WL01] Wong, V. W. S.; Leung, V. C. M.: An Adaptive Distance-Based Location Update Algorithm for Next Generation PCS Networks. IEEE Journal on Selected Areas in Communications, vol.19, no.10, 2001, pp.1942-1952.

105

Towards Trie-Based Query Caching in Mobile DBS∗ Hagen H¨opfner and Kai-Uwe Sattler Otto-von-Guericke-University of Magdeburg Department of Computer Science Institute of Technical and Business Information Systems P.O. Box 4120, 39016 Magdeburg, Germany {hoepfner | kus}@iti.cs.uni-magdeburg.de

Abstract: The usage of mobile equipment like PDAs, mobile phones, Tablet PCs or laptops is already common in our current information society. Typically, mobile information systems work in a context dependent (e.g. location dependent) manner which means that queries differ mostly only in some context-related predicates on the same set of relations. Considering this characteristics, query processing on mobile devices can take benefit from results of previously performed queries by using a query cache. In this paper, we describe such a caching approach based on a trie structure and organized by the query predicates which are associated with the corresponding result sets. We present the cache structure and the process of query rewriting as well as discuss implementation issues.

1 Introduction and Motivation On stationary computers managing large and complex data sets is often done by database management systems. Due to the increasing complexity of mobile information systems, DBMS-techniques on mobile devices become more important. Though mobile devices are quite powerful, compared to stationary computers they are called “lightweight”. Nearly all available enterprise databases (e.g. Oracle, DB2) are offered as functionally limited lite versions usable on lightweight devices [IBM02, Ora02b, iAn03, IBM03]. Today’s mobile radio technologies are still slow and expensive. Therefore, time based payment models are counterproductive considering a permanent connection. But also volume based payment models associated with large data sets cause high costs. Furthermore, technical problems (net overload, electrostatic shield, etc.) can result in disconnections. Thus, there is the need for storing necessary data directly on the mobile hosts. In mobile information systems such data sets (replica sets) are requested by the user via the mobile device from a database server [Gol03] and afterwards locally stored at the mobile device. Therefore, locally available replica sets can be considered as cache. New queries ∗ This

research is supported by the DFG under grant SA 782/3-2.

106

should reuse the cached data in order to minimize wireless (expensive and slow) communication. Only locally unavailable data should be requested from the database server. Designing such a cache comprises two central tasks: Query Rewriting: Queries, which are executed on the mobile system, have to be rewritten in order to use the cache. If a query is not completely answerable by the cache, it has to be decomposed into sub-queries in such a manner that only a minimal subset of the complete result must be requested from the database server. Cache Replacement: If there is no more available memory on the mobile device, no more replica sets can be cached. Therefore, parts of the cache contents have to be deleted. The decision to remove a subset of the cached data must consider possible future queries. That means, the remaining state of the cache must fit upcoming queries as good as possible. In this paper we present first ideas of a cache which uses a trie1 indexing schema to provide an efficient access to the cached replica sets. We take advantage of the special characteristics of mobile database systems: • In mobile environments queries are mostly executed in a context dependent 2 manner. That means that queries in mobile information systems reflect the elements of the context (e.g. location, time). For example, a person, who is visiting London and is using a mobile information system offering information about cultural events, will, in all likelihood, query current (time dependency) information of events performed in London (location dependency). Such systems are often called “location dependent services”. But the context of a user contains a lot of other elements [LH01] (e.g. used hardware, group membership, task to handle). • Mobile information systems consider the high cost of wireless data transmission. Therefore, a lot of “small” queries are used, which can be answered by a “small” but exact result set. If the user needs more detailed information, additional refined queries are issued. We use these special characteristics of queries in mobile informations systems for indexing the cache on a mobile device but consider only queries which must not include aggregate functions or joins. In addition, we do not consider here cache replacement and cache coherency. Cache coherency is a big problem especially in mobile environments but we postpone this aspect to future work. In the face of replacing cache entries with new data our approach is compatible with know techniques like LFU (least frequently used) or LRU (least recent used). Therefore, the cache entries have to be enhanced by reference counters or timestamps, respectively. But, having regard to an extended query language as presented in [HS03b] we can denote support for context dependent techniques here. 1 A trie [Fre59] is a tree for storing strings in which there is one node for every common prefix. The strings are stored in extra leaf nodes (see also [Bla98]). In our case, we replace string prefixes by query prefixes (conjunctions of predicates). 2 based on the context of the user and/or the context of the mobile device

107

There are several publications (e.g. [DFJ+ 96], [GG99]) demonstrating that semantic caches are more effcient than time or reference based caching approaches. In mobile database systems the most important approach of semantic caching is the LDD-cache [RD00] (based on [DK98]). In [RD99] a cluster extension of the LDD-cache is presented which increases its performance. In contrast to this approach we provide an index structure that allows to access cached information more efficient. The remainder of this paper is structured as follows: After presenting the index and cache structure in Section 2, we discuss our query processing and query rewriting approach in Section 3. We also compare our trie-based query-cache to the LDD-cache in Section 3. Finally, we discuss different implementation variants in Section 4. Because of the given space limitations we do not discuss any cache replacement strategy in this paper.

2 Query Cache Structure The main issue of a query cache is the granularity of the cache entries. In contrast to normal database management system caches, which store logical pages, query caches store query results (relation or fragments of relations respectively). Therefore, the queries are used as access keys. Now it is possible to check new queries, whether they can be answered from the cache. At this, we distinguish between the following four cases: 1. The same query has been performed already and its result is still stored in the cache. 2. A query, which results in a superset of the requested result, has been performed already and its result is still stored in the cache. Therefore, the new query can be locally answered by using additional operations (e.g. selection). Case (1) can be considered as a special case of this case. 3. A cached query and a new query overlap, i.e., a subset of the result can be answered by the cache. Only the non-overlapping subset must be requested from the database server. 4. There is no compatible query in the cache. Furthermore, we have to take into account, that a new query may be answered by a combination of cache entries. Regarding to these requirements our cache structure has to support an efficient search for appropriate entries. Based on this and on the special characteristics of mobile information systems we chose the following cache structure: A cache entry always corresponds to a fragment of a relation – thus to a set of tuples. The entries are indexed by a trie structure which represents the query. For that purpose we represent queries in a standardized calculus notation, i.e. in conjunctive normal form. Predicates are ordered in a lexicographic manner: at first relation predicates ri , then the selection predicates pj (also lexicographically ordered). Relation predicates describe the considered schema of a relation. For example, buildings(name) corresponds to SELECT name FROM buildings. Selection

108

predicates corresponds to a WHERE-clause, respectively (e.g. buildings.x>200 is a predicate representation of WHERE buildings.x>200). A query Q = {r1 ∧ r2 ∧ · · · ∧ rm ∧ p1 ∧ p2 ∧ · · · ∧ pn } can be represented as a sequence of predicates hr1 , r2 , . . . , rm , p1 , p2 , . . . , pn i, where ∀i, j ∈ 1 . . . n, i < j ⇒ pi / pj as well as ∀i, j ∈ 1 . . . m, i < j ⇒ ri /rj (/ means “lexicographically smaller”) holds. Obviously, this query language is not strong relational complete, but is restricted to a subset of calculi which is sufficient for the realization of context based, mobile information systems. For a trie that means, that edges represent predicates and nodes represent links to the caches fragments. A path P = r1 r2 · · · rm p1 p2 · · · pn in the trie (from the root to any node) corresponds to the query QP = {r1 ∧ r2 ∧ · · · ∧ rm ∧ p1 ∧ p2 ∧ · · · ∧ pn }. Thus, the result of a query QP represented by the path P can be found in the cache as the entry addressed by P . This cache approach is not limited to exact query matches. We support also the other two cases (see above) by following a path in the trie predicate by predicate. If a node linking a fragment is reached and if there are more predicates in the new query, the new query can be answered by running it on the linked fragment. Otherwise, if no node linking a fragment is reached so far but all predicates of the new query were used, this new query can be partially answered by combining all fragments linked by child nodes of the current one. Therefore, the query processor must generate a compensation query which request the missing sub result and combines it with the cached sub result.

3 Cache-supported Query Processing After the presentation of cache and index structures in the previous section we discuss the cache-supported query processing in the following. The central point is the query rewriting phase: the problem of splitting a query into two sub-queries in such a manner, that a local sub query can be performed on the cache and a remote query (compensation query) can be sent to the database server and performed there. The main focus is the minimization of the amount of data retrieved from the database server and thus the minimization of transfer costs. Query rewriting is based on correspondence relations between queries. Following the four cases presented in the previous section we can distinguish correspondence relations of a query P and another query Q as follows. For simplification we assume for now, that P and Q contain the same relation predicates, i.e. only the selection predicates are taken into account. (A) P ≡ Q means, that the query can3 be directly performed on the cache. Therefore, obviously equivalence of all predicates must hold: hp1 , . . . , pn i ≡ hq1 , . . . , qn i ⇔ ∀i = 1 . . . n : pi ≡ qi 3 granted

that all attributes used by the filter condition are included into the cached result

109

(B) P @ Q means, that Q can be answered by the cache, but an additional filter condition filter(P, Q) is required. This case can be distinguished into the following sub cases: (a) Q consist of more predicates: hp1 , . . . , pm i @ hq1 , . . . , qn i ⇔ m ≤ n ∧ ∀i = 1 . . . m : pi ≡ qi . The corresponding filter condition is: filter(P, Q) = hqm+1 , . . . , qn i. (b) Q consist of more restrictive predicates than P . A predicate q is more restrictive than a predicate p (both defined on an attribute A) if q holds for less tuples than q whereas a domain wide equipartition of the attribute values is assumed. For instance, a > 50 is more restrictive than a > 10, written as a > 50 ≺ a > 10. Operators used for comparison strongly depend on the involved attribute types (coordinates, time, date, integer, etc.). In [HS03a] we have presented an approach, that uses type dependent “distance” functions (so called ξ-functions). These functions can also be used in order to compare the restrictivity of selection predicates. hp1 , . . . , pm i @ hq1 , . . . , qn i ⇔ ∀i = 1 . . . k < n : pi = qi ∧ ∀j = k + 1 . . . n : qj ≺ pj Thus, the filter condition is the combination of the more restrictive predicates: filter(P, Q) = hqk+1 , . . . , qn i (C) P A Q means, that Q consists of less predicates or Q is less restrictive than P . As a result Q can be partially answered by the cache. For getting the whole result, a compensation compensation(P, Q) must be performed on the database server. This case can be distinguished into two sub-cases, too: (1) hp1 , . . . pn i A hq1 , . . . qm i ⇔ m < n ∧ ∀i = 1 . . . m : pi = qi Therefore, the result of a compensation query has to contain all tuples that are not included in the result of P but belong to the result of Q: compensation(P, Q) = hq1 , . . . qm , ¬pm+1 , . . . ¬pn i (2) hp1 , . . . , pn i A hq1 , . . . , qn i ⇔ ∀i = 1 . . . k < n : pi = qi ∧ ∀j = k + 1 . . . n : pj ≺ qj Thus, the compensation query is: compensation(P, Q) = hq1 , . . . qn , ¬pk+1 , . . . ¬pn i (D) P 6≡ Q means, that there are no consensuses between the predicates of the queries. ∀i = 1 . . . k < n : pi 6≡ qi Thus, the cache entries belonging to P are not usable for answering Q.

110

Q

P

P

Q

P

P

Q

Q

P P

Q

Q

P Q

caption: P

P

cached query Q

Q

new query

relation predicates selection predicates cached tuples

DB on server

P Q

Figure 1: Relations between a cached query Q an a new query P

Considering this correspondence relations (see also Figure 1) we are able to modify a given query in order to use the cache now. The idea is to collect the nodes, that link appropriate cache entries, while passing the trie. The result of this procedure are candidate sets of nodes corresponding to the cases mentioned above. Because we can consider case (A) as case (B) with an empty filter condition, Algorithm 1 uses only two sets CS AB and CSC . If both sets are empty, case (D) is given. The trie is traversed by using the recursive procedure find candidate nodes shown as algorithm 2. The generation of the candidate sets is followed by handling the cases. The function path used in the algorithm returns the query which corresponds to the path from root of the trie to a given node.

Algorithm 1: trie-based Rewriting given: query Q trie with root node CSAB := {} CSC := {} find candidate nodes (0, root) if CSAB = {} ∧ CSC = {} then perform Q remotely else if CSAB 6= {} then

111

Node n ∈ CSAB P := path(n) Q0 := filter(P, Q) perform Q0 on the cache-entry associated with n else if CSC 6= {} then n := min cost(CSC ) P := path(n) Q0 := compensation(P, Q) do Q0 ∪ cache-entry associated with n fi Because there may exist more than one candidate node which could be used for answering a query, the best node have to be detected (see below). Afterwards the filter and the compensation query is computed and performed. Algorithm 2 implements the traversing of the trie. Starting at the root node all edges, i.e. all predicates, will be checked. If a predicate p in the trie is equal to or less restrictive than the corresponding predicate of the new query, all child nodes child p (n) are tested. But if both predicates are contradictorily, the search will stop. If none of these alternatives hold 4 then the predicate is ignored and the search continues with all child nodes. If a checked node contains a link to a cache entry, the path and thus the query is reconstructed first. Afterwards the correspondence relation between the query and the given new query is computed incrementally. This is possible because the predicate has been checked already while running the algorithm. For the simplification of the presentation we skip a more detailed discussion of this aspect here. If a consensus is found, the actual node is added to one of the two candidate sets CSAB or CSC , respectively. If P ≡ Q holds, the search stops immediately.

Algorithm 2: Traversing the trie find candidate nodes (level, node) if cache-entry associated with node available then P := path (node) if P ≡ Q then CSAB := { node } return else if P @ Q then CSAB := { node } else if P A Q then CSC := CSC ∪ { node } fi 4 this

case corresponds to P A Q

112

forall p ∈ predicates(n) do if p ≡ qlevel ∨ qlevel  p then find candidate nodes (level+1, childp (node)) else if ¬(p ∧ qlevel ) then /* unaccomplished condition */ return else /* ignore predicate p */ find candidate nodes (level+1, childp (node)) fi od A path is chosen cost dependently from the set of alternative paths. A complete estimation of all costs (e.g. based on cardinalities or histograms) causes an essential additional expense. Because of the light-weighty of mobile devices only the maximal size of cached fragments is taken into account. So far we have assumed that P = {r1 ∧ r2 ∧ · · · ∧ rm ∧ p1 ∧ p2 ∧ · · · ∧ pn } and Q = {k1 ∧ k2 ∧ · · · ∧ ku ∧ q1 ∧ q2 ∧ · · · ∧ qv } differ only in selection predicates, i.e. m = u; ∀i ∈ 1 . . . m, ri = ki . Based on the previous ideas, now we discuss shortly the consequences of allowing differences between relation predicates. That means that queries can contain joins, too. We assume that R is the set of relation predicates used by P and K is the set of relation predicates used by Q. Thus, there exist four cases: (E) R ∩ K = ∅, means, that both queries use different relations. Q must be sent to the database server. (F) R = K, means, that both queries use the same relations. Q could be answered locally by the cache but a detailed check of the selection predicates is required (see above). (G) R ⊂ K, means, that the new query uses Q additional relations. A compensation query must be generated in order to query the missed tuples from the database server. The join can be computed on the mobile device. (H) K ⊂ R, means, that the new query Q uses some of the relations used by R. Q could be answered locally by the cache but a detailed check of the selection predicates is required (see above). For definitely extending the presented approach by allowing differences between relation predicates we have to modify algorithm 1 accordingly.

113

h id 1 2 3

name St. Maria Hospital University Hospital Dr. Koch Hospital

phone 3920811 1237654 8877365

fax 4433276 9912347 1253432

address P.O. Box 1100 18 Avenue of The Stars 5 Third Avenue

Table 1: The Relation hospitals

s id 1 2 3 4 5

name Ada Lovelace School 1st Primary School Ascaneum ECOLE Gustav-Nitsche School

form Grammar School Primary School Grammar School Primary School Secondary School

phone 234555366 355355534 234234234 445613334 464663698

address 12 Kent Street 35 East Avenue 141 11st Street 45 Church Place 1 Nitsche Street

Table 2: The Relation schools

b id 1 2 3 4 5 6 7 8

name Ada Lovelace School 1st Primary School Ascaneum ECOLE Gustav-Nitsche School St. Maria Hospital University Hospital Dr. Koch Hospital

x 1343 442 5453 166 46667 811 7654 8365

y 2345 1234 11 23 98883 4476 99147 1342

Table 3: The relation buildings: Location of the Buildings

114

An Example for Illustration We now illustrate our approach (without an explicit usage of join predicates) with a small example. We assume the following infrastructure database consisting of two relations: 1. hospitals (h id, name, phone, fax, address) 2. schools (s id, form, name, phone, address) In the following we use fictive example data for an fictive example city (cf. Table 1 and Table 2). Furthermore we know that the location of each building is stored in a third relation buildings (b id, name, x, y) (cf. Table 3). This database is queried via a mobile client. Therefore, we assume the following sequence of – already lexicographically ordered – queries: Q1 : hospitals(address, name) Q2 : schools(address, phone) ∧ schools.name=’ECOLE’ Q3 : buildings(name) ∧ buildings.x>200 ∧ buildings.x1000 ∧ buildings.y200 buildings.x1000 45 Church Place

445613334

P.O. Box 1100

St. Maria Hospital

18 Avenue of The Stars

University Hospital

5 Third Avenue

Dr. Koch Hospital

buildings.y200 ∧ buildings.x1000 ∧ buildings.y200 ∧ buildings.x1000 ∧ buildings.y The corresponding DTD graph is:

The DTD graph is used to compute so called node paths when a location step is expanded. A node path is a sequence of element names1, which starts at the root (or at a node reached by a previous location step) and follows the child-axis or attribute-axis to the element of interest (i.e. to the element which is reached by a location step). Each node reached with the last expansion step is called selected node of its (normalized) XPath expression. The DTD graph describes a superset of the paths allowed by the DTD. Missing information can be added to the DTD graph by attaching additional filters to the DTD graph nodes [4]. For example, a filter [./E2 xor ./Atom] attached to the node E1 expresses that each node E1 has either a child E2 or a child Atom. Similarly, a filter [unique(./E2)] attached to the node E1 expresses the constraint that for each element E1 there exists at most one child element E2. Such filters can be used to improve the completeness of a tester. However when the applications require or accept a fast but incomplete tester (as outlined in Section 4), it is also correct to ignore the filters for the following reason. If the intersection of the path sets selected by two XPath queries (XP1 and XP2) is empty under the superset of paths described by the DTD graph, we are also sure that this intersection is empty under subset of paths for XP1 and XP2 allowed under the given DTD, because the given DTD is at least as restrictive as the DTD graph. The same holds for the subset test, i.e., if an XPath query XP1 selects a subset of the paths selected by another query XP2 within the superset of paths described by the DTD graph, we can be sure that XP1 also selects a subset of XP2 under the more restrictive DTD. In general we accept well-formed DTDs. We exclude the element type ANY for efficiency reasons, because ANY would result in a lot of cycles in the DTD graph and thereby in more complex further computations. 2.4 The first normalization step: computing node path expressions The goal of the first normalization step is to perform equivalence transformations on a given XPath expressions such that the only remaining element location steps follow the child-axis (and the attribute-axis respectively), i.e. that each selected node can be described by a node path from the root node to this node. We compute a node path expression which describes these node paths, i.e. the node path expression describes the 1

The last node in a node path may also be an attribute, however, we avoid mentioning this explicitly in what follows in order to keep the presentation simple.

127

set of all node paths to a node selected by the given XPath expression. This transformation into a node path expression is applied to the XPath expression location step by location step and uses the given DTD graph. Predicate filters are ignored within this first normalization step and are considered in the second step. In order to give an extended example of how the first normalization step computes a node path expression from a given XPath expression, we use the DTD graph of the previous section and the following XPath expression (XP1) //E1//E2/../*//E1 . The first location step, //E1, includes arbitrary long node paths from the root to any element E1 (i.e. /Root/E1 , /Root/E1/E2/E1 , etc.). That is why we use a node path expression /Root(/E1/E2)N/E1 , N≥0 in order to describe all node paths from the root to the element E1. This node path expression contains a node path loop , i.e. (/E1/E2)N (N≥0), which summarizes all node paths containing zero or more sequences of /E1/E2. Detecting loops is part of this normalization step, and avoids us finding an infinite number of node paths to the node name E1. The second location step in XP1 , //E2 , can be described by an additional node path expression for node paths form the previously selected node names (here only E1) to the currently selected node names (here E2) , in this case by the node path expression /E2(/E1/E2)N2 (N2≥0). Thereafter, the node path expression which describes all node paths for the first two location steps of the given XPath expression XP1, i.e. for the XPath expression //E1//E2 , can be computed by appending the node path expression computed for the second location step (from E1 to E2) to the previously computed node path expression which describes node paths from the root to E1, i.e., the result is /Root(/E1/E2)N/E1/E2(/E1/E2)N2 (N≥0, N2≥0) . This can be simplified to /Root(/E1/E2)N (N≥1) where (/E1/E2)N (N≥1) describes a loop of one or more sequences of /E1/E2 . As the third location step of XP1, i.e. the parent-axis location step /.., requires removing the last node from each computed node path, the node path expression for the first three location steps is /Root(/E1/E2)N/E1[./E2] (N≥0) 2. The next location step of XP1 , /* , is applied to the node name E1 and selects its two successor node names, Atom and E2. For each successor node name, a node path expression is computed by appending the node name to the previously computed node path expression, i.e., we get the node path expression /Root(/E1/E2)N/E1[./E2]/Atom (N≥0), which describes all node paths of //E1//E2/../* to Atom nodes, and similarly, we get the node path expression /Root(/E1/E2)N/E1[./E2]/E2 (N≥0) which describes all node paths to E2 nodes. The latter node path expression can be

2

The predicate filter [./E2] states that only elements E1 which have a successor E2 are selected.

128

simplified to /Root(/E1/E2)N/E1/E2 (N≥0) . The XPath expression XP1 requires to apply the last location step //E1 to both of the previously selected node names, Atom and E2, but an application of this location step to Atom is prohibited by the DTD graph, because Atom has no successor nodes. Therefore, the last location step can only be applied to the node name E2. All node paths from E2 to E1 are described by the node path expression (/E1/E2)N2/E1 (N2≥0) . This node path expression of the node paths from E2 to E1 is appended to the previously computed node path expression, in order to get the final result /Root(/E1/E2)N/E1/E2(/E1/E2)N2/E1 (N≥0, N2≥0) , which can be simplified to /Root(/E1/E2)N/E1 (N≥1) . This finally computed node path expression describes all node paths from the root node to those nodes which are selected by the XPath expression XP1. 2.5. General expansion of an XPath expression using the DTD graph Let us generalize the example given. The node path expression which corresponds to an XPath expression is computed location step by location step by evaluating the DTD graph, where location steps in successor direction (child-axis, descendent-axis, and descendent-or-self-axis) are treated differently from location steps in ancestor direction (parent-axis, ancestor-axis, and ancestor-or-self-axis). Each location step is applied to each node in a set of selected nodes, where the first location step is applied to the root node only. Whenever the location step follows the successor direction (child-axis, descendent-axis, or descendent-or-self-axis), then for each (previously) selected node3, a node path expression which describes the node paths from the previously selected node to the node selected by this location step is computed. This node path expression is appended to that node path expression which describes all node paths from the root node to the previously selected node. After the expansion of this location step, we again have a set of selected nodes and for each node name a node path expression which describes all node paths to that selected node. Whenever the location step follows the ancestor direction (parent-axis, ancestor-axis, or ancestor-or-self-axis), then for each selected node and the given node path expression which describes the node paths to that selected node, the location step in ancestor direction selects one or more nodes on the node path from the root to the currently selected node name. That is why a location step in ancestor direction splits the given node path into a prefix which becomes the new node path to the selected node and a suffix which is used as a predicate filter. For example, let XP2 be the result of appending a location step /ancestor::E1 to the XPath expression XP1 of the previous subsection, i.e., XP2 = //E1//E2/../*//E1/ancestor::E1 . 3

In the above example, the last location step //E1 has to be considered for two previously selected node names, Atom and E2, because both were selected by the previous location step, /*.

129

After the location steps //E1//E2/../*//E1 have been evaluated as before, which has given us the node path expression /Root(/E1/E2)N/E1 (N≥1), the location step /ancestor::E1 requires going back to any occurrence of E1 in the node path except the last one. Hence, for XP2, we get the node path expression /Root(/E1/E2)N1/E1 [ .(/E2/E1)N2 ] (N1≥0) (N2≥1). Here, /Root(/E1/E2)N1/E1 (N≥0) is the prefix which describes all node paths from the root node to selected nodes E1 and [ .(/E2/E1)N2 ] (N2≥1) is a filter expression which is used to further restrict the selected nodes. To summarize, a location step in ancestor direction applied to a given node path expression selects one or more nodes. For each selected node, the location step splits the given node path expression into parts: the first identifies the selected node and the second is used as a predicate filter which has to be applied to the selected node. In order to simplify of the following presentation, we let normalized XPath expressions use a syntactic extension of XPath expressions which allows node path expressions for node paths to occur everywhere, where XPath allows an element to occur, and which also allows loops of child-axis location steps and loops of parent-axis location steps to occur in predicate filters. 2.6. The second normalization step: shuffling predicate filters to the right While predicate filters have been ignored in the previous computations of node path expressions, within the following second normalization step, predicate filters are shuffled to the right-most node names in the node paths, i.e., to the selected node names. For example, /Root/E1[./@a=”5”]/E2 is transformed into /Root/E1/E2[../@a=”5”] . In general, each predicate filter which does not belong to the last location step is rightshuffled along the child-axis (or attribute-axis) until it becomes a filter for the selected node name. This is done by adding parent-axis steps to the location path of each filter comparison which is not a constant for each right-shuffle. Similarly, when a predicate filter is right shuffled along a node path loop to descendent nodes, this adds a corresponding node path loop along the ancestor-axis to the predicate filter. For example, let [ FE ] be a predicate filter then /Root/E1 [FE]/(/E2/E1)N (N≥0) is transformed into /Root/E1/(/E2/E1)N [(../../)N FE] (N≥0) . Here, the parent-axis loop (../../)N (N≥0) in the predicate filter [(../../)N FE] is a shortcut notation for an even positive number of location-steps along the parent-axis. Finally, all predicate filters [P1], ..., [Pn] which belong to the selected node are combined into a single predicate filter [ P1 and ... and Pn ]. This is possible, because we restricted predicate filters to Boolean expressions and none of the filters depends on

130

order (neither document order nor filter application order). Whenever there is no predicate filter for a selected node, we add a predicate filter [ true( ) ] to that selected node. To summarize, our normalization uses the DTD graph to transform an arbitrarily allowed XPath expression into an equivalent set of normalized XPath expressions each of which is of the form rex [predicate filter] , where rex is a regular node path expression which describes all node paths of the given XPath expression to one selected node and predicate filter is a predicate filter expression which may or may not contain node path expressions and parent-axis loops. Notice that rex is a regular expression which is built only along the child-axis and which contains no wildcards (”*”) as a node test, but may contain node path loops. Furthermore, a normalized XPath expression defines all the restrictions of the selected node through predicate filters in the location step of the selected node itself, and the previous location steps of the location path do not contain any predicate filter any more. This will be the input for the predicate evaluator discussed in Section 3.

3. Problem reduction to predicate tests on XPath expressions 3.1. Reducing the locking of fragments to an overlap test for node path expressions A new lock request can be granted, if the XML fragment to be locked does not overlap with any other locked XML fragment for which a lock in an incompatible lock mode has already been granted to a different transaction. In order to check this, the overlap test is applied to each node of the DTD graph which is selected by both lock requests (or by both XPath expressions associated with the lock requests respectively). When given two normalized XPath expressions, rex1[X1] and rex2[X2] which select the same DTD graph node, the overlap test returns false (i.e. that the normalized XPath expressions are disjointed), if rex1 and rex2 select no common node path or ‘( X1 and X2 )’ is unsatisfiable. A tester for regular expressions [9] checks whether or not rex1 and rex2 select a common node path, and our tester for filter predicates (as described in Sections 3.3 to 3.6) checks whether or not ‘(X1 and X2)’ is satisfiable. 3.2. Reducing access control and the reuse of query results to subset tests on node path expressions Access is granted (or an old query result can be reused respectively), if an XPath expression XP1 which is being used for the current operation selects a subset of the nodes which are selected by an XPath expression XP2 which is given for an access right (or the previous query result respectively) – independently of the current content of an XML document. The subset test is performed on the normalized XPath expressions computed from XP1 and XP2. Our subset test is successful, if for each DTD graph node which is selected by a normalized XPath expression rex1 [ filter1 ]

131

which is computed from XP1, a normalized XPath expression rex2 [ filter2 ] which is computed from XP2 exists, such that the following holds: 1. The element paths described by the regular expression rex1 are a subset of the element paths described by the regular expression rex2. 2. filter1 filter2 . A subset test for regular expressions as needed in order to check the first condition is described in [9].The second condition is equivalent to: ( filter1 and ( not filter2 ) ) is unsatisfiable, i.e., we can use the same predicate evaluator as we can use for the overlap test. Access is granted (or an old query result can be reused), if and only if this formula is unsatisfiable for each DTD graph node. If access cannot be granted, an access violation exception is thrown. If it is not possible to reuse an old query result, the new query has to be submitted to the server and the results have to be shipped back to the client. 3.3. Filters with elements for which the DTD allows multiple occurrences The tester for filter expressions has to distinguish two cases for each element (say ‘E2’) which is a child element of another element (say ‘E1’). If the DTD allows at most one child element E2 for a given element E1, then the expression ‘./E2/@a="3" and ./E2/@a="4"’ is unsatisfiable. Therefore, a predicate filter [./E2/@a="3"] used in the context of elements E1 must select a node set which is disjointed from the node set selected by the predicate filter [./E2/@a="4"]. In the case, the test is forwarded to our predicate tester without any further modification. The same is done for all attributes, because for every given context node, there is (at most) one occurrence of this attribute. However, if the DTD allows a single element E1 to have multiple child elements ‘E2’, then for a given context node E1 there may be one child element ‘E2’ with a value "3" for the attribute ‘a’ and another child element ‘E2’ with a value "4" for the attribute ‘a’. Therefore, the expression ‘./E2[@a="3"] and ./E2[@a="4"]’ (*) is satisfiable, when the DTD allows multiple child elements E2. Therefore, an XPath expression //E1[./E2/@a="3"] , which only requires the existence of a child ‘E2’ with an attribute ‘a’ with a value of "3", may overlap with an XPath expression //E1[ ./E2/@a="4" ] , which requires the existence of a (possibly different) child ‘E2’ with an attribute ‘a’ with a value of "4". That is why in the second case, i.e., when multiple child element ‘E2’ are allowed for the same element ‘E1’, we rename the element names ‘E2’ to ‘E2(1)’, ‘E2(2)’ , … etc., where ‘E2(1)’ and ‘E2(2)’ represent possibly different occurrences of ‘E2’. Then we rewrite the formula (*) as ./E2(1)[@a=”3”] and ./E2(2)[@a=”4”] (**) . This formula is forwarded to our predicate tester which now finds out that this conjunction is satisfiable. From a logic point of view, ‘./E2(1)’ requires the existence of an element ‘/E2’ which is a child element of the current element, and /E2(2) requires the existence of a possibly but not necessarily different element ‘/E2’ which is

132

also a child element of the current element.4 Only a predicate ‘not( ./E2[@a])’ will be rewritten as ‘not( ./E2(X)[@a])’, with a variable X which means that whatever value X has (for X=1, X=2, …etc.) no attribute a of the element E2 exists.5 This is useful for finding out e.g. that the rewritten formula ./E2(1)[@a=”3”] and not( ./E2(X)[@a]) is unsatisfiable or in other words that ‘./E2[@a=”3”] implies ./E2[@a] ’ which is needed for the subset test. 3.4. Rewrite rules for predicate filters with loops Before we start rewriting formulas, we rename all loop variables N which belong to independent loops in such a way that we use different variables N1, N2, … for different loops. Thereafter, we apply the following rewrite rules to the formulas which are received from the subset test or from the overlap test. Let L be a loop of parent-axis location steps (../)N with (N≥0) , and let F1 and F2 be filter expressions. Then we move disjunctions and conjunctions outside of loops, i.e. ”L (F1 or F2)” ”L(F1) or L(F2)”. ”L (F1 and F2)” ”L(F1) and L(F2)”. For example, ”(../)N[@a and @b]” is replaced with ”(../)N[@a] and (../)N[@b]”. Note that the value for N must be identical in both parts of the conjunction. Thereafter, we apply rewrite rules for filter formulas without loops as follows. 3.5. Rewrite rules for the evaluation of filter formulas without loops The next step is to apply the following equivalence transformation rules which transform a formula towards a disjunctive normal form (DNF) as close as possible: Let A and B be location path expressions (without a loop) which require the existence of a location path A or B relative to the current node, and let C be a constant. We use eq(A,B) to describe the equality of A and B and neq(A,B) to describe the inequality of A and B, where eq(A,B) and neq(A,B) both assume that both A and B exist relative to the current node. We separate path tests from constraints regarding equality and inequality of given attribute values: ” A = B ” A and B and eq(A,B)” ” A != B ” ” A and B and neq(A,B) ” ” not ( A = B ) ” ” not (A) or not (B) or neq(A,B)” ” not ( A != B ) ” ” not (A) or not (B) or eq(A,B) ” ” A = C ” ” A and eq(A,C)” ” A != C ” ” A and neq(A,C) ”

4

In terms of predicate logic, we could write the formula (**) as (∃ ∃ ./E2(1)) (∃ ∃ ./E2(2)) (./E2(1)[@a=”3”] and ./E2(2)[@a=”4”] 5 In terms of predicate logic, this would be ‘(∀ ∀X) not( ./E2(X)[@a])’

133

.

” not ( A = C ) ” ” not (A) or neq(A,C)” ” not ( A != C ) ” ” not (A) or eq(A,C) ” . Let additionally F, F1 and F2 be filter expressions. We move negations inside location path expressions by applying the following rule6: ” not ( A [F] ) ” ” not (A) or A[not(F)] ” We move negations inside the formula as far as possible by applying the following rules: ” not ( F1 and F2 ) ” ” not ( F1 ) or not (F2) ” ” not ( F1 or F2 ) ” ” not ( F1 ) and not (F2) ” ” not ( not(F) ) ” ” F ” We move disjunctions outside of conjunctions and location path expressions, i.e. ” (F or F1) and F2 ” ” F and F2 or F1 and F2 ” ” A [ F1 or F2 ]” ” A [F1] or A [F2]”. And we move conjunctions outside of location paths, i.e. ” A [F1 and F2]” ” A [F1] and A [F2]”. A formula in disjunctive normal form (DNF) is satisfiable, if and only if at least one conjunction of the formula in DNF is satisfiable. This is checked using the following algorithm. 3.6. Test algorithm for a single conjunction We use the following algorithm in order to check whether or not a single conjunction of conditions is satisfiable which extends an algorithm given in [3]. (0)If the conjunction contains a location path A and it contains an expression not(A) 7 return “conjunction is unsatisfiable” ; (1)For each constant occurring in the conjunction introduce an own equivalence class Ci (1