Mobile Datenbanksysteme: Architektur, Implementierung, Konzepte (Xpert.press)

Xpert. press

Die Reihe Xpert.press bei Springer vermittelt Professionals in den Bereichen Softwareentwicklung, Internettechnologie und IT-Management aktuell und kompetent relevantes Fachwissen über Technologien und Produkte zur Entwicklung und Anwendung moderner Informationstechnologien.

Bela Mutschler · Günther Specht

Mobile Datenbanksysteme Architektur, Implementierung, Konzepte Mit 76 Abbildungen und CD-ROM

123

Bela Mutschler 89231 Neu-Ulm [email protected] Prof. Dr. Günther Specht Universität Ulm Abteilung Datenbanken und Informationssysteme 89069 Ulm [email protected] Bibliografische Information der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Additional material to this book can be downloaded from http://extras.springer.com.

ISSN 1439-5428 ISBN 3-540-20886-0 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere d ie der Übersetzung , des Nachdr ucks , des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist nicht Urheber der Daten und Programme. Weder Springer noch die Autoren übernehmen die Haftung für die CD-ROM und das Buch, einschließlich Ihrer Qulität, Handels- und Anwendungseignung. In keinem Fall übernehmen Springer oder die Autoren Haftung für direkte, indirekte, zufällige oder Folgeschäden, die sich aus der Nutzung der CD-ROM oder des Buches ergeben. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer-Verlag Berlin Heidelberg 2004 Printed in Germany Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutzgesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Text und Abbildungen wurden mit größter Sorgfalt erarbeitet. Verlag und Autor können jedoch für eventuell verbliebene fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Satz: Druckfertige Daten der Autoren Herstellung: LE-TeX Jelonek, Schmidt & Vöckler GbR, Leipzig Umschlaggestaltung: KünkelLopka Werbeagentur, Heidelberg Gedruckt auf säurefreiem Papier SPIN 10983942 - 33/3142/YL - 5 4 3 2 1 0

Vorwort

Architekturen, Implementierungskonzepte und Realisierungsformen mobiler Datenbanksysteme stehen im Mittelpunkt dieses Buches. Dabei soll ein umfassender Überblick über Konzepte, Technologien und den aktuellen Stand der Entwicklungen im Bereich mobiler Datenbanktechnologie gegeben werden. Das Buch gliedert sich in drei grosse Teilbereiche. Im ersten, grundlagenorientierten Teil stehen Architekturen mobiler Datenbanksysteme, Verfahren zur Replikation und Synchronisation, mobile Transaktionsmodelle, die Darstellung von Informationen auf mobilen Clients und die Konzepte von Pico-Datenbanksystemen (Datenbanksystemen auf Smartcards) im Mittelpunkt. An diesen ersten Teil schließt sich im zweiten Teil eine Untersuchung, eine Bewertung und ein Vergleich von insgesamt neun verschiedenen kommerziellen mobilen Datenbanksystemen (DB2 Everyplace, Oracle 10g Lite, Adaptive Server Anywhere und UltraLite, Tamino Mobile Suite, PointBase Micro, MS SQL Server CE Edition, eXtremeDB, hSQLDB und InstantDB) an. Um praktische Erfahrungen im Umgang mit dem Einsatz und der Programmierung von mobilen Datenbanken sammeln zu können, wird im dritten Teil die Konzeption und Programmierung einer mobilen Datenbankanwendung vorgestellt. Das gewählte Szenario, eine einfache Adressdatenbank, wird dabei gleich dreimal, erstens direkt in C und ohne den Rückgriff auf ein mobiles Datenbanksystem, zweitens unter Verwendung des kommerziellen mobilen Datenbanksystems DB2 Everyplace von IBM, sowie drittens mit dem ebenfalls kommerziellen mobilen Java-Datenbanksystem PointBase Micro implementiert. Ein Ausblick auf zukünftige Entwicklungen und Trends im Bereich des Mobile Computing und der mobilen Datenverarbeitung rundet das Buch inhaltlich ab. Dem Buch liegt eine CD-ROM bei, auf der als besonderes Highlight die IBM DB2 Everyplace Enterprise Edition in einer vollfunktionsfähigen, aber zeitlich auf 180 Tage nutzungsbeschränkten Evaluationsversion enthalten ist. Zusätzlich sind auf der CD-ROM die Quelltexte aller drei Beispielanwendungen und weitergehende Tutorials zu Installation und Konfiguration der Beispielanwendungen enthalten. Hinzu kommt eine Liste mit wichtigen Internetadressen aus dem Bereich mobile Datenbanksysteme.

Vorwort

■ ■ ■

V

Die Erstellung dieses Buches wäre niemals ohne die tatkräftige Unterstützung Anderer möglich gewesen. Zunächst möchten wir Ulrich Kreher und Timo Weithöhner für ihre interessanten und inspirierenden Anmerkungen, Vorschläge und vorgebrachten Kritikpunkte danken. Weiterhin gilt unser spezieller Dank Frau Fleschutz vom Springer-Verlag, die stets für alle Fragen unsererseits offen war. Bela Mutschler und Günther Specht Ulm, im April 2004

VI

■ ■ ■

Vorwort

Inhaltsverzeichnis Teil 1 - Konzepte 1

Einführung ............................................................................3

1.1 1.2 1.3 1.4 1.5

Mobile Anwendungen ............................................................3 Referenzarchitektur einer mobilen Umgebung ......................7 Mobiler Zugriff auf Informationsressourcen........................10 Definitionen mobiler Datenbanksysteme.............................12 Gliederung des Buches.........................................................13

2

Mobile Computing..............................................................17

2.1 2.2

2.7

Begriffe.................................................................................17 Mobilität und Drahtlosigkeit ................................................20 2.2.1 Endgerätemobilität .....................................................21 2.2.2 Benutzermobilität .......................................................21 2.2.3 Dienstmobilität ...........................................................22 Grundlagen drahtloser Netze................................................22 2.3.1 Mobilfunk in Deutschland (und weltweit) .................24 2.3.2 Wireless-LAN ............................................................32 2.3.3 Wireless Personal Area Networks..............................37 2.3.4 Alternative Funktechnologien ....................................40 Mobile Anwendungen ..........................................................41 2.4.1 Ortsunabhängigkeit ....................................................42 2.4.2 Lokalisierbarkeit.........................................................42 2.4.3 Sicherheit und Identifizierbarkeit...............................43 2.4.4 Verfügbarkeit und Effizienz.......................................45 2.4.5 Datenverteilung und Lastverteilung ...........................45 2.4.6 Überwachung von Integritätsbedingungen ................46 Location Based Services ......................................................46 Klassifikation mobiler Endgeräte.........................................50 2.6.1 Notebooks...................................................................51 2.6.2 PDAs, Smartphones und Handys ...............................51 2.6.3 Wearables ...................................................................54 2.6.4 Smartcards ..................................................................54 Zusammenfassung ................................................................55

3

Architekturen mobiler Informationssysteme ..................57

3.1

Client/Server-Architekturen .................................................57 3.1.1 Prozessmodell von Datenbanksystemen ....................58

2.3

2.4

2.5 2.6

Inhaltsverzeichnis

■ ■ ■

VII

3.5

3.1.2 Klassische Client/Server-Architekturen..................... 60 3.1.3 Mobile Client/Server-Architekturen .......................... 64 Verteilte Datenbanksysteme ................................................ 64 3.2.1 Klassische verteilte Datenbanksysteme ..................... 66 3.2.2 Mobile verteilte Datenbanksysteme........................... 69 Middleware-Architekturen................................................... 71 Mobile Agenten.................................................................... 73 3.4.1 Grundlagen................................................................. 73 3.4.2 Framework zur Ausführung mobiler Agenten........... 75 Zusammenfassung................................................................ 78

4

Replikation und Synchronisation ..................................... 79

4.1 4.2

4.7

Motivation ............................................................................ 79 Technische Grundlagen........................................................ 81 4.2.1 Replikation ................................................................. 81 4.2.2 Synchronisation.......................................................... 86 Zielkonflikt der Replikation................................................. 87 Klassische Replikations- und Synchronisationsverfahren... 88 4.4.1 Konsistenzerhaltende Verfahren................................ 89 4.4.2 Verfügbarkeitserhaltende Verfahren.......................... 94 4.4.3 Data Caching.............................................................. 95 4.4.4 Data Hoarding ............................................................ 96 4.4.5 Verzicht auf Replikation ............................................ 96 Neue mobile Verfahren........................................................ 98 4.5.1 Virtual-Primary-Copy ................................................ 98 4.5.2 Snapshot-Verfahren ................................................... 99 4.5.3 Nutzerdefinierte Replikation.................................... 100 Synchronization Markup Language (SyncML) ................. 104 4.6.1 Synchronisationsszenarien ....................................... 105 4.6.2 Synchronisationskonflikte........................................ 107 Zusammenfassung.............................................................. 108

5

Mobile Transaktionen ..................................................... 109

5.1

Klassische Transaktionen................................................... 110 5.1.1 Nebenläufigkeit........................................................ 110 5.1.2 Transaktionszustände ............................................... 111 5.1.3 ACID-Transaktionen................................................ 112 5.1.4 Serialisierbarkeit von Transaktionen ....................... 119 Mobile Transaktionen ........................................................ 115 Transaktionsmodelle der Klasse 1 ..................................... 117 5.3.1 Kangaroo-Transaktionen.......................................... 117 5.3.2 PSTMT-Transaktionen ............................................ 123 5.3.3 Offen-geschachtelte Transaktionen ......................... 127

3.2

3.3 3.4

4.3 4.4

4.5

4.6

5.2 5.3

VIII

■ ■ ■

Inhaltsverzeichnis

5.5

5.3.4 Prewrite-Transaktionen ............................................130 Transaktionsmodelle der Klasse 2......................................132 5.4.1 Provisorische Transaktionen ....................................132 5.4.2 Semantische Transaktionen......................................136 5.4.3 Schwache/Strikte Transaktionen ..............................141 5.4.4 Isolation-Only-Transaktionen ..................................144 5.4.5 Promotion-Transaktionen.........................................147 Zusammenfassung ..............................................................149

6

Anfrageverarbeitung........................................................153

6.1 6.2 6.3

6.4

Klassische Anfrageauswertung ..........................................153 Anforderungen mobiler Anfragesysteme...........................155 Klassifikation standortabhängiger Queries ........................156 6.3.1 Begriffe.....................................................................156 6.3.2 Klassifikation............................................................157 6.3.3 Ausführung lokationsabhängiger Anfragen .............159 Zusammenfassung ..............................................................161

7

Informationsdarstellung auf mobilen Geräten..............163

7.1 7.2

7.4

Adaption von Systemen......................................................163 Adaption von Informationen ..............................................165 7.2.1 Webkarussell ............................................................166 7.2.2 Personalisierung .......................................................168 Adaption durch Abstraktion ...............................................170 7.3.1 Composite Capability / Preference Profile...............170 Zusammenfassung ..............................................................171

8

Pico-Datenbanksysteme ...................................................173

8.1 8.2

Anwendungsszenarien........................................................173 Smartcards ..........................................................................176 8.2.1 Technischer Aufbau .................................................177 8.2.2 Standards ..................................................................178 Eigenschaften von Pico-Datenbanksystemen ....................178 Speicherverwaltung ............................................................181 8.4.1 Flat-Storage ..............................................................181 8.4.2 Domain-Storage........................................................182 8.4.3 Ring-Storage.............................................................183 Anfragebearbeitung ............................................................186 8.5.1 Einfache Abfragen....................................................187 8.5.2 Pipelining..................................................................189 8.5.3 Komplexe Abfragen .................................................191 Zusammenfassung ..............................................................191

5.4

7.3

8.3 8.4

8.5

8.6

Inhaltsverzeichnis

■ ■ ■

IX

Teil 2 - Systeme 9

Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme............................................. 195

9.1 9.2

Motivation .......................................................................... 195 IBM DB2 Everyplace ........................................................ 196 9.2.1 Komponenten ........................................................... 197 9.2.2 Architektur der clientseitigen Datenbank-Engine.... 199 9.2.3 Replikation & Synchronisation................................ 202 9.2.4 Anfragesprachen ...................................................... 208 9.2.5 Programmierung....................................................... 209 9.2.6 Zusammenfassung.................................................... 212 Oracle Database 10g Lite................................................... 213 9.3.1 Komponenten ........................................................... 213 9.3.2 Architektur der clientseitigen Datenbank-Engine.... 215 9.3.3 Replikation & Synchronisation................................ 216 9.3.4 Oracle 10g Application Server (Wireless)............... 221 9.3.5 Programmierung....................................................... 222 9.3.6 Zusammenfassung.................................................... 223 SQL Anywhere Studio....................................................... 224 9.4.1 Komponenten ........................................................... 224 9.4.2 Adaptive Server Anywhere und UltraLite ............... 227 9.4.3 Replikation und Synchronisation............................. 229 9.4.4 Programmierung....................................................... 232 9.4.5 Zusammenfassung.................................................... 234 Tamino Mobile Suite ......................................................... 235 9.5.1 Komponenten ........................................................... 236 9.5.2 Architektur der clientseitigen Datenbank-Engine.... 237 9.5.3 Replikation und Synchronisation............................. 239 9.5.4 Implementierungskonzepte ...................................... 243 9.5.5 Programmierung....................................................... 246 9.5.6 Zusammenfassung.................................................... 246 PointBase Micro................................................................. 247 9.6.1 Architektur der clientseitigen Datenbank-Engine.... 248 9.6.2 Replikation und Synchronisation............................. 250 9.6.3 Implementierungskonzepte ...................................... 253 9.6.4 Programmierung....................................................... 254 9.6.5 Zusammenfassung.................................................... 255 Microsoft SQL Server 2000 CE Edition............................ 256 9.7.1 Komponenten ........................................................... 256 9.7.2 Architektur der clientseitigen Datenbank-Engine.... 256 9.7.3 Replikation und Synchronisation............................. 258

9.3

9.4

9.5

9.6

9.7

X

■ ■ ■

Inhaltsverzeichnis

9.8

9.9

9.7.4 Implementierungskonzepte ......................................259 9.7.5 Programmierung.......................................................260 9.7.6 Zusammenfassung....................................................261 Eingebettete (Java-SQL)-Datenbanken..............................261 9.8.1 eXtremeDB...............................................................262 9.8.2 Hypersonic SQL Database .......................................263 9.8.3 InstantDB..................................................................267 Vergleich der mobilen Datenbanksysteme.........................268 9.9.1 Architektur der Datenbank-Engine ..........................268 9.9.2 Replikation und Synchronisation .............................269 9.9.3 Programmierung.......................................................270 9.9.4 Zusammenfassung....................................................272

Teil 3 - Praxis 10

Konzeption und Realisierung einer mobilen Datenbankanwendung .....................................................277

10.1 10.2

Implementierungsvarianten ................................................277 Programmierwerkzeuge und Konfiguration der Entwicklungsumgebung .....................................................279 10.2.1 Entwicklung in C....................................................280 10.2.2 Entwicklung in Java ...............................................283 Programmierung von Palmtops..........................................286 10.3.1 Speicheraufbau .......................................................286 10.3.2 Ereignisgesteuerte Programmierung ......................289 Variante 1: Implementierung in C......................................291 10.4.1 Datenbankfunktionalität .........................................294 10.4.2 Programmierung des Conduits ...............................303 10.4.3 Zusammenfassung Variante 1 ................................304 Variante 2: Implementierung mit DB2 Everyplace ...........304 10.5.1 Konfiguration der Synchronisationsarchitektur .....305 10.5.2 Anwendungsentwicklung.......................................307 10.5.3 Zusammenfassung Variante 2 ................................310 Variante 3: Implementierung mit PointBase Micro ...........311 10.6.1 Startformular...........................................................311 10.6.2 Datenbank-Programmierung ..................................314 10.6.3 Suchformular ..........................................................318 Zusammenfassung der Implementierungsvarianten...........320 10.7.1 Variante 1: C-Anwendung .....................................321 10.7.2 Variante 2: DB2 Everyplace...................................322 10.7.3 Variante 3: PointBase Micro ..................................323

10.3

10.4

10.5

10.6

10.7

Inhaltsverzeichnis

■ ■ ■

XI

11

JDBC Optional Package for Java 2 Micro Edition ...... 325

11.1 11.2

Grundlagen......................................................................... 325 Details................................................................................. 326

12

Ausblick............................................................................. 329

Literatur........................................................................................ 335 Indexverzeichnis........................................................................... 347

XII

■ ■ ■

Inhaltsverzeichnis

Teil 1 Konzept

1 Einführung

Die Informationstechnologie durchlebt momentan einen fundamentalen Wandel. Stationäre Rechnersysteme wie PCs werden immer mehr durch mobile Computer verdrängt. Unter mobilen Computern versteht man nicht mehr nur relativ leistungsstarke Notebooks, sondern auch Personal Digital Assistants (PDAs), Smartphones, Handys, Tablet-PCs, Smartcards sowie mobile eingebettete Systeme wie beispielsweise Pager. Kleinste mobile Computersysteme werden mittlerweile sogar in Ringe, Kleidungsstücke oder Armbanduhren integriert (solche Computer werden als Wearables bezeichnet). Für mobile Computer ist in Zukunft nicht nur eine ständig zunehmende technische Leistungsfähigkeit zu erwarten (was beispielsweise den Prozessortakt oder die Speichergröße anbelangt), sondern auch eine immer häufigere, spontane Vernetzung mit anderen mobilen Computern oder stationären Netzen. Nach der Mainframe- und PC-Ära heisst die wichtigste Anforderung in Zukunft: Anytime, Anywhere Computing.

Mobile Computing

1.1 Mobile Anwendungen Mobile Computing spielt vor allem in der Industrie, genauer gesagt bei Integrationsbemühungen innerhalb von Unternehmen (Enterprise Application Integration) eine immer wichtigere Rolle. Ein Beispiel ist der Einsatz von PDAs für die Datenerfassung in der Lagerverwaltung, vor allem bei externen Lagern oder in Zulieferketten. Ein anderes Beispiel ist der Versicherungsvertreter, der im Außendienst einen Zugriff auf entfernt gespeicherte Daten benötigt, jedoch nicht immer online ist. Eng mit mobilen Anwendungen sind Funknetze (d.h. Drahtlosigkeit) verknüpft. Zwar sind Mobilität und Drahtlosigkeit zwei zueinander orthogonale Konzepte, trotzdem besteht eine enge Korrelation zwischen beiden. So setzen fast alle mobilen Anwendungen die Möglichkeit voraus, eine drahtlose Verbin-

1.1 Mobile Anwendungen

Enterprise Application Integration

■ ■ ■

3

Lokationsabhängige Anwendungen

Funknetze

Online-Szenario

4

■ ■ ■

dung zu einem Netzwerk aufzubauen, um auf entfernte Datenquellen zugreifen zu können. Mit der Adaption klassischer Anwendungen für den Einsatz in mobilen Umgebungen kommt es nicht nur zu einer Anpassung existierender Konzepte, sondern auch zur Entwicklung neuer Technologien und Anwendungen, wie sie beispielsweise Location Based Services (LBS) darstellen. Location Based Services sind Dienste für mobile Geräte, die einem Nutzer, abhängig von seinem jeweiligen Standort, für ihn relevante Informationen auf einem Client (Handy, PDA, Notebook) bereitstellen. Dazu ist unter anderem eine genaue Standortbestimmung (Ortung) des mobilen Clients notwendig. Insbesondere mit der Einführung der Mobilfunknetze der dritten Generation (Stichwort: UMTS) erwarten sich die Netzbetreiber einen starken Boom mobiler Dienstleistungen und Mehrwertdienste. Mit der ansteigenden Nutzung mobiler Datendienste (Multimedia Messaging Service, Videotelefonie, Internetzugriff) nimmt die Menge der übertragenen Daten zu. Insbesondere der ansteigende Versand von digitalen Photos und die für die neuen UMTS-Netze vorgesehene Videotelefonie bedeuten eine erhebliche Zunahme des Datenaufkommens, speziell in den Mobilfunknetzen. Den Mobilfunknetzen (GSM, GPRS, HSCSD, UMTS) steht mit den drahtlosen Netzwerken der IEEE-Standardfamilie 802.11 (Wireless-LANs) eine Drahtlostechnologie gegenüber, die wesentlich höhere Bandbreiten (bei gleichzeitig geringeren Reichweiten) ermöglicht und sich deswegen zu einer interessanten Alternative mit einer hohen Wachstumsdynamik entwickelt (gerade im Zusammenhang mit der Ersetzung festverkabelter lokaler Netzwerke). Beim Zugriff auf Informationen über mobile Clients können zwei grundlegende Szenarien unterschieden werden. Beim einfacheren der beiden Szenarien wird davon ausgegangen, dass mobile Clients eine Netzwerkverbindung (Mobilfunknetz oder Wireless-LAN) lediglich dazu benutzen, um auf Daten auf einem entfernten Datenbankserver zuzugreifen. Die angefragten Daten werden serverseitig in der Form eines HTML- oder WML-Dokumentes dynamisch aufbereitet und anschließend an den mobilen Client übertragen. Dieser braucht für die Anzeige der Informationen einzig einen Browser. Datenbankfunktionalität ist in diesem Szenario auf dem mobilen Client nicht vorhanden. Der Client agiert somit als Thin Client, der lediglich eine grafische Schnittstelle für den Zugriff auf eine entfernte Datenbank darstellt. Dieses Szenario wird wegen der vorausgesetzten Netzwerkverbindung als Online-Szenario bezeichnet.

1 Einführung

Wichtigstes Merkmal des korrespondierenden Offline-Szenarios ist der Einsatz „leichtgewichtiger“ Datenbanksysteme (so genannter mobiler Datenbanksysteme), die an die wesentlich geringeren Ressourcen mobiler Clients angepasst sind (wie geringer Speicherplatz, niedrige Taktfrequenz oder kleine Displaygrößen). Offline bezieht sich darauf, dass bei Anfragen oder Eingaben keine dauernde Netzwerkverbindung zu einem entfernten Datenbankserver vorausgesetzt wird. Mobile Clients werden somit von der Verfügbarkeit drahtloser Netzwerkverbindungen entkoppelt. Dazu müssen relevante Daten zunächst vom Datenbankserver auf den Client übertragen werden (Stichwort: Replikation). Auf den lokalen Daten durchgeführte Änderungen müssen dann später mit den zwischenzeitlichen Änderungen auf dem zentralen Datenbankserver wieder abgeglichen werden (Stichwort: Synchronisation). Die Replikation von Daten und die Synchronisation zwischen einem mobilem Client und einem Datenbankserver nach längeren Phasen ohne Netzwerkverbindung sind zentrale Problemfelder im Zusammenhang mit mobilen Datenbanksystemen.

Offline-Szenario

Gerade durch die ständig zunehmende Leistungsfähigkeit und Verfügbarkeit mobiler Technologien ergeben sich neue Möglichkeiten bei der Integration mobiler Anwendungen in bestehende Infrastrukturen. Die Spannweite reicht von ortsunabhängigen Informationsdiensten (nationale Wetterdaten, Börseninformationen, …) und Datenbankanwendungen bis hin zu ortsabhängigen Dienstleistungen. Einige besonders interessante Anwendungsszenarien für Mobiltechnologien sind im Folgenden zusammengestellt [Le03]:

Anwendungsszenarien

■

Online-Zugriff auf Datenbank- und Informationssysteme,

■

Offline-Zugriff auf Datenbank- und Informationssysteme (wozu dann insbesondere leichtgewichtige Datenbanksysteme auf den mobilen Clients eingesetzt werden),

■

beim mobilen Kundenmanagement (Customer-RelationshipManagement) werden einem Mitarbeiter beim Kunden die für seine Arbeit notwendigen Informationen angezeigt,

■

beim mobilen Zugriff auf Lieferkettensysteme (Supplier-ChainManagement) greift ein Nutzer mobil auf andere mobile Systeme zu,

■

Mobile Reservierungsdienste (Fahrkarten, Tickets, …),

■

Mobile Zahlungssysteme (über Handys: z.B. PayBox, …),

■

Pervasive Groupware Applications,

■

Remote Control, Fernwartung und Telemetrie,

1.1 Mobile Anwendungen

■ ■ ■

5

■

Ortsabhängige mobile Dienstleistungen (Location Based Services).

Klassifikation der Anwendungen

Mittlerweile wurden einige Versuche unternommen, mobile Anwendungen anhand bestimmter Kriterien zu klassifizieren. Ein erster Klassifikationsversuch fokussiert ausschließlich Anwendungen für den Mobile Commerce (M-Commerce). Dabei wird zwischen drei verschiedenen Typen von M-Commerce-Anwendungen, namentlich dem Kerngeschäft, den Mehrwertdiensten und Anwendungen, die ihren Ursprung im E-Commerce haben, unterschieden. Eine zweite, eher allgemeine Klassifikation unterscheidet zwischen Business-2-Consumer- (B2C) und Business-2-BusinessAnwendungen (B2B). Eine dritte interessante Klassifikation mobiler Anwendungen unterscheidet zwischen kommunikationszentrierten, transaktionsorientierten und inhaltszentrierten Anwendungen. Kommunikationszentrierte Anwendungen fokussieren vor allem den Austausch von Nachrichten. Transaktionsorientierte Anwendungen modellieren einzelne Geschäftsprozesse und verknüpfen diese zu größeren Prozessen. Inhaltszentrierte Anwendungen fokussieren schließlich die Bereitstellung von Daten und Informationen für einen einfachen Abruf durch interessierte Clients.

Mobile Datenbanksysteme

Anwendungsszenarien, die den Einsatz mobiler Technologien sinnvoll machen, sind immer dann gegeben, wenn sich ein Nutzer oder ein Client häufig stark räumlich verändern. Charakteristisches Merkmal fast aller Unternehmensanwendungen ist zudem eine starke Datenzentrierung. Entsprechend macht eine zuverlässige, effiziente und sichere Administration, Speicherung und Nutzung von Daten den Einsatz von Datenbanksystemen notwendig. Die physischen Restriktionen vieler mobiler Clients gestatten jedoch weder die Implementierung leistungshungriger Datenbanksystemfeatures, noch eine Auswertung von komplexen Anfragen, die umfangreiche, zu materialisierende Zwischenergebnisse produzieren (wie beispielsweise Sortieroperationen). Dies führte zur Entwicklung von Small-Footprint-Datenbanksystemen mit kleinerem eigenen Speicherbedarf und angepasster Funktionalität. Aufgrund ihres Einsatzes auf mobilen Clients werden Small-Footprint-Datenbanksysteme auch als mobile Datenbanksysteme bezeichnet. In den letzten Jahren entstanden bereits eine ganze Reihe (kommerzieller) mobiler Datenbanksysteme. Dabei konkurrieren in ihrer Funktionalität sehr umfassende Produkte großer Hersteller wie IBM oder Oracle mit eher anwendungsspezifischen Prototypen aus der Forschung und Entwicklung. Um sich im Kontext einer konkreten Aufgabenstellung für das richtige System zu entscheiden, ist es

6

■ ■ ■

1 Einführung

wichtig, die den mobilen Datenbanksystemen zugrunde liegenden Ideen und Konzepte zu kennen und einschätzen zu können. Aufgrund der Leistungsschwäche mobiler Clients müssen bekannte Techniken und Methoden klassischer Datenbanksysteme angepasst werden. Mobile Datenbanksysteme und zugehörige Synchronisationsdienste müssen eine effiziente Integration mobiler Anwendungen in bestehende, heterogene Infrastrukturen und Systemlandschaften ermöglichen. Insbesondere die Verfügbarkeit von ausgereiften Synchronisationstools ist dabei von grundlegender Bedeutung, da nur diese Werkzeuge den Abgleich zwischen mobilem Client und stationärem, entferntem Datenbankserver gestatten.

1.2 Referenzarchitektur einer mobilen Umgebung In den letzten Jahren gab es diverse Ansätze und Vorschläge, wie eine beispielhafte mobile Umgebung definiert werden kann. Durchgesetzt hat sich die nachfolgend beschriebene Referenzarchitektur, die auch im restlichen Verlauf dieses Buches zugrunde gelegt wird. Die Referenzarchitektur (vgl. Abbildung 1.1) beschreibt die allgemeine, zellenbasierte Struktur einer mobilen Umgebung, ohne auf Einzelheiten und Anforderungen spezifischer Anwendungsdomänen genauer einzugehen. Sender, die eine einzelne Funkzelle versorgen, werden auch als Basisstation oder Funkfeststation bezeichnet. Funkzellen selbst weisen keine fest definierte Größe aus, das heisst sie sind in ihrem Zellradius und ihrer Form starken Schwankungen unterworfen, auf die auch geographische Besonderheiten wie Gebirgszüge oder Gebäude Einfluss nehmen können. Es kann zwischen folgenden Zelltypen [Le03] unterschieden werden: ■

Megazelle. Dies ist die größte Funkzelle. Die Funkversorgung erfolgt durch Satelliten, wodurch die Funkzellen die Größe von ganzen Kontinenten annehmen können.

■

Makrozelle. Diese Zellen haben einen Zellradius zwischen 10 km und 300 km und versorgen vor allem sich schnell bewegende Nutzer, beispielsweise telefonierende Autofahrer.

■

Mikrozelle. Diese Zellen haben einen Zellradius zwischen 300 m und 10 km und versorgen vor allem eine größere Anzahl an Nutzern, wie sie in typischerweise in Ballungsräumen auftreten.

1.2 Referenzarchitektur einer mobilen Umgebung

Funkzellen

■ ■ ■

7

■

Pikozelle. Diese Zellen haben einen Zellradius von weniger als 300m auf und formen vor allem lokale Netzwerke. Pikozellen repräsentieren die kleinsten möglichen Zellen.

Abb. 1.1: ReferenzArchitektur

Architekturelemente

Betriebszustände mobiler Clients

8

■ ■ ■

Von der konkreten Netzwerktechnologie, durch die die Funkzellen tatsächlich realisiert werden (GSM, UMTS, Wireless-LAN, …), wird in der Referenzarchitektur abstrahiert. Die Systemarchitektur besteht aus verschiedenen Klassen von Hosts (Rechnersystemen), denen unterschiedliche Rollen zukommen. Es wird zwischen mobilen Knoten (Notebooks, PDAs, Smartphones) und nicht-mobilen, stationären Knoten (Server, Workstations, PCs) unterschieden. Mobile Knoten sind drahtlos in die Systemarchitektur eingebunden. Stationäre Knoten dagegen sind untereinander durch ein leistungsstarkes, festverkabeltes Netzwerk verbunden. Es gibt zwei Betriebszustände mobiler Clients. Existiert eine drahtlose Verbindung zur Basisstation und somit zum Festnetz, befinden sich mobile Knoten im Zustand Schwach-Verbunden (Connected Mode), existiert keine solche Verbindung, sind die mobilen also vom Festnetz getrennt, befinden sie sich im Zustand Verbindungslos (Disconnected Mode). Stationäre Knoten, die eine gesicherte, permanente Netzwerkverbindung vorweisen (wie beispiels-

1 Einführung

weise klassische stationäre Einheiten) befinden sich im Betriebszustand Stark-Verbunden (Always-On). Mobile Knoten bewegen sich innerhalb eines unendlichen geographischen Mobilitätsgebietes völlig autonom. Autonom heisst, dass die mobilen Knoten in ihrem Bewegungsverhalten nicht von außen gesteuert werden. Es ist also a priori nicht bekannt, wann ein Zellenwechsel auftreten wird und in welche Funkzelle der mobile Knoten als nächstes wechseln wird. Funkzellen können sich überlappen. Ebenso können verschiedene Drahtlostechnologien (z.B. GSM, UMTS, Wireless-LAN) parallel angeboten und genutzt werden. Der Übergang von einer Zelle in eine andere wird als Migration (Handover) oder auch als Verbindungsübergabe bezeichnet. Gründe einer Verbindungsübergabe können das Verlassen des Versorgungsbereiches der aktuellen Zelle, eine zu hohe Netzbelastung oder allgemeine Störungen sein. Dabei wird gefordert, dass es durch den Migrationsprozess zu keiner Verletzung der Zugriffskontinuität kommt, das heisst, dass eine Migration keinerlei Auswirkungen auf gerade laufende Transaktionen und damit verbundener Datenzugriffsprozesse hat (so darf eine Mobilfunkverbindung bei einem Zellenwechsel nicht abbrechen). Die Knoten des Festnetzes können weiter untergliedert werden in stationäre Knoten, die die eigentliche Datenspeicherung, Verwaltung und Verarbeitung realisieren, und in Basisstationen (Mobile Support Station), die den Zugang der mobilen Einheiten zum Festnetz ermöglichen. Jede Zelle wird durch mindestens eine Basisstation versorgt, wobei eine Basisstation durchaus auch mehrere Funkzellen versorgen kann (das dazu notwendige Verfahren basiert auf dem Einsatz sektorisierter Antennen). Sind aus Gründen besserer Skalierbarkeit und Lastverteilung innerhalb einer Zelle mehrere Basisstationen notwendig, bleibt diese Redundanz gegenüber den mobilen Knoten transparent. Basisstationen sind für die Administration und das Nutzermanagement der ihnen zugeordneten Zellen zuständig. Mobile Knoten können ausschließlich über eine Basisstation auf das Festnetz zugreifen. In der untenstehenden Tabelle werden einige aktuelle (Brutto-)Bandbreiten von Funktechnologien gegenübergestellt: Drahtlostechnologie General Packet Radio Service (GPRS) High Speed Circuit Switched Devices (HSCSD) Wireless-LAN 802.11b Wireless-LAN 802.11g Universal Mobile Telecommunication System (UMTS) Bluetooth

Bandbreite 171,2 kBit/s 115,2 kBit/s 11 MBit/s 54 MBit/s 2 MBit/s 1 MBit/s

1.2 Referenzarchitektur einer mobilen Umgebung

Migration, Handover

Festnetzkomponenten

Tab. 1.1 : Bandbreiten

■ ■ ■

9

Bereits in den 1970er Jahren wurde in den Bell Laboratories in den USA die wichtige Erkenntnis gewonnen, dass viele kleine Sender, die zusammen ein zellenbasiertes Funknetz realisieren, durch den Einsatz von Frequenz- und Kanalwechselalgorithmen eine größere Netzkapazität bereitstellen können, als es ein einzelner, vergleichsweise sehr leistungsstarker Sender kann. Eine erhöhte Netzkapazität bedeutet gleichzeitig aber auch eine höhere Zahl von Nutzern, die durch ein Funknetz versorgt werden können. Technische Details der Drahtlostechnologien werden ausführlicher in Kapitel 2 besprochen.

1.3 Mobiler Zugriff auf Informationsressourcen

Klassifikation mobiler Anwendungen

Jeder Nutzer hat eigene Anforderungen an mobile Anwendungen. Bevorzugen einige Nutzer die Verwendung mobiler Clients für das Personal Information Management (PIM), also der Verwaltung von Adressen, Terminen und Kontaktdaten, möchten andere Nutzer dagegen in regelmäßigen Intervallen aktuelle Informationen beziehen (beispielsweise Börsenkurse, Wettervorhersagen oder Sportergebnisse). Eine dritte Gruppe an Nutzern wiederum will Daten beliebigen Typs von einer Datenquelle abrufen, sie bearbeiten und anschließend die durchgeführten Änderungen wieder auf die Originaldaten zurückspeichern (synchronisieren). Trotz der Vielfalt möglicher Anwendungen lassen sich bezüglich des Einsatzes mobiler Datenbankanwendungen zwei verschiedene Klassen unterscheiden: ■

10

■ ■ ■

Vertikale Anwendungen. Bei diesem Anwendungsszenario greifen mobile Nutzer auf zentrale Informationsressourcen des Festnetzes zu. Dabei unterscheidet man zwischen Push- und Pull-Szenarien [Vei00, Imi92]. Bei Push-Szenarien versorgt die zentrale Informationsquelle alle erreichbaren mobilen Clients in regelmäßigen Intervallen mit aktuellen Informationen, ohne dass die mobilen Clients diese explizit anfordern müssen. Dagegen kommt in Pull-Szenarien der zentralen Informationsquelle eine inaktive Rolle zu. Mobilen Clients werden die gewünschten Informationen erst auf deren explizite Aufforderung hin übermittelt. Zu beiden Szenarien existieren verschiedene Varianten, die unter anderem auf Broadcast Disks [Arc95] zurückgreifen. Broadcast Disks sind logische Zusammenstellungen von Daten, die anhand fest vorgegebener Regeln in festen Abständen von einem Server an eine bestimmte Menge von Clients übertragen

1 Einführung

werden. Die wichtigsten vertikalen Anwendungen (in einem Push- oder Pull-Szenario) sind die Location Based Services. ■

Horizontale Anwendungen. Bei diesem Anwendungsszenario steht die Kooperation mobiler Nutzer bzw. von Anwendungen untereinander im Mittelpunkt. Zur Bearbeitung einer gemeinsam zu lösenden Aufgabe wird auf Daten zugegriffen, die systemweit verteilt sein können. Daten sind dabei nicht nur auf mobilen Clients, sondern auch auf Datenquellen des Festnetzes verteilt. Wichtiges Beispiel horizontaler Anwendungen sind die mobilen Ad-Hoc-Netze. Darunter sind spontane Vernetzungen mobiler Clients zu verstehen (ähnlich den Peer-to-Peer-Netzwerken), die nach der Vernetzung zusammen Aufgaben lösen oder Daten austauschen. Voraussetzung dazu ist die Dienstfindung in mobilen Ad-Hoc-Netzen.

Beim Datenzugriff von mobilen Clients aus kann auch eine Klassifikation bezüglich der zugegriffenen Daten erfolgen. Im Folgenden wird zwischen drei Kategorien unterschieden, die unterschiedliche Sicherheitseigenschaften aufweisen und damit unterschiedliche Anforderungen an die Speicherung und den Zugriff implizieren: ■

Private Daten. Dabei handelt es sich zumeist um äußerst sicherheitskritische Daten, auf die im Normalfall ausschließlich dem Eigentümer der Daten ein umfassender Zugriff gewährt werden darf. Um den Zugriff auf die Daten zu kontrollieren, sind das Vorhandensein einer effizienten Rechteverwaltung auf dem mobilen Client und der Einsatz von Verschlüsselungstechniken bei der Übertragung (wie IPSec, SSL) notwendig.

■

Öffentliche Daten. Bei diesen Daten handelt es sich um für jedermann zugängliche Informationen, die von beliebigen Nutzern eingesehen und genutzt werden können. Öffentliche Daten sind hauptsächlich bei vertikalen Anwendungen von Bedeutung. Sie werden zumeist über zentrale Datenquellen bereitgestellt und richten sich an grosse Nutzergruppen. Die Aktualisierung der Daten auf den Clients kann mit Pull-, als auch mit PushVerfahren realisiert werden. Beispiele von öffentlichen Daten sind Börseninformationen, Wetterdaten und Sportergebnisse. Eine Änderung öffentlicher Daten durch den Endbenutzer ist in den wenigsten Fällen erlaubt. Für gewöhnlich besitzen mobile Nutzer also kein Schreibrecht. Erste Ansätze, dies zu ändern, sind aber bereits zu erkennen. Dies kann, vor allem was die Aktualität der von Nutzern direkt eingebrachten Daten betrifft, eine erhebliche Verbesserung darstellen. Ein Beispielszenario ist die

1.3 Mobiler Zugriff auf Informationsressourcen

Klassifikation von Daten

■ ■ ■

11

Einbringung von Verkehrsinformationen durch Autofahrer. Dahinter steht die Vision stark interaktiver Informationssysteme, die durch die Nutzer selbst verwaltet und gepflegt werden. ■

Gemeinsame Daten: Dabei handelt es sich um eine Kategorie von Daten, deren Verwaltung besonders schwierig und komplex ist. Nutzer in großer Anzahl greifen auf von allen Nutzern gemeinsam genutzte Datenbestände sowohl lesend als auch schreibend zu. Bei gemeinsamen Daten muss zwischen zwei Zugriffsszenarien unterschieden werden. Beim ersten Szenario greifen die Nutzer mit ihren mobilen Clients direkt schreibend auf zentrale Informationsquellen zu. Wie üblich sorgen Sperrverfahren dafür, dass nebenläufige konkurrierende Zugriffe mehrerer mobiler Nutzer zu keinen Zugriffsverletzungen und somit zu keinen Dateninkonsistenzen führen. Gleichzeitig darf die Verfügbarkeit der von vielen gleichzeitig genutzten Daten nicht zu stark eingeschränkt werden, da dies sofort zu erheblich längeren Zugriffszeiten führt. Beim zweiten Szenario werden Daten des gemeinsamen, zentralen Datenbestands auf die mobilen Clients repliziert, so dass eine lokale Datenverarbeitung erfolgen kann. In diesem Szenario muss der Disconnected Mode mobiler Clients unterstützt werden. Dies führt aber zu einem erhöhten Aufwand bei der Wiedereinbringung mehrfach geänderter Daten von verschiedenen Clients in die zentrale Datenbasis.

Die Klasse der gemeinsamen Daten ist für den Einsatz mobiler Datenbanksysteme besonders interessant, da dieser Fall bezüglich Verwaltung und Nutzung die komplexesten Frage- und Problemstellungen mit sich bringt.

1.4 Definitionen mobiler Datenbanksysteme Wir unterscheiden im weiteren Verlauf des Buches zwischen einem mobilen Datenbanksystem auf der einen, und einem mobilen Informationssystem auf der anderen Seite: Mobiles Datenbanksystem

12

■ ■ ■

■

Mobiles Datenbanksystem. Ein mobiles Datenbanksystem ist definiert als Small-Footprint-Datenbanksystem, das auf einem mobilen Client (beispielsweise einem PDA) installiert ist und auf diesem Daten persistent in einer strukturierten Weise speichert. Ein mobiles Datenbanksystem ist an die speziellen Bedürfnisse und Anforderungen der leistungsschwachen mobilen Clients angepasst. Das Ziel dabei ist, trotz der physikalischen

1 Einführung

Restriktionen Datenbankfunktionalität bereitzustellen. In der Praxis werden oftmals Daten einer zentralen Datenbank auf einen mobilen Client repliziert, damit auch im Disconnected Mode eine weitere Datenverarbeitung unabhängig von einer bestehenden Netzwerkverbindung möglich ist. Auf dem Client durchgeführte Änderungen müssen dann später mit den Originaldaten der zentralen Datenbank wieder abgeglichen werden. Die mit einer mobilen Datenbank gespeicherten Daten werden als mobile Daten bezeichnet. ■

Mobiles Informationssystem. Ein mobiles Informationssystem ist das Gesamtsystem, bestehend aus einer oder mehreren mobilen Anwendung und der darunter liegenden Datenhaltungsschicht, in unserem Fall einem mobilen Datenbanksystem. Wenn auf den Einsatz mobiler Datenbanksysteme auf den mobilen Clients verzichtet wird, trotzdem aber mobil auf zentral verfügbare Informationsressourcen zugegriffen wird, spricht man von Mobilität unterstützenden Informationssystemen.

Mobiles Informationssystem

Nach dieser Begriffsdefinition wird im folgenden Abschnitt ein detaillierter Überblick über den weiteren Aufbau des Buches gegeben.

1.5 Gliederung des Buches Das Buch gliedert sich in drei grosse Schwerpunkte. Im ersten Teil (Kapitel 2 bis 8) werden die konzeptionellen Grundlagen mobiler Datenbanksysteme vorgestellt. Diese Kapitel dienen dazu, ein grundlegendes Verständnis relevanter Problemstellungen und theoretischer Konzepte zu schaffen. Im zweiten Teil des Buches, der Kapitel 9 umfasst, erfolgt eine ausführliche Untersuchung und Bewertung existierender kommerzieller mobiler Datenbanksysteme. Der dritte Teil des Buches, der aus den Kapiteln 10 und 11 besteht, fokussiert die praktische Umsetzung der zuvor vorgestellten Theorie und verdeutlicht dies anhand der Entwicklung einer mobilen Datenbankanwendung.

Grobgliederung

Kapitel 2 geht zunächst auf die wichtigsten Grundlagen des Mobile Computings ein. Während Abschnitt 2.1 klärt, was unter Mobilität ganz allgemein zu verstehen ist, definiert Abschnitt 2.2 drei verschiedene Typen von Mobilität. Danach untersucht Abschnitt 2.3 grundlegende Eigenschaften mobiler Datenbankanwendungen. In diesem Zusammenhang werden neben Anforderungen, die sich di-

Kapitel 2

1.5 Gliederung des Buches

■ ■ ■

13

Kapitel 3

Kapitel 4, 5, 6, 7 und 8

Kapitel 9

14

■ ■ ■

rekt aus dem mobilen Kontext ableiten lassen, auch solche Anforderungen untersucht, die bereits an herkömmliche Hochleistungsdatenbanksystemen gestellt werden (wie die Unterstützung von Nebenläufigkeit oder die Überwachung von Integritätsbedingungen). Abschnitt 2.4 klassifiziert schließlich mobile Endgeräte, um dadurch eine bessere Beurteilung der unterschiedlichen Charakteristika und Einsatzmöglichkeiten aktueller mobilen Clients zu ermöglichen. Im letzten Abschnitt von Kapitel 2 werden die bereits angesprochenen Location Based Services (LBS) und die mit ihnen verbundenen Konzepte genauer vorgestellt. Ausgehend von dem in Kapitel 2 untersuchten Mobile Computing, werden in Kapitel 3 Architekturen mobiler Informationssysteme beschrieben. In der Forschung und Entwicklung wurden in den letzten Jahren viele verschiedene Architekturen vorgeschlagen, die sich jedoch alle – zumindest mehr oder weniger – einigen wenigen generischen Architekturen zuordnen lassen. Abschnitt 3.1 geht auf Client/Server-Architekturen ein, wie sie vor allem bei den kommerziellen Systemen (vgl. Kapitel 9) anzutreffen sind. Eine zweite wichtige Architekturvariante, die auf einem verteilten Datenbanksystem basiert, wird in Abschnitt 3.2 vorgestellt. Ausgangsbasis ist ein verteiltes Datenbanksystem, das um drahtlos angebundene Clients ergänzt wird. In Abschnitt 3.3 wird die Client/Server-Architektur um zusätzliche Middleware-Komponenten ergänzt. Als viertes und letztes Szenario mobiler Datenverarbeitung wird in Abschnitt 3.4 schließlich der Einsatz mobiler Agenten beschrieben. Diese wurden zwar ursprünglich nicht in Datenbanksystemen eingesetzt, der Einsatz mobiler Agenten im Rahmen einer mobilen Datenverarbeitung hat aber durchaus großen Nutzen. Die Kapitel 4, 5, 6, 7 und 8 widmen sich konkreten Implementierungskonzepten mobiler Datenbanksysteme. Während Kapitel 4 die Replikation und die Synchronisation untersucht, werden in Kapitel 5 verschiedene mobile Transaktionsmodelle vorgestellt. Kapitel 6 geht danach auf die Charakteristika von leichtgewichtigen Anfragesystemen für mobile Clients ein. In Kapitel 7 wird die Darstellung von Informationen auf mobilen Geräten genauer untersucht. Kapitel 8 geht auf Pico-Datenbanksysteme ein, einer interessanten Spezialform mobiler Datenbanksysteme. Dabei handelt es sich um Datenbanksysteme für Smartcards. Wichtige Themen sind Speicherkonzepte und die Anfrageausführung. Einen Schwerpunkt des Buches bildet Kapitel 9, in dem sowohl ein Vergleich der Architekturen und Implementierungskonzepte, als auch eine Bewertung der Synchronisationsverfahren kommerzieller mobiler Datenbanksysteme vorgenommen wird. Insgesamt sechs

1 Einführung

mobile Datenbanksysteme – IBM DB2 Everyplace (Abschnitt 9.1), Oracle 10g Lite (Abschnitt 9.2), Sybase Adaptive Server Anywhere und UltraLite (Abschnitt 9.3), Tamino Mobile Suite (Abschnitt 9.4), PointBase Micro (Abschnitt 9.5) und Microsoft SQL Server 2000 CE Edition (Abschnitt 9.6) – werden dabei einer genaueren Untersuchung unterzogen und im letzten Abschnitt 9.8 dieses Kapitels anhand vorgegebener Kriterien miteinander verglichen. Abschnitt 9.7 geht davor noch auf drei kleinere Nischenanbieter respektive Opensource-Projekte (eXtremeDB, hSQLDB, InstantDB) ein. Kapitel 10 stellt die Implementierung einer mobilen Datenbankanwendung vor. Dadurch werden beispielhaft die Probleme und Lösungsmöglichkeiten bei der Konzeption und Erstellung mobiler Datenbankanwendungen verdeutlicht. Das gewählte Anwendungsszenario – eine Adressdatenbank – wird dabei für Palm-OS realisiert. Es werden insgesamt drei Realisierungsalternativen vorgestellt und implementiert. Die erste Realisierungsalternative ist eine Programmierung in der Programmiersprache C. Die zweite Variante verwendet den zusammen mit DB2 Everyplace ausgelieferten Mobile Application Builder. In einer dritten Variante wird das Anwendungsszenario als Java-Anwendung zusammen mit dem mobilen Datenbanksystem PointBase Micro realisiert. Im letzten Abschnitt von Kapitel 10 werden die drei vorgestellten Möglichkeiten der Entwicklung mobiler Datenbankanwendungen verglichen. Kapitel 11 beschreibt die wichtigsten Features und Möglichkeiten des JDBC Optional Packages für einen Einsatz auf mobilen Clients. Dabei handelt es sich um eine leichtgewichtige Version der klassischen JDBC-Schnittstelle. Abschließend wird in Kapitel 12 ein Ausblick auf die weiteren Trends und Entwicklungen bei mobilen Datenbanksystemen gegeben.

1.5 Gliederung des Buches

Kapitel 10

Kapitel 11, 12

■ ■ ■

15

2 Mobile Computing

Auf die Erfindung und kommerzielle Vermarktung des tragbaren Computers durch Adam Osborne im April 1981 geht die heutige mobile Informationstechnologie zurück. Das damals präsentierte Osborne-1-Rechnersystem darf allerdings nicht mit mobilen Computern verglichen werden, wie man sie heute kaufen kann. Als 12kg schwerer Koffercomputer, mit eingebautem 5-Zoll-Bildschirm, zwei Z80-Prozessoren, CP/M1 sowie zwei Floppy-Laufwerken setzte das Gerät trotzdem neue Maßstäbe. Dieses Kapitel ist wie folgt gegliedert: Abschnitt 2.1 definiert zunächst, was unter Mobilität allgemein, sowie unter den Schlagwörtern Mobile Computing, Nomadic Computing, Pervasive Computing und Ubiquitous Computing zu verstehen ist. Verschiedene Typen von Mobilität werden in Abschnitt 2.2 definiert und erläutert. Danach geht Abschnitt 2.3 kurz auf die wichtigsten Grundlagen und Klassen drahtloser Netzwerke ein. Abschnitt 2.4 beschreibt erforderliche Eigenschaften mobiler Datenbank- und Informationssysteme. In Abschnitt 2.4 wird eine wichtige mobile Anwendung, die Location Based Services, ausführlich vorgestellt. Abschnitt 2.5 schließt dieses Kapitel ab, indem heute verfügbare mobile Endgeräte vorgestellt und klassifiziert werden.

Geschichte des Mobile Computings

2.1 Begriffe Die revolutionäre Idee, Computersysteme mobil mit sich zu führen, um zu jedem Zeitpunkt und an jedem Standort die benötigte Rechenkraft verfügbar zu haben, kann als Ursprung weiterer, zum Mo1

CP/M (Control Programm for Microcomputers) war zu Beginn der 1980er Jahre das Standard-Betriebssystem für Mikrocomputer. Es war das erste DISK Operating System (DOS) und bildete damit die Grundlage für die heutigen Windows-Systeme von Microsoft. MS-DOS selbst stammt von einem CP/M-Clone namens QDOS (Quick and Dirty Operating System) ab, das von Microsoft später für den ersten IBM PC eingekauft wurde.

2.1 Begriffe

■ ■ ■

17

Technische Entwicklung

Mobilität

Mobile Computing

bile Computing artverwandter Forschungsgebiete, wie des Pervasive Computings oder des Nomadic Computings, betrachtet werden. Die ständig voranschreitende Miniaturisierung von Computerkomponenten und die gleichzeitige Entwicklung drahtloser Vernetzungstechnologien ermöglichten seit 1981 enorme Fortschritte in der Entwicklung mobiler Geräte. So reicht das Spektrum heute verfügbarer mobiler Computersysteme von leistungsfähigen Notebooks, über PDAs bis hin zu Handys, Smartphones, hoch integrierten Wearables und auf Smartcards integrierten Rechnersystemen. Drahtlose Kommunikationsnetze und damit verknüpfte Datendienste sind in den Industrienationen nahezu flächendeckend verfügbar. Neue, noch schnellere Kommunikationsnetze, wie zum Beispiel die Mobilfunknetze der dritten Generation (Stichwort: UMTS), führen schon demnächst zu einem weiteren Sprung der verfügbaren Netzkapazitäten. Die Leistungsschwäche mobiler Clients und Infrastrukturprobleme gehören somit zunehmend der Vergangenheit an. Als direkte Konsequenz steigt die Anzahl mobiler Anwendungen und Clients stetig an und es rücken Anwendungsszenarien in den Vordergrund, die bislang keine oder nur eine untergeordnete Rolle spielen. Gerade die Entwicklung mobiler Datenbankanwendungen weist dabei eine sehr hohe Wachstumsdynamik auf. Der Begriff „Mobilität“ wird definiert, als die geographischen und zeitlichen Änderungen von Standorten, denen ein mobiler Client, beispielsweise ein PDA, unterworfen ist. Dementsprechend kann der Begriff „Mobile Computing“ wie folgt definiert werden: ■

Mobile Computing. Das Forschungsgebiet des Mobile Computing befasst sich mit dem Einsatz von Informationstechnologie in mobilen Umgebungen. Es berücksichtigt unter anderem die Kommunikation von mobilen Nutzern untereinander (beispielsweise über mobile Ad-Hoc-Netze), Anforderungen an und Eigenschaften von mobilen Clients und die Entwicklung neuer mobiler Anwendungen.

Neben dem Begriff Mobile Computing entstanden in letzter Zeit einige weitere Begriffe wie Nomadic Computing oder Pervasive Computing, die nun ebenfalls definiert werden. Dabei ist zu beachten, dass Mobile Computing eine Obermenge der nachfolgend vorgestellten Begriffe darstellt [Rot03]:

18

■ ■ ■

2 Mobile Computing

■

■

Nomadic Computing2. Nomadic Computing ist die Verwendung mobiler Clients zusammen mit drahtlosen Netzwerktechnologien. Durch die Verwendung des Wortes Nomadic wird (im Vergleich zum übergeordneten Begriff Mobile Computing) die wesentlich stärkere Fokussierung auf die Mobilität verdeutlicht. Dabei stehen insbesondere die drahtlosen Kommunikationsfähigkeiten mobiler Clients im Mittelpunkt.

Nomadic Computing

Ubiquitous Computing3/Pervasive Computing4. Der Begriff des Ubiquitous Computing wurde erstmals in einem Artikel von Mark Weiser in der amerikanischen Fachzeitschrift Scientific American verwendet [Wei91]. Weiser unterscheidet drei Phasen in der Geschichte der Computernutzung: die Phase der Mainframes (Phase 1), die aktuell noch dominierende Phase der Personal Computer (Phase 2), sowie die sich daran anschließende Phase des Ubiquitous Computing (Phase 3). Die dritte Phase ist charakterisiert durch kleine, weltweit vernetzte Systeme, die überall verfügbar sind. Laut Weiser erfolgt der Übergang zur Phase des Ubiquitous Computing bis 2020. Ein wichtiger Teilaspekt der Vision des Ubiquitous Computing ist die Forderung, dass eine weit reichende Automatisierung digitaler Dienstleistungen (erbracht durch pervasive Rechnersysteme) erfolgt. Unter pervasiven Rechnersystemen sind in Alltagsgegenstände wie Uhren oder Kugelschreibern integrierte Computer zu verstehen. Nutzern bleibt dabei die technische Umsetzung einer in Anspruch genommenen Dienstleistung völlig verborgen. Die Computersysteme selbst treten in den Hintergrund und werden in Bedienung und Administration von den Nutzern entkoppelt. In diesem Zusammenhang entstanden auch die Begriffe Calm Computing, Invisible Computing und Disappearing Computing. Statt des Begriffes Ubiquitous Computing wird häufig auch der Begriff Pervasive Computing verwendet.

Ubiquitous Computing, Pervasive Computing,

In diesem Buch stehen mobile Datenbanksysteme, insbesondere Aspekte der mobilen Datenerfassung, Speicherung und des Retrieval im Vordergrund. Dies sind Themen, die eher dem klassischen Mobile Computing und dem Nomadic Computing zuzuordnen sind. Ubiquitous Computing und Pervasive Computing rücken dagegen eher in den Hintergrund.

2

nomadic: nomadisch, wandernd ubiquitous: allgegenwärtig, überall zu finden 4 pervasive: durchdringend, überall vorhanden, beherrschend 3

2.1 Begriffe

■ ■ ■

19

2.2 Mobilität und Drahtlosigkeit Die Begriffe Mobilität und Drahtlosigkeit werden fast immer synonym verwendet, obwohl sich die beiden Begriffe in ihrer Semantik deutlich unterscheiden. Mobilität kann als Eigenschaft eines Hosts (Rechnersystems), eines Anwenders oder eines Dienstes charakterisiert werden, eine flexible Nutzung, unabhängig von einem aktuellen Standort, zu ermöglichen. Drahtlosigkeit dagegen stellt die Frage der Anbindung an das Netz in den Vordergrund. Von einer drahtlosen Anbindung spricht man, wenn ein Client mit Hilfe einer beliebigen Funktechnik (Wireless-LAN, Mobilfunk, Bluetooth, HiperLAN, Infrarot) kommuniziert. Die beiden Begriffe Drahtlosigkeit und Mobilität sind also orthogonal zueinander. Aus diesem Grund existieren insgesamt vier Szenarien (vgl. Abbildung 2.1), die die vier möglichen Begriffskombinationen beschreiben.

Korrelation

20

■ ■ ■

Mobilität Drahtlosigkeit

Abb. 2.1: Drahtlosigkeit vs. Mobilität

Nichtmobile Kommunikation

Mobile Kommunikation

Drahtgebundene Kommunikation

Stationäres Rechnersystem

Notebook mit Modemkabelanbindung

Drahtlose Kommunikation

Stationäres Rechnersystem in einem Wireless LAN

Notebook, PDAs, Handys mit drahtloser Anbindung

Während mit dem Festnetz verbundene, stationäre Host weder durch Drahtlosigkeit noch Mobilität charakterisiert sind, unterstützen Clients wie Mobiltelefone oder (entsprechend ausgerüstete) PDAs sowohl Mobilität als auch Drahtlosigkeit. Darüber hinaus existieren auch Szenarien, in denen lediglich von Drahtlosigkeit, nicht aber von Mobilität gesprochen wird (beispielsweise bei der Verwendung von Wireless-LAN als Alternative für Kabel bei stationären PCs). Ein Beispiel für den komplementären Fall (Mobilität, aber keine Drahtlosigkeit) ist ein Notebook, das über ein Modemkabel an das Festnetz angebunden wird. Mobilität, im Gegensatz zur immer eindeutig kategorisierbaren Drahtlosigkeit, kann verschiedene alltägliche Szenarien mehr oder weniger stark beherrschen. Objekte des Alltags können mobil sein, müssen es aber nicht. Ein fixiertes Objekt kann Mobilität unterstützen, ohne selbst mobil zu sein (beispielsweise ein EmailWebdienst). Es ist offensichtlich, dass es verschiedene Interpretationen von Mobilität gibt. Eine mögliche Unterscheidung nach [Rot03] differenziert zwischen drei unterschiedlichen Typen von Mobilität,

2 Mobile Computing

die sich jedoch nicht gegenseitig ausschließen. Diese sollen in den folgenden Abschnitten vorgestellt werden.

2.2.1 Endgerätemobilität Endgerätemobilität liegt dann vor, wenn ein mobiles Endgerät auch dann einen permanent gesicherten drahtlosen Zugriff auf das Kommunikationsnetz hat, während es seinen Standort ändert, sich also räumlich bewegt. Es spielt dabei keine Rolle, ob das mobile Endgerät einem konkreten Benutzer fest zugeordnet ist. Dies kann der Fall sein (wie im Falle eines Mobiltelefons), muss es aber nicht. Abbildung 2.2 veranschaulicht den Fall, bei dem ein mobiler Client einem Nutzer fest zugeordnet ist. Entscheidend ist jedoch die jederzeit mögliche drahtlose Anbindung des mobilen Clients an das Festnetz. Endgerätemobilität geht immer direkt einher mit der Verfügbarkeit drahtloser Netzwerke.

fest zugeordnet

Dynamische Verbindung

Netzwerk

Abb. 2.2: Endgerätemobilität [Rot03]

2.2.2 Benutzermobilität Bei der so genannten Benutzermobilität verwendet ein Nutzer, der seinen Standort ändert, beliebige (fest installierte oder mobile) Endgeräte. Kennzeichnend für diesen Typ von Mobilität ist die Tatsache, dass ein Benutzer selbst, und nicht das von ihm verwendete Endgerät mobil ist (auch wenn zusätzlich Endgerätemobilität vorliegen kann). Im Sinne reiner Benutzermobilität ist ein mobiler Nutzer auf das Vorhandensein entsprechender Infrastrukturen an den Nutzungsstätten (Arbeitsplatz, Hotel, Zug) angewiesen. Abb. 2.3: Benutzermobilität [Rot03]

temporär zugeordnet Permanente Drahtlosverbindung

Netzwerk

temporär zugeordnet

2.2 Mobilität und Drahtlosigkeit

■ ■ ■

21

2.2.3 Dienstmobilität Von Dienstmobilität spricht man, wenn ein Benutzer einen Kommunikations- oder Informationsdienst in Anspruch nehmen kann, ungeachtet von dem Standort, von dem er auf den Dienst zugreifen will. Die Dienste selbst, die zwar nicht mobil sind, jedoch einen mobilen Zugriff unterstützen, stehen im Mittelpunkt. Dienste werden dabei, für den Nutzer völlig transparent, auf die immer gleiche Art und Weise angeboten (beispielsweise ein Email-Webinterface). Typischerweise tritt Dienstmobilität zusammen mit Endgeräte- oder Benutzermobilität auf. Abb. 2.4: Dienstmobilität [Rot03]

feste / temporäre Zuordnung Netzwerk Permanente Drahtlosverbindung

wechselnder Ort

feste / temporäre Zuordnung

Dienst

Vermittlung eines Dienstes

2.3 Grundlagen drahtloser Netze Die mobile Arbeitswelt verlangt häufig nach einer Datenverarbeitung bzw. Datenübertragung, die nicht durch feste Leitungen beschränkt ist. Die Lösung liegt im Einsatz von Funknetzen, von denen mittlerweile bereits eine ganze Palette existiert. Diese sind jedoch weitgehend inkompatibel zueinander. Aktuell sind – neben den Mobilfunknetzen – Trends hin zum bandbreitenstarken Wireless-LAN einerseits, und zur Vernetzung von Endgeräten mit der BluetoothTechnologie andererseits zu erkennen. Alles, was im Zusammenhang mit drahtloser und mobiler Kommunikation wichtig ist, lässt sich vier Schichten des sieben Schichten umfassenden ISO-OSI-Referenzmodells (vgl. Abbildung 2.5) zuordnen. Die untersten beiden Schichten adressieren im Fall der Drahtloskommunikation die Datenübertragung über die Luftschnittstelle. Die unterste Schicht beschreibt dabei die eigentliche Bitüber-

22

■ ■ ■

2 Mobile Computing

tragung, beispielsweise die Modulation digitaler Daten auf eine Trägerwelle. Da der Äther ein von vielen Clients gemeinsam genutztes Übertragungsmedium darstellt, sind Fragen des Mehrfachzugriffs und der gemeinsamen Nutzung des Übertragungsmediums ebenfalls relevant (Stichwort: Frequenzmultiplexing). Dies wird in der Sicherungsschicht bearbeitet. Damit sind in der Bitübertragungs- und der Sicherungsschicht die entscheidenden Unterschiede zur normalen, kabelgebundenen Kommunikation zu finden.

7 6 5 4 3 2 1

Anwendungsschicht Darstellungsschicht

Dienstvermittlung Heterogenität Leistungsfähigkeit mobiler Clients

Abb. 2.5: ISO-OSIReferenzmodell

Kommunikationsschicht Transportschicht Vermittlungsschicht

Handover, Roaming, Ad-Hoc-Routing

Sicherungsschicht

Mehrfachzugriff Bitübertragung über die Luftschnittstelle

Bitübertragungsschicht

Der Vermittlungsschicht (Schicht 3) fallen Aufgaben im Rahmen der Koordination mobiler Bewegungen zu, wie sie beispielsweise bei Standortveränderungen von Nutzern anfallen. Netzwerkverbindungen müssen ohne umfangreiche Konfigurationsarbeiten schnell und einfach hergestellt, der gewünschte Kommunikationspartner schnell ermittelt werden. Im Falle eines Handovers zwischen verschiedenen Funkzellen darf eine bereits etablierte Netzwerkverbindung nicht unterbrochen werden. Gerade in mobilen Umgebungen kommen der Vermittlungsschicht somit wichtige Aufgaben zu. Den sich anschließenden höheren Schichten 4, 5 und 6 kommt dagegen keine besondere Rolle gegenüber der drahtgebundenen Kommunikation zu. Sind in den untersten drei Schichten alle Verfahrensweisen definiert, können zum Beispiel beliebige Transportprotokolle eingesetzt werden (auch wenn diese eigentlich nicht für einen Einsatz in mobilen Umgebungen konzipiert wurden und deswegen eine schlechte Performanz aufweisen können). Für mobile Anwendungen dagegen wieder relevant ist die oberste Anwendungsschicht (Schicht 7). Konkrete Problemstellungen sind hier beispielsweise: ■

Dienstvermittlung. Im Vordergrund steht die automatisierte Dienstfindung und Dienstnutzung, auch in mobilen Ad-HocNetzen.

■

Heterogenität. Mobile Umgebungen vereinen aufgrund ihrer Dynamik sehr häufig sehr viele verschiedene, heterogene Platt-

2.3 Grundlagen drahtloser Netze

■ ■ ■

23

formen (Betriebssysteme, mobile Clients, Backend-Systeme). Diese Heterogenität muss überwunden werden, um eine wirklich übergreifende Mobilkommunikation zu ermöglichen. Drahtlose Netze können in vielen Anwendungsszenarien eingesetzt werden. Einige Beispiele sind: ■

Einsatz in Katastrophengebieten, in denen vorhandene Netzwerkinfrastrukturen (egal ob kabelgebunden oder drahtlos) ausgefallen sind.

■

Einsatz in medizinischen Einrichtungen wie Krankenhäusern, in denen Gerätschaften oft ihren Standort wechseln. Allerdings können in Krankenhäusern nur solche Funknetze aufgebaut werden, die keine Konflikte mit empfindlichen Überwachungsgeräten oder anderen technischen Apparaten verursachen.

■

Einsatz in der industriellen Fertigung, d.h. am Produktionsprozess teilhabende mobile Einheiten, wie z.B. Gabelstapler, werden an ein drahtloses Netzwerk angebunden. Unter Verwendung von auf transportierten Gütern angebrachten RFID-Chips (Radio Frequency Identification), die direkt mit dem Bordsystem des Gabelstaplers kommunizieren, kann so eine lückenlose elektronische Datenverarbeitung erreicht werden.

■

Einsatz auf Messen, wo drahtlose Netze die Präsentation von Anwendungen deutlich vereinfachen können.

2.3.1 Mobilfunk in Deutschland (und weltweit) Die ersten Versuche mit Funktelefongesprächen aus Zügen heraus führte die Deutsche Reichsbahn im Raum Berlin bereits im Jahr 1918 durch. Schließlich wurde im Jahre 1926 dann auf der Strecke zwischen Berlin und Hamburg ein Funktelefondienst angeboten (allerdings nur den Fahrgästen der ersten Klasse). Die für die Funkkommunikation notwendigen Antennen waren längs auf den Wagendächern gespannte Drähte. Als ortsfeste Sende- und Empfangsantennen dienten entlang der Gleise installierte Telegrafenleitungen. In den 30er- und 40er Jahren folgten Versuche im Mittelwellen- und Kurzwellenbereich. Das weltweit erste größere Mobilfunknetz entstand aber 1946 in den USA. Anfang der 50er-Jahre wurden dann auch in Deutschland auf der UKW-Technik basierende lokale Netze in verschiedenen Regionen aufgebaut (beispielsweise der Rhein-

24

■ ■ ■

2 Mobile Computing

Funk, der vor allem für die Kommunikation der Binnenschiffer untereinander gedacht war). Das erste Mobilfunknetz (das A-Netz) startete in Deutschland bereits 1958 und funkte im Frequenzbereich von 160 MHz. Betreiber war die Bundespost. In den 1970er Jahren erreichte das A-Netz schließlich eine fast flächendeckende Versorgung Deutschlands (ca. 80 Prozent Netzabdeckung). Jedes Gespräch wurde damals noch vom "Fräulein vom Amt" handvermittelt. Sobald der Funkbereich einer Basisstation verlassen wurde, konnte die Gesprächsverbindung nicht mehr aufrechterhalten werden – stattdessen musste eine unterbrochene Verbindung in der neuen Funkzelle erneut vermittelt werden. Auslandsgespräche waren überhaupt nicht möglich. Bereits 1972 begann der Aufbau des B-Netzes, mit dem Selbstwählverkehr in beiden Richtungen (also zwischen Mobil- und Festnetz) möglich wurde. Größter Nachteil des B-Netzes war die Anforderung, den ungefähren Standort des gewünschten mobilen Kommunikationspartners (definiert durch eine Vorwahl) zu kennen. Bis zu seinem Ende 1994 telefonierten mehr als 27000 Nutzer über das B-Netz. Insbesondere mit dem dritten Mobilfunknetz in Deutschland, dem C-Netz, wurde dann die Mobilkommunikation das erste Mal für größere Nutzergruppen möglich. Das C-Netz startete in Deutschland 1985 (in Österreich bereits im November 1984). Zum ersten Mal war damals ein Mobilfunkteilnehmer in ganz Deutschland unter der gleichen Rufnummer erreichbar. Der größte Unterschied zu den vorherigen leitungsvermittelten A- und B-Netzen lag in der Zellenstruktur des C-Netzes. Neben der Sprachtelefonie waren mit dem CNetz auch Datenverbindungen und Faxverbindungen möglich (mit maximal 2400 bit/s). Zum Zeitpunkt der Abschaltung des C-Netzes im Jahr 2000 betrug die Nutzeranzahl noch 803000. Das A-, B- und C-Netz werden zusammen als Mobilfunknetze der ersten Generation (1G) bezeichnet. In anderen Ländern Europas wurden währenddessen alternative, zu den deutschen inkompatible Netze entwickelt.

Mobilfunk der 1. Generation

Erst mit den in den 1990er Jahren aufkommenden Netzen der zweiten Generation (2G) änderte sich die Zersplitterung des europäischen Mobilfunktechnologie. Im Mittelpunkt der Entwicklung stand vor allem eine bessere Sprachqualität, aber auch eine Optimierung des Durchsatzes und der Netzabdeckung. International am erfolgreichsten ist mittlerweile das Global System for Mobile Communication (GSM), das sich vor allem in weiten Teilen Europas, des nahen Ostens und Afrikas durchgesetzt hat. In den USA haben sich dagegen die beiden Standards TDMA/IS-136 und CDMA/IS-95 und in

Mobilfunk der 2. Generation

2.3 Grundlagen drahtloser Netze

■ ■ ■

25

Japan PDC durchgesetzt. Die aktuell drei wichtigsten dieser vier genannten Mobilfunkstandards – GSM, TDMA/IS-136, PDC – werden nun in ihren wichtigsten Konzepten und Funktionen kurz beschrieben. Exkurs: Grundlagen der Mobilkommunikation Jede Mobilkommunikation ist an elektromagnetische Wellen gebunden, mit deren Hilfe Nutzdaten übertragen werden können. Bei niedrigen Frequenzen (ab 300 MHz) spricht man von Bodenwellen, bei höheren Frequenzen (ab 900 MHz) von Raumwellen. Um digitale Informationen auf eine Trägerfrequenz zu übertragen, werden Modulationsverfahren eingesetzt, die digitale in analoge Signale (digitale Modulation) umwandeln. Diese analogen Signale werden danach auf eine Trägerfrequenz aufmoduliert (analoge Modulation). Im Vergleich zu verkabelten Netzwerken haben Funknetze wesentlich geringere Datenraten. Die Gründe dafür liegen einerseits darin, dass die für die Kommunikation benutzten Frequenzbänder zumeist sehr klein sind, das heisst nur geringe Bandbreiten aufweisen. Andererseits benutzen sehr oft viele Nutzer das Übertragungsmedium gleichzeitig. Zwar kann durch einen Wechsel auf höhere Frequenzen die Datenrate erhöht werden, allerdings führt dies zu steigenden Kosten und einer anwachsenden Störanfälligkeit. Die für Datenübertragungen genutzten Frequenzen werden oft durch staatliche Regulierungsbehörden kontrolliert. In Deutschland kümmert sich beispielsweise die Regulierungsbehörde für Post & Telekommunikation (RegTP) um eine korrekte Nutzung des Frequenzbereichs von 9 KHz bis 275 GHz. Größtes Problem jeder Mobilkommunikation sind Interferenzen. Interferenzen sind Störungen des eigenen Signals durch andere, fremde Übertragungssignale. Gerade die Mobilkommunikation ist für Interferenzen besonders anfällig, da eine geeignete Abschirmung des Kommunikationsmediums wie bei herkömmlichen Kabeln nicht vorhanden ist. Die Ursache für Interferenzen können aber nicht nur andere Signale sein, auch das Problem der Mehrwegeausbreitung kann zu Signalstörungen führen. Bei der Mehrwegeausbreitung erreicht ein Signal durch Streuungen, Beugungen und Reflexionen den Empfänger mehrfach, oft zeitversetzt. Die entstehende Überlagerung verschiedener Signale ist schwer zu korrigieren. Im Idealfall breiten sich die elektromagnetischen Wellen vom Sender vollkommen gleichmäßig aus. Zur Veranschaulichung kann man sich auch vorstellen, dass alle elektromagnetischen Wellen auf Kugeloberflächen liegen, deren Zentrum der Sender ist. In der Theorie reduziert sich die Intensität elektromagnetischer Wellen mit dem Quadrat des Ab-

26

■ ■ ■

2 Mobile Computing

standes, das heisst wenn sich der Abstand eines Empfängers vom Sender verdoppelt, reduziert sich die Intensität der elektromagnetischen Wellen auf ein Viertel. In realen Einsatzumgebungen wird die Wirkung elektromagnetischer Wellen allerdings noch wesentlich stärker reduziert (z.B. durch Gebäude, Reflexionen, sonstige Störquellen), so dass die Intensität der elektromagnetischen Wellen nicht im Quadrat, sondern in der vierten Potenz abnimmt. Wird die Distanz zwischen Empfänger und Sender verdoppelt, muss also die 16fache Sendeleistung aufgebracht werden, um beim Empfänger dieselbe Intensität zu erreichen. Um die Häufigkeit von Interferenzen zu reduzieren, können Multiplexverfahren eingesetzt werden. Diese ermöglichen zudem eine bessere Ausnutzung eines Frequenzbereiches durch eine koordinierte Mehrfachnutzung eines gemeinsamen Mediums. Dabei unterscheidet man zwischen Frequenz- und Zeitmultiplexverfahren. Bei Frequenzmultiplexing (Frequency Divison Multiplexing – FDM) wird das verfügbare Frequenzspektrum in mehrere disjunkte, das heisst sich nicht überlappende Frequenzbereiche unterteilt. Jeder Übertragungskanal (man denke an ein einzelnes Radioprogramm) bekommt anschließend exklusiv genau einen solchen Frequenzbereich zugeteilt. Das Zuteilungsverfahren wird auch als Frequency Division Multiplexing Access (FDMA) bezeichnet. Vorteilhaft bei diesem Verfahren ist insbesondere die einfache technische Umsetzung, da zwischen Sender und Empfänger keine besondere Koordination notwendig ist. Klassisches Beispiel für einen Einsatz von FDM sind die Sendefrequenzen von Radiostationen. Innerhalb eines Versorgungsbereiches dürfen keine zwei Sender in der gleichen oder unmittelbar benachbarten Frequenz senden. Beim Zeitmultiplexing (Time Division Multiplexing – TDM) wird jedem Sender ein bestimmter Frequenzbereich immer nur für einen bestimmten Zeitraum zugeteilt. Der Funkkanal kann dadurch in seiner vollen Bandbreite, wenn auch immer nur für kurze Zeit genutzt werden. Dazu muss der Frequenzbereich in Zeitschlitze aufgeteilt werden. Ist dies geschehen, kann jedem Sender in regelmäßigen Intervallen (die typischerweise eine Größenordnung von einigen Millisekunden aufweisen) ein Zeitschlitz zugeordnet werden. Dieses Verfahren wird auch als Time Division Multiplexing Access (TDMA) bezeichnet. Dieses Verfahren ermöglicht eine grosse Flexibilität bei der Zuteilung von Zeitschlitzen an Anwendungen, was vor allem im Zusammenhang mit Fragen des Quality of Service (QoS) wichtig ist. So können bandbreitenintensiven Anwendungen grosse Zeitschlitze, weniger anspruchsvollen Anwendungen, wie dem Versand von SMS, kleinere Zeitschlitze zugewiesen werden. Demgegenüber steht

2.3 Grundlagen drahtloser Netze

■ ■ ■

27

allerdings ein höherer technischer Aufwand zur Synchronisation zwischen Sender und Empfänger. 2.3.1.1 Mobilfunkstandards Global System for Mobile Communication (GSM)

Auf der 1984 stattfindenden Conférence des Administrations Européens des Postes et Télécommunications (kurz CEPT) wurde ein erster Schritt zur Vereinheitlichung der vielen Mobilfunknetze initiiert. Mit der Groupé Special Mobile wurde ein Organisationskomitee geschaffen, das sich um die Entwicklung eines gesamteuropäischen, einheitlichen Mobilfunkstandards kümmert. Die Ergebnisse dieser Bemühungen, die heutigen GSM-Mobilfunknetze, sind mittlerweile in mehr als 140 Ländern im Einsatz. Mehr als 60% aller Mobilfunknutzer weltweit telefonieren über GSM-Netze. GSM selbst ist ein auf Zellen basierendes Netz. Jede Zelle wird durch eine Sende- bzw. Empfangsstation, die auch Basisstation genannt wird, versorgt. Das ursprüngliche GSM arbeitete im Frequenzbereich um 900 MHz und wird deshalb auch als GSM 900 bezeichnet. Mittlerweile existieren jedoch verschiedene Varianten, die auf anderen Frequenzbänden arbeiten (GSM 1800, GSM 1900, GSM 400, GSM-R).

GSM-Architektur

Die GSM-Architektur [nach Rot03] besteht aus drei verschiedenen Teilsystemen, dem Funksystem (Base Station Subsystem), dem Vermittlungssystem (Mobile Switching and Management Subsystem) und dem Wartungssystem (Operation and Maintenance Subsystem). Das Funksystem regelt die Kommunikation zwischen Mobilgeräten und Basisstationen, bindet also die Nutzer an das Netzwerk an. Wichtigste Komponente des Vermittlungssystems ist das Mobile Switching Center (MSC), das den Netzwerkverkehr zwischen unterschiedlichen Funksystemen koordiniert und zusätzlich Verbindungen zu externen Netzwerken vermittelt. Das Wartungssystem stellt Methoden und Funktionen bereit, um ein funktionstüchtiges Netz aufrechtzuerhalten, dient letztlich also der Administration und Kontrolle des Netzwerks. Der Kern des Wartungssystems ist das Operation and Management Center (OMC), dessen wichtigsten Aufgaben die Konfiguration des Netzwerks, das Sicherheitsmanagement und die Administration geschäftskritischer Informationen (wie Gebührenabrechungen oder Kundendaten) sind. Der Zugriff auf verfügbare Netzkapazitäten erfolgt bei GSM über ein kombiniertes FDMA/TDMA-Verfahren. Beim Frequency Division Multiplexing Access (FDMA) wird der genutzte Frequenzbereich in je 124 Kanäle zum Senden und Empfangen von Daten aufgeteilt. Die so definierten 248 Frequenzkanäle werden durch die zu-

GSMLuftschnittstelle

28

■ ■ ■

2 Mobile Computing

sätzliche Anwendung eines Time Division Multiplexing AccessVerfahrens (TDMA-Verfahren) in so genannte TDMA-Rahmen untergliedert, von denen jeder eine Größe von 4,615ms besitzt. Jeder solche TDMA-Rahmen ist wiederum in acht Zeitschlitze (Timeslots) unterteilt, die jeweils 156,26 Bits an Nutzlast aufnehmen. Jede Anwendung, die einen physikalischen TDM-Kanal belegt (beispielsweise ein Telefongespräch), kann alle 4,615ms einen wiederkehrenden Zeitschlitz der Größe 156,26 Bits nutzen. Abzüglich eines Schutzabstandes von einigen Bits bleibt eine mögliche Nutzlast (Nutzdaten + Overhead) von 148 Bit pro Zeitschlitz. Da die Abstände zwischen den einzelnen Zeitschlitzen so gering sind, bleibt diese Aufspaltung der Nutzdaten gegenüber einem Nutzer jedoch völlig transparent. GSM unterstützt den Wechsel zwischen den verschiedenen Funkzellen eines Funknetzes zu Zeitpunkten bestehender, aktiver Kommunikationsverbindungen. Zwischen verschiedenen Funknetzen unterschiedlicher Netzbetreiber kann dagegen nur dann gewechselt werden, wenn gerade keine aktive Kommunikationsverbindung besteht. Wenn ein Nutzer von dem Versorgungsbereich einer Funkzelle in eine andere Funkzelle wechselt (Handover), muss eine bestehende Kommunikationsverbindung neu konfiguriert werden. Als Ursache eines Handovers kommen neben den räumlichen Bewegungen eines Nutzers vor allem sich verschlechternde Signaleigenschaften in Frage. In einem solchen Fall fällt die Entscheidung für einen Handover auf der Basis der Signalstärke zwischen mobilem Client und Basisstation. Ein Handover wird genau dann durchgeführt, wenn ■

der Empfangspegel auf dem mobilen Client einen bestimmten, vorgegebenen Schwellwert unterschreitet,

■

die maximal erlaubte Distanz zwischen mobilem Client und Basisstation erreicht ist,

■

die Bitfehler bei der Kommunikation einen bestimmten, vorgegebenen Schwellwert überschreiten.

GSM-Handover

Beim Handover werden folgenden Varianten unterschieden: ■

Intracell-Handover. Ein mobiler Client bleibt im Versorgungsbereich einer Zelle, da das Signal jedoch keine konstante Qualität bietet, wird auf eine andere Frequenz gewechselt.

■

Intercell-Handover. Ein mobiler Client wandert in den Versorgungsbereich einer anderen Zelle. Der mobile Client wechselt zunächst die Frequenz. Zusätzlich wird eine bereits aktive Ver-

2.3 Grundlagen drahtloser Netze

■ ■ ■

29

bindung im GSM-Vermittlungssystem auf die neue Basisstation geschleift. Beim Intercell-Handover werden zwei weitere Spezialfälle unterschieden. Beim internen Handover erfolgt ein Wechsel zwischen Funkzellen, die durch die gleiche Basisstation versorgt werden, beim externen Handover wird die neue Funkzelle durch eine eigene Basisstationen versorgt.

Roaming

HSCSD, GPRS, EDGE

30

■ ■ ■

Technisch gesehen wird also mit einem Handover (zumeist) zu einer neuen Basisstation gewechselt. Eine einmal von einem Mobile Switching Center des GSM-Vermittlungssystems betreute Kommunikationsverbindung wird dagegen nach dem Handover und einem damit verbundenen Wechsel zu einer neuen Basisstation auch weiterhin durch dasjenige Mobile Switching Center betreut, das die Kommunikationsverbindung ursprünglich vermittelt hat. Zwar gelangt ein mobiler Client mit einem Handover (zumeist) auch in den Bereich eines neuen Mobile Switching Center, doch wird eine bestehende Kommunikationsverbindung an ein neues MSC lediglich logisch übergeben. Das ursprüngliche MSC wird auch als Anker-MSC bezeichnet, da die Kommunikationsverbindung nach außen hin weiter durch dieses MSC kontrolliert wird. Es besteht eine enge Korrelation zwischen den beiden Begriffen Handover und Roaming. Roaming bezeichnet einerseits die Fähigkeit eines Mobilfunknetzes, jeden Teilnehmer unabhängig von dessen aktuellem Standort die Möglichkeit zur Mobilkommunikation einzuräumen (das heisst als Anrufer oder als Angerufener zu agieren). Andererseits bezeichnet Roaming die Möglichkeit, zwischen verschiedenen Mobilfunknetzen zu wechseln, ohne dass für jedes Funknetz ein eigener Nutzungsvertrag abgeschlossen wurde. So kann – trotz der Tatsache, dass ein Mobilfunkvertrag in Deutschland abgeschlossen wurde – beispielsweise auch in Österreich mobil telefoniert werden. Dazu muss der deutsche Netzbetreiber mit dem gewünschten österreichischen Netzbetreiber ein Roaming-Abkommen vereinbaren. Ein solches Abkommen regelt den für das Roaming notwendigen Informationsaustausch zugriffstechnischer und rechnungsrelevanter Daten zwischen den Netzbetreibern. Sowohl Handover-Prozesse als auch das Roaming wurden erst in den Mobilfunknetzen der zweiten Generation möglich. GSM war zunächst auf die reine Übertragung von Sprache ausgelegt. Mit der zunehmenden Verbreitung des Internets kam aber auch der rein datenorientierten Kommunikation eine immer wichtigere Rolle zu. Die direkt durch das GSM-Netz mögliche Datenkommunikation (mit einer Bandbreite von 9,6 kbit/s) weist jedoch einen großen Nachteil auf: der gesamte Datenverkehr erfolgt durch eine kanalvermittelte Übertragung, das heisst die anfallenden Kosten rich-

2 Mobile Computing

ten sich nicht nach der übertragenen Menge, sondern nach der Übertragungsdauer. Um diese Problematik zu umgehen, wurden neue Datendienste entwickelt, die auf den GSM-Netzen aufsetzen und eine effektivere Datenübertragung ermöglichen. Eine erste, aber noch kanalvermittelte Möglichkeit besteht darin, mehrere Kanäle zu einem großen Übertragungskanal zu bündeln. Dieser Vorgehensweise wird mit High Speed Circuit Switched Data (HSCSD) bezeichnet. Demgegenüber steht der General Packet Radio Service (GPRS), der eine paketorientierte Datenkommunikation verwendet. Dadurch wird eine bessere Auslastung vorhandener Netzressourcen und eine einfachere Abrechnung erbrachter Leistungen erreicht. Eine neue Weiterentwicklung dieser beiden Datendienste ist die EDGE-Technologie (Enhanced Data Rates for GSM Evolution). Dies ist ein Datendienst, der auch zusammen mit anderen Mobilfunkstandards (wie beispielsweise dem amerikanischen TDMA/IS-136) eingesetzt werden kann und bereits die Entwicklung in Richtung der Mobilfunkstandards der dritten Generation (3G) darstellt. Als Beispiel eines in den USA verbreiteten Mobilfunkstandards wird kurz auf TDMA/IS-136, das auch als US Digital Cellular System oder Digital Advanced Mobile Phone Service (D-AMPS) bekannt ist, eingegangen. Als Nachfolger des älteren analogen AMPS funkt TDMA/IS-136 im Frequenzbereich um 800 MHz (andere Frequenzbereiche werden ebenfalls benutzt). Die Architekturen von GSM und TDMA/IS-136 stimmen weitgehend überein, Unterschiede liegen in der Übertragungsweise von Daten über die Luftschnittstelle. Unterstützt werden sowohl analoge, als auch digitale Übertragungskanäle und zwischen beiden Kanaltypen kann ohne Schwierigkeiten gewechselt werden. Ähnlich wie GSM erlaubt auch TDMA/IS-136 die Ergänzung um einen zusätzlichen Datendienst, Cellular Digital Packet Radio (CDPD) genannt, der Datenraten von bis zu 19,2 kbit/s erlaubt.

TDMA/IS-136

Der wichtigste digitale Mobilfunkstandard in Japan ist Personal Digital Cellular (PDC), der eine Weiterentwicklung des älteren Japanese Digital Cellular darstellt (das wiederum auf dem amerikanischen AMPS basiert). Wie andere aktuelle Mobilfunktechniken (GSM oder TDMA/IS-136) greift auch PDC auf ein TDMAbasiertes Zugriffsverfahren zurück. PDC funkt in zwei Frequenzbereichen um 800 MHz und 1500 MHz. Insgesamt definiert PDC 800 verschiedene Frequenzbereiche, was sehr hohe Nutzerzahlen ermöglicht. PDC-Netze finden sich aktuell nur in Japan, in anderen Ländern haben sie keine Verbreitung gefunden.

PDC

2.3 Grundlagen drahtloser Netze

■ ■ ■

31

Mobilfunk der 3. Generation

Neben den Mobilfunkstandards der zweiten Generation (GSM, TDMS/IS-136, …) stehen schon die Mobilfunkstandards der dritten Generation (3G) in den Startlöchern. Wichtigster Vertreter ist das Universal Mobile Telecommunication System (UMTS). UMTS ist eine evolutionäre Weiterentwicklung von GSM-Netzen und soll durch eine maximale Datenrate von 2 MBit/s neue Dienste und Anwendungen ermöglichen, wie beispielsweise echtzeitfähige Dienste, Multimediadienste oder Videotelefonie.

2.3.2 Wireless-LAN Der Begriff Wireless-LAN (WLAN) kann in zwei verschiedenen Bedeutungen verwendet werden. Einerseits als genereller Sammelbegriff für alle Arten drahtloser Netzwerke, andererseits für diejenigen drahtlosen Netze, die auf der IEEE 802.11-Protokollfamilie aufbauen. Die zweite Bedeutungsvariante steht in diesem Abschnitt im Mittelpunkt. Drahtlose lokale Netze können auf zwei verschiedene Arten konfiguriert werden: als Ad-Hoc-Netze oder als Infrastrukturnetze. Unter Ad-Hoc-Netzen sind sich selbst organisierende Funknetze zu verstehen, die durch das beständige Hinzufügen bzw. Entfernen um mobile Clients einer hohen Dynamik unterliegen. Dabei kommunizieren alle Endgeräte spontan und ohne Zwischenschaltung einer Basisstation direkt miteinander. Den Ad-Hoc-Netzen stehen die Infrastrukturnetze gegenüber, die die Anbindung an andere Netze (beispielsweise ein kabelgebundenes Fast Ethernet) über eine Basisstation (auch Access Point genannt) vornehmen. Infrastrukturnetze sehen keine direkte Kommunikation zwischen verschiedenen Clients vor, sämtlicher Kommunikationsverkehr wird stets über eine Basisstation abgewickelt. Infrastrukturnetze sind im Vergleich zu Ad-HocNetzen wesentlich leichter aufzubauen, da fast die gesamte Netzfunktionalität in den Access Points integriert ist, was die Konfiguration der Clients und den Aufbau eines drahtlosen Netzwerks wesentlich erleichtert. Wireless-LAN nach dem 802.11-Standard arbeitet auf den beiden untersten und dabei vor allem auf der Bitübertragungsschicht des ISO/OSI-Referenzmodells. Entsprechende Netzwerkadapter (entweder in der Form von Netzwerkkarten oder direkt auf Hauptplatinen integriert) lassen sich ohne Probleme in jedes System einbinden. Auf bestimmte Protokolle auf der Anwendungsebene ist man somit nicht angewiesen. Trotz der Transparenz für höhere Protokollebenen kann es in der Praxis zu Problemen kommen, deren Ursachen in der höhe-

32

■ ■ ■

2 Mobile Computing

ren Bitfehlerrate und in der (im Vergleich zu festverkabelten Netzwerken größeren) Verzögerung bei der Datenübertragung liegen. Beispielsweise sind in einem drahtgebundenen LAN Antwortzeiten von zumeist weniger als einer Millisekunde zu erwarten. Demgegenüber steht eine Antwortzeit von bis zu vier Millisekunden in einem Wireless-LAN. Der Access Point ist innerhalb des WirelessLAN das einzige aktive ISO/OSI-Schicht-2-Element. Über ihn können Netzwerke mit unterschiedlicher physikalischer Schicht miteinander verbunden werden, beispielsweise einem Fast Ethernet oder einem Token Ring. Die Synchronisation des Zugriffs auf ein gemeinsames Übertragungsmedium managt die Medium Access Control (MAC), die Teil der Sicherungsschicht (Schicht 2) ist. Ebenso wie in Kabelnetzen können Kollisionen durch gleichzeitiges Senden entstehen. Um Kollisionen zu verhindern, können zwei verschiedene Verfahren eingesetzt werden, kollisionserkennende und kollisionsvermeidende. Um Kollisionen zu erkennen, müssen Stationen, die senden, das Übertragungsmedium permanent abhören. Nur dadurch können sie feststellen, ob alle übertragenen Daten auch unverfälscht übermittelt wurden. Dieses Verfahren ist unter der Bezeichnung Carrier Sense Multiple Access with Collision Detection (CSMA/CD) bekannt und wird beispielsweise im klassischen Ethernet eingesetzt. Dieses Verfahren kann bei Wireless-LANs jedoch nicht eingesetzt werden, da ein Sender am Sendeort stets alle anderen Signale anderer Sender überdeckt und somit nicht „mithören“ kann. In Wireless-LANs wird daher ein kollisionsvermeidendes Verfahren eingesetzt, das Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). Wenn sich auch nicht alle Kollisionen tatsächlich verhindern lassen, wird zumindest doch deren Auftrittswahrscheinlichkeit erheblich reduziert. Bei diesem Verfahren sendet der Sender vor der Übertragung der eigentlichen Nutzdaten an den gewünschten Empfänger eine Nachricht mit dem Übertragungswunsch. Der Empfänger antwortet im Normalfall mit einer Bestätigung dieser Anfrage. Alle Stationen, die die Anfrage des Senders oder die Antwort des Empfängers mithören, stellen eigene Sendewünsche zunächst zurück, so dass die gewünschte Übertragung störungsfrei ablaufen kann. Kommt es trotzdem zu Kollisionen garantiert ein einfaches Quittierungssystem, dass keine Nutzdaten verloren gehen. 2.3.2.1 IEEE 802.11 Der aktuell wichtigste Standard für Wireless-LANs ist die IEEE 802.11-Protokollfamilie, dessen wichtigsten Eigenschaften sind:

2.3 Grundlagen drahtloser Netze

■ ■ ■

33

802.11b

802.11a, 802.11h

34

■ ■ ■

■

Frequenzbereich. Alle Wireless-LANs der 802.11-Familie werden in den Frequenzbändern um 2,4 GHz (ISM-Band) oder um 5 GHz betrieben, die lizenzfrei genutzt werden dürfen, aber in der BRD trotzdem durch die RegTP kontrolliert werden.

■

Modulationsverfahren. Zum Einsatz kommen zwei Frequenzspreizverfahren (vgl. Erläuterungen zu CDMA-Verfahren weiter oben). So kann einerseits im Rahmen eines Frequency Hopping die Trägerfrequenz gewechselt werden, andererseits wird das Frequenzspektrum durch logische Verknüpfung der Daten mit einer hochfrequenten Bitfolge aufgespreizt. Dadurch werden schmalbandige Störungen wirkungslos.

■

Reichweiten. Die Reichweite von 802.11-Systemen beträgt bis zu 100 m. Der Einsatz von Richtantennen erlaubt Reichweiten von bis zu 2 km.

■

Datenraten. Der 802.11-Standard bietet (von Teilspezifikation zu Teilspezifikation) verschiedene Datenraten. So unterstützt der Standard 802.11b Bruttodatenraten von bis zu 11 MBit/s, der Standard 802.11h sogar bis zu 54 MBit/s.

Die 802.11-Protokollfamilie gliedert sich in Teilstandards (gekennzeichnet durch Kleinbuchstaben), die unterschiedliche Leistungscharakteristiken aufweisen. Der aktuell am weitesten verbreitete Standard (und deswegen auch billigste, was den Aufbau entsprechender Infrastrukturen anbelangt) ist der 802.11b-Standard. Dieser realisiert eine Bruttobandbreite von maximal 11 MBit/s und funkt im Frequenzband um 2,4 GHz. Da dieses Frequenzband auch von anderen Funktechnologien (beispielsweise Bluetooth) aber auch Mikrowellen benutzt wird, sind Funkverbindungen nach 802.11b verhältnismäßig starken Störungen unterworfen. 802.11b unterstützt eine maximale Reichweite von bis zu 50 Metern, vorausgesetzt, dass keine beschränkenden Faktoren wie Mauern, Gebäude oder Bäume stören. Mit 802.11a existiert ein weiterer Teilstandard, der vor allem in Firmennetzen eine relativ starke Verbreitung gefunden hat, allerdings inkompatibel zu 802.11b ist. 802.11a nutzt den Frequenzbereich um 5 GHz, was die Störanfälligkeit durch andere Funknetze stark vermindert, da nicht mehr das lizenzfreie ISM-Band genutzt wird. Durch das höhere Frequenzband kommt es allerdings zu einer größeren Anfälligkeit für Rauschen, Abschattungen und Dämpfungen. 802.11a erlaubt eine maximale Datenrate von 54 MBit/s und ist somit um den Faktor 5 schneller als 802.11b. Da der Frequenzbereich um 5 GHz allerdings in Europa auch anderweitig genutzt wird (beispielsweise von Militär oder in der Flugsicherung), unterliegt die Verwendung von 802.11a-Funknetzen starken Einschränkungen. So

2 Mobile Computing

muss Hardware bezüglich der Sendeleistung eingeschränkt werden (maximal 30 Milliwatt) und der Aufbau entsprechender Funknetze darf nur innerhalb von Gebäuden erfolgen. Außennetze nach diesem Standard sind nicht erlaubt. Die Reichweite von 802.11a-Netzen beträgt aufgrund der geringen Sendeleistung maximal 25 Meter. Eine Erweiterung des 802.11a-Standards schraubt die maximal erlaubte Sendeleistung auf 200 Milliwatt hoch, was weitergehende Einsatzmöglichkeiten dieses Funkstandards ermöglicht. Dieser leistungsstärkere Standard wird als 802.11h-Standard bezeichnet. Kern der Erweiterung ist die Fähigkeit, die Sendeleistung an das benötigte Niveau anzugleichen. Dieser Vorgang wird als Transmit Power Control (TPC) bezeichnet. Auch der 802.11h-Teilstandard ist zu 802.11b inkompatibel. Der letzte relevante Teilstandard ist der 802.11g-Standard. Dieser funkt wieder im Frequenzband um 2,4 GHz und ist kompatibel zum 802.11b-Standard (mit allen Vor- und Nachteilen). Durch die höhere maximale Bandbreite von 54 MBit/s stellen Geräte, die diesen Standard umsetzen, jedoch eine interessante Alternative zu 802.11b dar. Eine grosse Verbreitung hat dieser Standard allerdings noch nicht gefunden. 2.3.2.2 IEEE 802.16 (WiMAX) In der zweiten Jahreshälfte 2004 soll die erste Produktgeneration für den IEEE-Standard 802.16 verfügbar sein. Dieser neue Standard ist eine Art Super-WLAN mit extrem hohen Bandbreiten und einer größeren Reichweite als das herkömmliche 802.11-WLAN. Entwickelt wurde der Standard von einem Firmenkonsortium unter der Führung von Intel, Nokia und Airspan. Der Name des Firmenkonsortiums – WiMAX – gibt dem Super-WLAN auch seinen Namen. Gegenüber den 802.11-Standards wird der 802.16-Standard zum Aufbau größerer, drahtloser Weitverkehrsnetze eingesetzt. Funknetze dieser Größe werden auch als Wireless Metropolitan Area Networks (WMAN) bezeichnet. Der 802.16-Standard arbeitet im Frequenzbereich von 2,5 GHz bis 66 GHz und bietet bei maximalen Reichweiten von bis zu 50 km eine Datenübertragungsrate von maximal 134 MBit/s (bei vollständiger technologischer Auslastung). Bei dieser Bandbreite können pro Sekunde bis zu 70 Millionen Zeichen übertragen werden. Somit ist WiMAX 1300mal schneller als die derzeit übliche HandyTechnologie GPRS. Im Vergleich zur 802.11-WLANs benötigt WiMAX größere Basisstationen. Diese sind jedoch immer noch wesentlich kleiner als Basisstationen für Mobilfunknetze. Zudem sind sie auch wesentlich günstiger. Ähnlich wie bei der 802.11-Protokoll-

2.3 Grundlagen drahtloser Netze

802.11g

Entwicklung

Wireless Metropolitan Area Networks

■ ■ ■

35

802.16a

802.16e

familie besteht auch die 802.16-Protokollfamilie aus unterschiedlich leistungsfähigen Teilstandards. Die Spezifikation 802.16a beschreibt die Funktechnik für den Aufbau von leistungsstarken Wireless-LAN-Backbones. Gefunkt wird im Frequenzbereich zwischen 2 GHz und 11 GHz. Die maximale Datenrate von 802.16a beträgt bei einer Reichweite von 50 km maximal 70 MBit/s. In Zusammenarbeit mit Intel wird in Houston County im Bundesstaat Georgia (USA) gerade ein solcher WMANBackbone installiert. Dazu werden nur zwei Sendemasten benötigt, was zu Gesamtkosten von gerade einmal 2 Millionen Dollar führt. Über solche Wireless Metropolitan Area Networks können bis zu 60 Unternehmen bzw. mehrere hundert DSL-Breitbandanschlüsse angebunden werden. Für die bandbreitenstarke Anbindung von Privatnutzern ist dagegen ein weiterer Teilstandard, 802.16e genannt, vorgesehen. Marktreife Produkte zur Ausnutzung solcher Funknetze werden jedoch erst in zwei bis drei Jahren erwartet. 2.3.2.3 Wireless-LAN-Roaming Hauptproblem bei drahtlosen, lokalen Funknetzwerken ist die Abhängigkeit des Datendurchsatzes von der Reichweite. Die angegebenen Brutto-Übertragungsraten reduzieren sich in der Praxis auf wenige MBit. So bleiben unter guten Bedingungen von den 54 MBit/s des 802.11a- und des 802.11g-Standards gerade noch 17 MBit/s übrig. Die 11 MBit/s Maximalleistung von 802.11b-Geräten reduzieren sich auf 4 bis 5 MBit/s. Zusätzlich gilt: je weiter man sich von einem Access Point entfernt, desto geringer wird auch der Datendurchsatz. Ab einem bestimmten Punkt wird die Verbindung sehr langsam oder bricht sogar ganz ab. Auch in Wireless-LANs ist die Möglichkeit des Roamings von Bedeutung. Kern des Roaming ist ein Prozess, der immer dann abläuft, wenn ein mobiler Client mit einer aktiven Netzwerkanbindung einen Wechsel von einem Access Point zu einem anderen Access Point durchführt. Das Roaming muss dabei gegenüber den Nutzern völlig transparent sein, das heisst ein Nutzer darf weder den Wechsel zu einem anderen Access Point oder in ein anderes Netz bemerken, noch darf eine bestehende aktive Kommunikationsverbindung unterbrochen werden. Wie in den Mobilfunknetzen lässt sich auch in einem Wireless-LAN Roaming am ehesten mit einem HandoverProzess zwischen verschiedenen Funkzellen vergleichen. Erkennt ein (mobiler) Client, dass die Sendeleistung des aktuellen Access Points zu niedrig ist, um die Netzwerkverbindung aufrechtzuerhalten, sucht er selbständig nach einem neuen Access Point.

36

■ ■ ■

2 Mobile Computing

Dieser Suchvorgang kann entweder als ein einfaches Scannen (Passive Scanning) oder über das Senden spezieller Datenframes (Active Scanning), auf die ein Access Point reagiert, realisiert sein. Nachdem ein geeigneter Access Point gefunden wurde, registriert sich der mobile Client und wartet auf eine Bestätigung. Die Bestätigung erhält er erst, nachdem der neue Access Point den Wechsel des Clients dem Netz und insbesondere dem alten Access Point bekannt gegeben hat. Mit der erhaltenen Bestätigung ist der Wechsel des Access Points abgeschlossen.

2.3.3 Wireless Personal Area Networks Im Gegensatz zu Wireless-LANs, die hauptsächlich dazu dienen, Notebooks und sehr leistungsfähige mobile Clients miteinander zu vernetzen bzw. diese an bestehende Netzwerke anzubinden, dienen Wireless Personal Area Networks (WPAN) vor allem der Vernetzung kleinerer, leistungsschwächerer Geräte (dazu gehören mobile Clients, ebenso wie stationäre Geräte und Haushaltsgeräte). Solche kleineren Geräte entsprechen in ihrer Leistungsfähigkeit zwar nicht den Möglichkeiten traditioneller Computersysteme, stellen gleichzeitig aber auch keine so großen Anforderungen, was ihre Vernetzung anbelangt. Hier rücken andere technische Eigenschaften, beispielsweise die Fähigkeit des Aufbaus einfacher Ad-hoc-Netzwerke, in den Vordergrund. Für den Aufbau von Wireless Personal Area Networks (WPAN) gibt es aktuell zwei verbreitete Techniken: IrDA, das auf Infrarot aufbaut, und Bluetooth, das auf einer ähnlichen Funktechnik wie Wireless-LAN basiert und wesentlich leistungsfähiger als IrDA ist. IrDA besitzt vor allem den Nachteil, dass zwischen Sender und Empfänger eine Sichtverbindung bestehen muss. Wände, Gegenstände, Menschen und sogar direkte Sonneneinstrahlung zwischen Sender und Empfänger führen sofort zu einer Unterbrechung bestehender Verbindungen. Typische Einsatzgebiete von WPANs sind: ■

Vernetzung von PDAs zum Austausch kleinerer Datenmengen,

■

Vernetzung von Haushaltsgeräten,

■

Drahtlose Anbindung von Peripheriegeräten (Drucker, Handys, Digitalkameras, …) eines PCs,

■

Drahtlose Übermittlung von Fotos einer Digitalkamera an einen Drucker, der die Aufnahmen sofort ausdruckt,

■

Drahtlose Anbindung eines Headsets an ein Mobiltelefon,

2.3 Grundlagen drahtloser Netze

Anwendungsszenarien

■ ■ ■

37

■

Aufbau von (mobilen) Ad-Hoc-Netzen,

■

Überbrückung der physikalischen Lücke zwischen verschiedenen Netztechnologien. Will ein Nutzer beispielsweise mit seinem Notebook über die Datendienste seines Mobiltelefons online gehen, kann mit Hilfe von Bluetooth oder IrDA die physikalische Übertragungslücke zwischen Handy und Notebook überbrückt und so eine einfache Datenkommunikation ermöglichen. Die Datenkommunikation, also die Herstellung einer Internetverbindung für ein Notebook, kann beispielsweise unter Verwendung verfügbarer GSM-Netze erfolgen.

Wie die obigen Anwendungsszenarien zeigen, sind Geräte, mit denen ein WPAN aufgebaut werden kann, vor allem für den Massenmarkt gedacht. Die entsprechende Hardware muss deswegen in großen Mengen und zu günstigen Preisen hergestellt werden können. Da die vernetzten Geräte aufgrund ihrer Größe über keine nennenswerte Stromversorgung verfügen, müssen die Kommunikationsverfahren und die Sendeleistung der Geräte an diese Restriktion angepasst werden. Eine geringe Sendeleistung führt aber dazu, dass zu vernetzende Geräte eine nur relativ geringe räumliche Distanz zueinander aufweisen dürfen. Typische WPANs besitzen Durchmesser von einigen Zentimetern bis hin zu maximal 10 m. In einem Wireless-LAN kann jeder Knoten mit jedem anderen Knoten kommunizieren (Multipoint-to-Multipoint-Kommunikation). Dieses Szenario ist in einem WPAN nicht möglich. Innerhalb eines WPANs kann nur ein einzelnes Gerät als Sender (der Master) mit einem oder mehreren Empfängern (den Slaves) kommunizieren (Point-to-Multipoint-Kommunikation). In manchen Fällen (beispielsweise bei IrDA-Verbindungen) sind sogar nur Verbindungen zwischen zwei Kommunikationspartnern möglich (Point-to-PointKommunikation). Da WPANs für gewöhnlich aber sowieso nur wenige Geräte miteinander verbinden (was sich ja schon durch die Reichweitenbeschränkung ergibt), spielen diese Einschränkungen keine nennenswerte Rolle. 2.3.3.1 Bluetooth Bluetooth wurde von der Bluetooth Special Interest Group (SIG) entwickelt, die von dem Unternehmen Ericsson 1994 gegründet wurde. Ursprünglich war Bluetooth als Technik für die Verbindung beliebiger Endgeräte über relativ kurze Entfernungen (< 10m) gedacht. Mittlerweile wurde das Einsatzgebiet jedoch stark erweitert.

38

■ ■ ■

2 Mobile Computing

Für verschiedene Anwendungen definiert Bluetooth verschiedene Profile. Beispiele für Profile sind das Headset Profile oder das Cordless Telephony Profile. Jedes Profil kapselt Protokolle, die im jeweiligen Anwendungsszenario eine wichtige Rolle spielen. Bluetooth abstrahiert somit von weiten Teilen des ISO/OSIReferenzmodells und definiert (wie die 802.11-Wireless-LANs auch) eine eigene Bitübertragungsschicht. Auch Bluetooth funkt im Frequenzband um 2,4 GHz. Um die Störanfälligkeit bei Nutzung dieses Frequenzbandes zu reduzieren, realisiert Bluetooth ein Frequenzsprungverfahren in Kombination mit einem Zeitmultiplexverfahren. Insgesamt 1600mal pro Sekunde wird die Frequenz gewechselt – bei der 802.11-Protokollfamilie erfolgt ein Frequenzwechsel dagegen nur ca. 20mal pro Sekunde. Alle Endgeräte, die ein Pikonetz bilden, besitzen die gleiche Sprungfrequenz. Bluetooth unterscheidet weiterhin zwischen zwei verschiedenen Sendeklassen für Endgeräte. Während Klasse-1-Geräte mit maximal 2,5 Milliwatt senden, steigt die Sendeleistung bei Klasse-2-Geräten auf 100 Milliwatt an. Dies führt zu einem Reichweitenzuwachs auf bis zu 100 Metern! Ein Bluetooth-WPAN, das auch Pikonetz genannt wird, besteht aus einem Master (der Leitstation) und bis zu 7 Slaves (Folgestationen), zusammen also aus bis zu 8 aktiven Endgeräten. Zusätzlich können bis zu 200 passive Endgeräte, die sich nicht aktiv am Datenverkehr beteiligen, an ein WPAN angebunden sein. Jedes beliebige Endgerät kann als Leitstation agieren. Die Leitstation bestimmt die Frequenzsprungfolge. Neue Folgestationen müssen diese Sprungfolge adaptieren, wenn sie Teil des Netzes werden wollen. Man spricht auch davon, dass sie sich auf die Frequenzsprungfolge synchronisieren. Geräte können an mehreren Netzen gleichzeitig teilnehmen, jedoch nur an einem aktiv. Die Sprungfolgefrequenz wird aus eindeutigen Parametern, unter anderem aus einer eindeutigen, individuellen Gerätekennung gewonnen, so dass zwei verschiedene Netze niemals das gleiche Frequenzsprungverfahren implementieren (und sich dadurch gegenseitig stören). Mobile Clients, die eine BluetoothVerbindung initialisieren, übernehmen zunächst automatisch die Rolle der Leitstation. Bis zu 10 Netze lassen sich zu einem ScatterNetz zusammenfassen. Die Entwicklung des WLAN-Standards 802.11 und der Bluetooth-Technologie haben schnell Gemeinsamkeiten beider Technologien aufgezeigt. Beide Standards dienen der Vernetzung unterschiedlichsten Geräte und ersetzen bestehende Kabelverbindungen. Beide Standards besitzen unterschiedliche Stärken und Schwächen. Wireless-LAN übertrifft Bluetooth vor allem, was die Frage der Reichweite anbelangt und wird deswegen vor allem in der PC-

2.3 Grundlagen drahtloser Netze

Bluetooth-Profile

Pikonetze

■ ■ ■

39

Kommunikation eingesetzt. Bluetooth kann vor allem geringe Hardwarekosten, einen niedrigen Stromverbrauch und eine einfacher zu konfigurierende drahtlose Übertragung zwischen Kleinstgeräten vorweisen. 2.3.3.2 Infrarot (IrDA) Eine zweite weitverbreitete Technologie für den Aufbau von WPANs ist die drahtlose Infrarotkommunikation. Die drahtlose lichtwellenbasierte Kommunikation unterscheidet sich jedoch erheblich von drahtlosen Funktechniken. Erste Ansätze mit der Verwendung von Infrarotsignalen waren bereits 1979 zu sehen, als Hewlett Packard Taschenrechner mit Druckern vernetzte. 1993 schlossen sich schließlich mehr als 30 Firmen (unter anderem erneut Hewlett Packard) zur Infrared Data Association (IrDA) zusammen, um die Infrarotkommunikation zu standardisieren. Heute steht IrDA nicht mehr nur für diese Organisation, sondern auch für den von ihr erarbeiteten Standard zur Infrarotkommunikation. Wie Funksignale sind auch Infrarotsignale für das menschliche Auge unsichtbar, gehorchen allerdings trotzdem den Gesetzen der Strahlenoptik. Infrarotsignale können beispielsweise massive Gegenstände nicht durchdringen, was die Reichweite von Infrarotsendern sehr stark beschränkt. Zwischen Sender und Empfänger muss also eine Sichtverbindung bestehen. Ein Vorteil der eingeschränkten Reichweite ist allerdings, dass die Einflüsse von eventuellen Störquellen, eine nur geringe Rolle spielen. Störanfällig sind Infrarotsignale nur gegenüber Fremdlicht (Kunstlicht, Sonnenlicht), nicht jedoch gegenüber niederfrequenten elektromagnetischen Wellen. Da gerade Sonnenlicht eine häufige Störquelle darstellt, kann IrDA sehr häufig nicht im Freien eingesetzt werden. Im Gegensatz zu Funktechniken unterliegt die Verwendung von Infrarot aber keinerlei hoheitlichen Beschränkungen.

2.3.4 Alternative Funktechnologien Neben den beschriebenen Wireless-LANs (der 802.11- und 802.16Protokollfamilien) und den Wireless Personal Area Networks existieren noch einige weitere Funknetztechnologien: ■

40

■ ■ ■

HiperLAN. Unter HiperLAN (High Performance Radio LAN) versteht man einen europäischen ETSI-Standard (European Telecommunications Standard Institution) im 5-GHz-Band. Ver-

2 Mobile Computing

schiedene Teilstandards (auch Typen genannt) spezifizieren verschiedene Bandbreiten. So spezifiziert Typ 1 beispielsweise ein drahtloses Netz mit einer maximalen Bandbreite von 24 MBit/s. ■

HiperACCESS. HiperACCESS ist eine Variante der HiperLAN-Technik. Die maximale Bandbreite beträgt 20 MBit/s, gefunkt wird im 5-GHz-Frequenzband.

■

HiperLINK. HiperLINK ist eine weitere Variante der HiperLAN-Technik, die auf drahtlosen Punkt-zu-Punkt-Verbindungen basiert. Die maximale Bandbreite beträgt 155 MBit/s, gefunkt wird im 17-GHz-Frequenzband.

■

HomeRF. Home Radio Frequency ist eine kostengünstige IEEE-802.11-Alternative für Heimanwender. Mit dem Shared Wireless Access Protocol (SWAP) ist es vor allem auf die Übertragung natürlicher Sprache ausgelegt. Die den Standard betreuende HomeRF Working Group hat sich jedoch aufgrund geringer Nachfrage nach dieser Technik aufgelöst. GSM 900

UMTS

Abb. 2.6: Frequenzspektrum

802.11 a/h 802.11 b/g Bluetooth

0

1

2

3 4 Frequenzspektrum

5

6 GHz

Nach der Vorstellung der wichtigsten Grundlagen und Typen drahtloser Kommunikationsnetze stehen im weiteren Verlauf dieses Kapitels wieder die Eigenschaften mobiler Anwendungen im Mittelpunkt. Nach einer Beschreibung der wichtigsten Merkmale mobiler Anwendungen in Abschnitt 2.4 wird danach in Abschnitt 2.5 eine spezielle mobile Anwendung zur Erbringung einer ortsabhängigen Dienstleistung, ein Location Based Service, beschrieben.

2.4 Mobile Anwendungen Der Begriff mobile Anwendung ist sehr allgemein gehalten, da er von dem tatsächlichen Zweck der Anwendung vollständig abstrahiert. Er beschreibt lediglich die Eigenschaft eines computergestütz-

2.4 Mobile Anwendungen

■ ■ ■

41

ten Systems mit anderen Computersystemen drahtlos zu kommunizieren und kann wie folgt definiert werden: Definition 2.1: mobile Anwendung

Eine mobile Anwendung ist eine Anwendung, die drahtlos mit anderen Systemen kommuniziert, die selbst mit anderen Rechnersystemen vernetzt sein können. Dabei hat eine mobile Anwendung typischerweise gegenüber stationären Anwendungen weitere Eigenschaften wie Ortsunabhängigkeit und Lokalisierbarkeit, sowie zusätzliche Anforderungen an Sicherheit, Identifizierbarkeit, Verfügbarkeit, Datenverteilung und Lastverteilung. Einige Eigenschaften und Anforderungen werden in den folgenden Abschnitten vorgestellt.

2.4.1 Ortsunabhängigkeit Ortsunabhängigkeit bedeutet, dass ein Nutzer an beliebigen geographischen Standorten dazu in der Lage ist, mit einer Clientanwendung auf lokale oder entfernte Dienste transparent zuzugreifen, Daten ab zu rufen und zu bearbeiten. Dabei ist vor allem die Unterstützung des Disconnected Mode mobiler Clients wichtig. Erst indem die Funktionsfähigkeit der mobilen Datenbankanwendung von der Verfügbarkeit drahtloser Netze entkoppelt wird, kann tatsächliche Ortsunabhängigkeit erreicht werden.

2.4.2 Lokalisierbarkeit Vor allem die Betreiber von Telekommunikationsnetzen haben in den vergangenen Jahren verschiedene Verfahren entwickelt, um den Standort eines Nutzers mit einer erstaunlich hohen Genauigkeit zu ermitteln. Der Prozess der Lokalisierung identifiziert dabei nicht nur die Funkzelle, in der sich ein Nutzer aktuell aufhält, sondern vielmehr dessen Standort auf einige Meter genau. Dies wird z.B. durch die Untergliederung der Funkzellen in Sektoren und Berechnungen anhand der Signalempfangsintensität möglich. Der Grund durchgeführter Ortsbestimmungen lag ursprünglich weniger in dem Bestreben, ortsabhängige Dienste anzubieten (die als Location Based Services bekannt sind und im folgenden Abschnitt 2.5 ausführlich behandelt werden), als vielmehr in der Notwendigkeit, durch Ortsbestimmungen ein technisch korrektes Handover mobiler Nutzer zu ermöglichen. Andererseits ist es aus der Perspektive des Datenschut-

42

■ ■ ■

2 Mobile Computing

zes äußerst kritisch, Daten über die Position und den Aufenthaltsort mobiler Nutzer kommerziell zu nutzen.

2.4.3 Sicherheit und Identifizierbarkeit Die Übertragung und Speicherung sensibler Daten auf mobilen Clients erfordert adäquate Sicherheitsmechanismen. Zweifelsohne ist die Sicherheit eines der größten Probleme, das sowohl in technischer als auch in anwendungsbezogener Hinsicht dem endgültigen Durchbruch mobiler Anwendungen in sensiblen Bereichen noch im Wege steht. Drahtlose Kommunikation ermöglicht ein extrem einfaches Abfangen übertragener Daten, da in diesem Fall nicht einmal das Anzapfen eines Kabels notwendig ist. Die Daten können vielmehr direkt aus dem Äther abgehört, analysiert und manipuliert werden. Nur durch den Einsatz zusätzlicher Sicherheits- und Verschlüsselungstechnologien (wie Virtual Private Networks, IPSec, Secure Socket Layer, Wi-Fi Protected Access) kann verhindert werden, dass Daten abgehört und entschlüsselt werden. Bei der Konzeption eines adäquaten Sicherheitsmodells müssen vier verschiedene Teilbereiche berücksichtigt werden: ■

Gerätebene

■

Übertragungsebene

■

Netzebene

■

Anwendungsebene

Nur durch die Entwicklung eines Sicherheitskonzeptes, dass alle vier Ebenen berücksichtigt, sind sichere mobile Anwendungen, vor allem aber eine sichere Ende-zu-Ende-Kommunikation zwischen Client und Server möglich. Besonders relevante Punkte bei der Erstellung eines Sicherheitskonzeptes sind: ■

Vertraulichkeit. Übertragung nur zu gewünschten Kommunikationspartner. Nicht erwünschte Mithörer sollen keinen Zugriff auf übertragene Daten erlangen.

■

Zugriffskontrolle bzw. Rechteverwaltung. Implementierung einer umfassenden Rechteverwaltungskomponente, die z.B. auf Access Control Lists basiert. Bei der Zugriffskontrolle und bei Rechtesystemen spricht man von Autorisierung. Einer Autorisierung muss immer eine Authentifizierung (siehe unten) vorausgehen.

2.4 Mobile Anwendungen

Entwicklung eines Sicherheitskonzepts

■ ■ ■

43

■

Verschlüsselung. Dabei geht es nicht nur um Verschlüsselung bei der Datenübertragung (z.B. über Public-Key-Verfahren), sondern auch um eine verschlüsselte Speicherung auf ClientSeite, da mobile Clients aufgrund ihrer Größe und ihres monetären Wertes einem erheblich höheren Diebstahlrisiko als stationäre Serversysteme ausgesetzt sind.

■

Integrität. Es muss verhindert werden, dass Daten während ihrer Übertragung verändert oder gefälscht werden (Schutz vor Man-in-the-Middle-Attacken, also vor Veränderungen übertragener Daten durch unbekannte Dritte). Verfälschungen können das Löschen von vorhandenen oder das Hinzufügen von neuen Informationen, oder die direkte Manipulation von Inhalten sein.

■

Authentifizierung. Notwendig ist eine zuverlässige und funktionierende Identifikation von Kommunikationspartnern. Dies können sowohl Personen als auch Rechner sein. Authentifizierungen kann für jede Session oder für jede einzelne übertragene Nachricht gefordert werden.

■

Non-Repudiation. Dabei geht es um die Unabstreitbarkeit durchgeführter Transaktionen. Dies ist vor allem bei Bezahlsystemen von mobilen Clients aus wichtig, wie beispielsweise bei elektronischen Fahrkarten oder Tickets. Gilt der Grundsatz der Non-Repudiation, muss es Sendern und Empfängern von Daten möglich sein, einen eventuell sogar gerichtstauglichen Nachweis für die eigene Aktivität zu erbringen.

■

Geräteschutz. Neuere PDAs berücksichtigen diese Forderung bereits, indem Fingerabdruck-Scanner direkt in die Hardware integriert werden (so geschehen beim HP iPAQ H 5450).

■

Medium Access. Externer Zugriff auf bestehende Netzwerkinfrastrukturen. Beispielsweise darf nur Nutzern ein Zugriff auf ein Wireless-LAN gewährt werden, die sich zuvor registriert haben (oder entsprechende Gebühren entrichtet haben).

Bei mobilen Datenbanken muss neben einer durch das Betriebssystem implementierten Rechteverwaltung auch eine datenbankspezifische Zugriffsrechteverwaltung auf Relationen und Sichten implementiert sein. Identifikation

44

■ ■ ■

Die oben geforderte eindeutige Identifizierbarkeit mobiler Nutzer oder Clients wird in Mobilfunknetzen durch die so genannten Subscriber Identification Modules (SIM) erreicht, die alle notwendigen Daten zu einem Nutzer enthalten. Diese durch SIM-Karten erreichte

2 Mobile Computing

Identifizierbarkeit bezieht sich allerdings stets auf Nutzer, nicht auf Endgeräte, da SIM-Karten austauschbar sind. Häufig kann eine Identifikation von Nutzern auch verdeckt mit Cookies realisiert werden. Cookies sind kleine Textdateien, die Auskunft über die Identität und die bisherigen Aktivitäten eines Nutzers auf einer Webseite geben. Cookies lassen sich im Gegensatz zu anderen Techniken wie den SIM-Karten aber auch sehr leicht manipulieren und für andere Aufgaben einsetzen. Deswegen stellen sie keine wirklich sinnvolle Alternative für eine Identifizierung dar.

2.4.4 Verfügbarkeit und Effizienz Viele mobile Clients sind so konzipiert, dass sie nach dem Einschalten sofort einsatzbereit sind. Im Vergleich zu stationären Computern entfällt somit der lange Boot-Vorgang. Anwendungen müssen diese Fähigkeit mobiler Clients adaptieren, letztlich also ebenfalls nach dem Programmstart sofort verfügbar sein. Bei mobilen Datenbanksystemen wird gefordert, dass mit dem Start einer Anwendung auch ein sofortiger Zugriff auf die mobile Datenbank möglich sein muss. Lange Boot-Zeiten der mobilen Datenbank müssen also entfallen. Genauso wichtig sind bei bereits gebooteten Systemen kurze Antwortzeiten auf Anfragen. In leistungsstarken Datenbanksystemen sind zur Realisierung eines effizienten Datenzugriffs aufwendige Primär- und Sekundär-Indexstrukturen, effiziente relationale Algebraoperatoren und komplexe kostenbasierte Optimierer implementiert. Die Verwendung solcher Techniken ist jedoch nur bei der Verfügbarkeit entsprechend leistungsfähiger Hardware möglich. Mobile Anwendungen müssen dagegen oftmals eine leistungsschwächere Ausstattung vieler Clients berücksichtigen. Aufgrund der geringeren strukturellen Komplexität und des kleineren Volumens der auf mobilen Clients gewöhnlich gespeicherten Daten sind diesbezüglich aber gewisse Abstriche vertretbar. So kann beispielsweise auch auf sequentielle Suchverfahren ohne die Verwendung spezieller Indexstrukturen zurückgegriffen werden.

2.4.5 Datenverteilung und Lastverteilung Klassische Datenbankanwendungen speichern Datenbestände nicht immer zentral, sondern auch verteilt über mehrere Knoten bzw. Computersysteme (man spricht dann von verteilten Datenbanken). Auch für mobile Datenbanksysteme kann Verteilung eine interes-

2.4 Mobile Anwendungen

■ ■ ■

45

sante Implementierungsvariante sein, obwohl dann nicht die Verteilung von Daten innerhalb des Festnetzes, sondern die Verteilung von Daten zwischen Festnetz und mobilen Clients im Vordergrund steht. Ziel der Verteilung ist zweierlei: (a) die Erhöhung der Verfügbarkeit kritischer Daten und (b) eine bessere Lastverteilung. Von Lastverteilung wird dann gesprochen, wenn innerhalb eines Verbundes von Rechnern die Möglichkeit besteht, Daten (und damit die Datenzugriffe) auf verschiedene Hosts zu verteilen. Beide Ziele werden durch eine redundante Speicherung von Daten erreicht (Stichwort: Datenreplikation). Für mobile Clients spielt die Lastverteilung nur in der Richtung vom Client zum Server eine Rolle. Das heisst, wenn der Client zu schwach ist (CPU, temporärer Speicher für Zwischenergebnisse, etc.) muss es möglich sein, diese Last auf den Server abzuwälzen. Eine beliebig gewichtete Lastverteilung spielt aber eher eine untergeordnete Rolle. Das zweite Ziel, die Erhöhung der Verfügbarkeit der Daten, bildet dagegen den Hauptgrund für Replikation im mobilen Umfeld.

2.4.6 Überwachung von Integritätsbedingungen Daten sind das wichtigste Gut eines Unternehmens. Daher sind Integritätsbedingungen in Datenbanksystemen besonders wichtig. Sie reichen von einfachen Intra-Relationsbedingungen, wie Korrelationen und Abhängigkeiten von Attributkombinationen innerhalb einer Relation, über Inter-Relationsbedingungen, bis hin zu semantischen Integritätsbedingungen. Ihre Überwachung erweist sich bei mobilen Datenbanksystemen jedoch als wesentlich schwieriger, als bei herkömmlichen Datenbanksystemen. Einfache Integritätsbedingungen, die keine großen Anforderungen an die physischen Ressourcen (wie beispielsweise die benötigte Prozessorzeit) stellen, lassen sich oft ohne Schwierigkeiten durchsetzen. Komplexere Integritätsbedingungen dagegen verursachen aufgrund ihres Überwachungsaufwands erhebliche Schwierigkeiten. Diese Probleme lassen sich auch durch den Einsatz intelligenter Replikationsverfahren nicht immer beheben. Durch den inhärenten Speicherplatzmangel mobiler Clients wird diese Problematik verschärft.

2.5 Location Based Services Eins der wichtigsten Merkmale beim Mobile Computing ist der Umstand, dass sich Nutzer und mobile Clients räumlich bewegen. Es ist

46

■ ■ ■

2 Mobile Computing

deswegen nur eine logische Konsequenz, dass es für viele Anwendungen erforderlich ist, die aktuelle Position eines Nutzers zu kennen und diese Positionsdaten für die Erbringung der Nutzleistung einer Anwendung heranzuziehen. Solche Anwendungen werden als Location Based Services bezeichnet [Leh03, Rot03]. Einige Anwendungsfelder, die auf Positionsdaten bzw. deren Weiterverarbeitung basieren, sind: ■

Suche nach speziellen, möglichst nahe gelegenen Orten bzw. Einrichtungen (Hotels, Krankenhäuser, Restaurants),

■

Navigation zu bestimmten Standorten,

■

Lokalisation von Personen oder Objekten (beispielsweise einer befreundeten Person, oder eines gestohlenen oder verlorenen PDAs),

■

Abruf und Aufbereitung von Verkehrsinformationen,

■

Ortsabhängige Zustellung von Werbung (beispielsweise könnte ein Nutzer auf ein Sonderangebot aufmerksam gemacht werden, wenn er im Supermarkt am entsprechenden Regal vorbeigeht und diese Produkte in seinem Profil stehen),

■

Weitergabe eigener Positionsdaten im Falle eines Notfalls (Unfall, Brand, …) bzw. Benachrichtigung von Personen,

■

Dynamische WWW-Links, die abhängig von der eigenen Position die Zieladresse eines Links anpassen (beispielsweise auf die nächstgelegene Tankstelle).

Für ortsbezogene Dienste muss zunächst eine (möglichst genaue) Standortbestimmung durchgeführt werden. Bei den existierenden Verfahren zur Positionsbestimmung kann zwischen zwei verschiedenen Kategorien unterschieden werden: ■

Tracking. Die Position einer Person oder eines Objektes wird durch ein Netzwerk von Sensoren bestimmt. Dazu muss das zu ortende Objekt mit einer Marke (engl.: Tag) ausgezeichnet werden. Ermittelte Positionsdaten liegen zunächst immer nur dem Positionsermittlungssystem (und nicht dem mobilen Client) vor und müssen gegebenenfalls an eine Anwendung zur weiteren Verarbeitung übergeben werden.

■

Positioning. Ein Objekt ermittelt die eigene Position selbständig. Dazu wird auf ein System von Sendern oder Baken (engl.: Beacons) zurückgegriffen, die Funk-, Ultraschall oder andere Signale ausstrahlen. Diese Signale sind der Input komplexer Be-

2.5 Location Based Services

Anwendungsgebiete

Positionsbestimmung

■ ■ ■

47

rechnungsverfahren, anhand derer die eigene Position ermittelt werden kann. Bei den Positioning-Verfahren wird zwischen netzwerkbasierten und MT-basierten (MT = Mobile Telephone) Verfahren unterschieden. Erstere erlauben nur die zellengenaue Standortermittlung, während die letzteren dagegen eine wesentlich genauere Standortbestimmung erlauben. Ein Beispiel eines netzwerkbasierten Verfahrens ist das Cell ID Verfahren. Dabei wird die Cell Global Identity (CGI) einer Funkzelle, in der sich ein mobiler Client gerade aufhält, zur Standortangabe verwendet. Voraussetzung ist natürlich, dass eine Verbindung zur Basisstation besteht, der Client also in einer Zelle eingebucht ist. Im Normalfall ist jeder Zelle eine CGI zugeordnet. Ist eine Zelle in mehrere Zellsektoren aufgegliedert, ist jedem Sektor eine CGI zugewiesen. Bei diesem Verfahren handelt es sich um ein technisch sehr einfaches, allerdings auch relativ ungenaues Verfahren zur Standortbestimmung. Sind die Zellgrößen in städtischen Gebieten diesbezüglich gerade noch sinnvoll nutzbar, ist der Sinn des Einsatzes dieses Verfahren in ländlichen Gebieten mit Zellendurchmessern von bis zu 35 km zweifelhaft. Ein Beispiel eines MT-basierten Verfahrens der Standortbestimmung ist das Global Positioning System (GPS). Dabei handelt es sich um ein satellitengestütztes System zur Standortbestimmung, das von den USA aus primär militärischen Gründen installiert wurde. Aber auch zivilen Nutzern steht das System mit einer dann allerdings nur eingeschränkten Genauigkeit von 15 m zur Verfügung. Eine Standortbestimmung kann nur dann erfolgen, wenn ein Nutzer über einen Client verfügt, der in der Lage ist, GPS-Signale zu empfangen und zu interpretieren. Jedes GPS-Signal enthält einen Zeitstempel und die aktuelle Position des Satelliten, der das Signal gesendet hat. Insgesamt kreisen 24 Satelliten auf sechs verschiedenen Umlaufbahnen um die Erde. Anhand der Signale von mindestens vier Satelliten kann die Position des Clients und somit auch die Position des Nutzers errechnet werden. Allerdings müssen alle vier Satellitensignale gleichzeitig empfangen werden, was nur möglich ist, wenn sich vier Satelliten gleichzeitig am sichtbaren Horizont befinden. Ein weiteres MT-basiertes Verfahren ist das E-OTD-Verfahren (Enhanced Observed Time Difference). Dabei wird die Position eines Mobiltelefons durch Triangulation über drei Basisstationen ermittelt. Die Triangulation basiert auf vom Handy gemessenen Zeitdifferenzen, die zwischen dem Empfang spezieller Funksignale (Bursts genannt) der drei Basisstationen liegen.

48

■ ■ ■

2 Mobile Computing

Im Folgenden wird der Ablauf eines typischen Anwendungsszenarios detailliert beschrieben (vgl. Abbildung 2.7). Die zu erbringende ortsabhängige Dienstleistung besteht darin, für einen Nutzer alle Restaurants zu ermitteln, die sich in einem Umkreis von 100 m um dessen aktuellen Standort befinden. Der ortsabhängige Dienst wird durch ein WAP-Portal realisiert, das die gewünschten Informationen bereitstellt. Die genaue Abfolge der Schritte ist wie folgt:

Nutzung eines Location Based Service

1. Aufruf des WAP-Informationsportals über den WAP-Browser des mobilen Clients. Über das Informationsportal wird eine WML-Anfrage abgesetzt (alle Restaurants im Umkreis von 100 m). Diese WML-Anfrage wird zunächst der Basisstation übermittelt. 2. Die Basisstation leitet die WML-Anfrage an ein WAPGateway eines GSM-Netzbetreibers weiter. Ein WAPGateway hat die Aufgabe, das für die Kommunikation zwischen mobilem Client und Gateway benutzte WAP-Protokoll in das für die weitere Verarbeitung benötigte Transportprotokoll HTTP zu transformieren. 3. Vom WAP-Gateway wird die Anfrage über HTTP an den Webserver des Informationsportals weitergeleitet. Der Webserver empfängt die WML-Anfrage. 4. Anschließend fordert der Webserver vom Gateway Mobile Location Center (GMLC) den genauen Standort des mobilen Clients an. 5. Nach einer Zustimmung zum Standortbestimmungsvorgang durch den Nutzer erfolgt die Lokalisierung. 6. Das Gateway Mobile Location Center übermittelt die festgestellten Positionsdaten (mit welchem Verfahren die Positionsbestimmung erfolgt, spielt hierbei keine Rolle) anschließend dem Webserver, der daraufhin die eigentliche Dienstleistung initialisiert. 7. Unter Verwendung der Positionsdaten wird nun die gewünschte Information aus der Datenbank ermittelt. 8. Das Ergebnis selbst wird in einer dynamisch erzeugten WMLDatei verpackt, die anschließend unter Verwendung des HTTP-Protokolls an das WAP-Gateway zurückgeschickt wird. 9. Auf dem WAP-Gateway wird das HTTP-Protokoll in das WAP-Protokoll umgesetzt und die WML-Datei dann an die korrekte Basisstation übermittelt. Die korrekte Basisstation ist

2.5 Location Based Services

■ ■ ■

49

diejenige, bei der der mobile Client, der die Dienstleistung initialisiert hat, jetzt gerade eingebucht ist. 10. Abschließend übermittelt die Basisstation die WML-Datei zur Anzeige an den mobilen Client. Abb. 2.7: Architektur Person

1

10

WAPGateway

9 2

Basisstation 3 8 5 4

7 Datenbank

6 GMLC

Applikationsserver + Webserver

2.6 Klassifikation mobiler Endgeräte Die Hardwareentwicklung unterliegt einem enormen Wachstumstempo. Während die Entwicklungszyklen immer kürzer werden, kommt es gleichzeitig zu einem sehr starken Zuwachs der Leistungsfähigkeit neuer Gerätetypen. Dies macht eine Klassifikation mobiler Clients einzig auf technischen Eigenschaften und Merkmalen (wie Prozessortakt, Speichergröße oder Displaygröße) wenig sinnvoll, da die Zeitabstände zwischen den Markteinführungen neuer Technologien viel zu kurz sind. Daher stellen wir im Folgenden eine Klassifikation mobiler Clients vor, die sich nach grundlegenden Eigenschaften, wie sie durch die Ausstattung und das Einsatzgebiet bestimmt sind, richtet.

50

■ ■ ■

2 Mobile Computing

2.6.1 Notebooks Notebooks sind die mobile Variante stationärer Computersysteme. Sie sind bezüglich ihrer Leistungsfähigkeit mit stationären Rechnersystemen vergleichbar. In diese Geräteklasse fallen neuerdings auch Gerätetypen, wie die Tablet-PCs oder Subnotebooks. Durch neue Entwicklungen auf dem Gebiet der Prozessortechnik können Notebooks ihre stationären oft nur ein halbes Jahr älteren Pendants leistungsmäßig sogar in vielen Fällen übertreffen.

2.6.2 PDAs, Smartphones und Handys Personal Digital Assistants (PDAs) sind mobile Clients, die von ihrer Größe her darauf ausgelegt sind, mit einer Hand gehalten und mit der anderen bedient zu werden. Gegenüber den Notebooks weisen sie eine deutlich geringere Leistungsfähigkeit auf (auch wenn gerade in diesem Bereich aktuell besonders spektakuläre Leistungssteigerungen zu beobachten sind). PDAs sind mobile Universalgeräte, die vom jeweiligen Hersteller nicht für den Einsatz in einer spezifischen Anwendungsdomäne vorgesehen sind. Auf solchen Geräten können auf einem eigenen Betriebssystem (Palm-OS, Linux, Pocket PC, Windows Mobile 2003) über eine einfach zu bedienende (Lade-) Schnittstelle beliebige Applikationen installiert und ausgeführt werden. Allein für die Palm-Plattform existieren derzeit (Januar 2004) mehr als 20.000 (kostenlose und kostenpflichtige) Zusatzprogramme, die nahezu alle Anwendungsgebiete abdecken. Bei PDAs wird zwischen tastaturbasierten und stiftbasierten Geräten unterschieden. Während tastaturbasierte Geräte eine kleine Tastatur integriert haben, ist dies bei den stiftbasierten Geräten nicht der Fall. Die Eingabe erfolgt bei diesem Gerätetyp unter Verwendung eines Stifts, eines berührungsempfindlichen Displays (Touchscreen) und des Einsatzes einer speziellen Software zur Handschriftenerkennung. Wahlweise kann in diesem Fall auch die Eingabe über eine virtuelle Tastatur erfolgen. Tastatur- wie stiftbasierte PDAs weisen die folgenden charakteristischen technischen Merkmale auf: ■

Prozessor und Speicherkapazität. Im Vergleich zu Notebooks verfügen PDAs zwar über eine wesentlich geringere Leistungsfähigkeit, was Prozessortakt und Speicherkapazität betrifft. Aktuelle XScale-Prozessoren von Intel erreichen jedoch bereits ei-

2.6 Klassifikation mobiler Endgeräte

■ ■ ■

51

nen Prozessortakt von 600 MHz. Dies gestattet bereits aufwendigere Multimedia-Anwendungen und Multitasking.

Tab. 2.1: Ausstattung aktueller mobiler Endgeräte

■

Speichertyp. PDAs verfügen über keinen herkömmlichen Sekundärspeicher (beispielsweise eine Festplatte), um Anwendungen und Daten persistent zu speichern. Stattdessen wird auf externe Speicherkarten, sowie einen internen, batteriegepufferten Speicher oder Flash-Speichermodule zurückgegriffen.

■

Display. Displays sind im Vergleich zu Notebooks wesentlich kleiner, weisen jedoch bereits zunehmend vergleichbare Auflösungen und Farbtiefen auf. Aktuelle Geräte kommen bereits auf bis VGA-Auflösung und 32 Bit Farbtiefe.

Merkmal Betriebssystem Display

Prozessor

RAM Speicher Bedienung Netzwerk

52

■ ■ ■

Tungsten T3 (PDA) Palm-OS 5.2.1 320x460 (16 Bit Farbtiefe)

Acer Pocket PC n30 (PDA) Pocket PC 2002 240x320 (16 Bit Farbtiefe)

Intel XScale ARM-Prozessor (400 MHz) 64 Mbyte (davon 12 MB ROM) -

SamsungS3C2420-CPU (266 MHz) 64 MByte

Stift Bluetooth

32 MByte Flash-ROM Stift, Radwippe Bluetooth

Samsung X10 (Notebook) Windows XP Home 1024x768 14,1“ TFT-LCD (XGA) Intel Pentium M / 1,3Ghz (SpeedStep 600 MHz) 256MByte PC21002033 40 GByte Tastatur LAN,WLAN

■

Erweiterung. PDAs können, ähnlich wie Notebooks, mit Hilfe von Einsteckkarten in ihrer Funktionalität erweitert werden. So können über entsprechende Erweiterungskarten zusätzlicher Speicher, Digitalkameras, Netzwerkkarten oder Wireless-LANKomponenten in einen PDA integriert werden. Als problematisch erweisen sich jedoch die vielen verschiedenen Standards für Einsteckkarten (Compact Flash, Smart Media, Multimedia Card, Memory Stick, Secure Digital), die untereinander inkompatibel sind. Aktuelle Trends zeigen keine Erweiterungstechnologie, die sich durchzusetzen scheint. Jeder Hersteller propagiert seine Eigenentwicklungen.

■

Verfügbarkeit. PDAs werden wesentlich kürzer genutzt als Notebooks, die meistens über einen längeren Zeitraum (teils mehrere Stunden) eingeschaltet und ebenso lange genutzt werden. PDAs dagegen sind zumeist nur einige wenige Sekunden, höchstens einige Minuten eingeschaltet, um Informationen ab-

2 Mobile Computing

zurufen und Daten zu bearbeiten. Sie dürfen deshalb keine langen Bootzeiten haben, sondern müssen zusammen mit ihren Anwendungen verzögerungsfrei einsatzbereit sein. Den universell einsetzbaren PDAs stehen die für spezifische Einsatzbereiche konzipierten Clients gegenüber, die die gleiche Leistungsfähigkeit aufweisen, aber in Bezug auf das Betriebssystem und die Möglichkeiten zur Installation von Zusatzprogrammen wesentlich unflexibler sind. So ist es in vielen Fällen bei Spezialclients unmöglich, auf das Betriebssystem oder die Programmierung Einfluss zu nehmen. Charakteristisches Merkmal dieser PDA-Variante ist die hochgradige Optimierung einzelner Hardwarekomponenten, um den PDA an den Einsatz im jeweiligen Anwendungsbereich anzupassen. Die Bezeichnung PDA wird bei diesen Spezialgeräten zumeist nicht mehr verwendet. Der Name des Gerätes orientiert sich stattdessen oft an der Funktion des Spezialgerätes. Im Folgenden sind einige ausgesuchte Anwendungsgebiete aufgeführt und in ihrer Funktionalität kurz beschrieben: ■

Scanning. Diese Spezialgeräte sind miniaturisierte Scanner, die während eines Scan-Vorgangs entweder Strichcodes (Barcodes) oder aber ganze, gedruckte Texte einlesen und sofort elektronisch weiterverarbeiten können (in dem sie den eingescannten Text beispielsweise direkt in ein bestimmtes Dateiformat umwandeln).

■

Industrielle Fertigung. Diese Spezialgeräte werden in Fabriken im Rahmen einer mobilen Datenverarbeitung, beispielsweise in der Lagerverwaltung, eingesetzt.

■

GPS-Navigation. Diese Spezialgeräte sind mit GPSKomponenten (Empfänger, Navigationssoftware) ausgerüstet und werden als Navigationssystem eingesetzt. Aktuell ist jedoch der Trend zu erkennen, diese Funktionalität bereits in universelle PDAs zu integrieren.

In die gleiche Geräteklasse fallen auch Mobiltelefone und Smartphones, deren Verkaufszahlen massiv ansteigen. Smartphones können als Kombination von PDAs und Mobiltelefonen verstanden werden. Einige Smartphones sind als Erweiterung von Mobiltelefonen um die von PDAs her bekannten Organizerfunktionen konzipiert, während andere Smartphones eher klassischen PDAs ähneln, die um zusätzliche Fähigkeiten zur Mobilkommunikation ergänzt wurden.

2.6 Klassifikation mobiler Endgeräte

Handys, Smartphones

■ ■ ■

53

In ihrer Leistungsfähigkeit unterliegen Handys und Smartphones den gleichen Restriktionen, denen schon klassische PDAs unterworfen sind. Teilweise sind sie diesen sogar noch unterlegen, insbesondere was die Displaygröße und den Prozessortakt anbelangt.

2.6.3 Wearables Die Geräteklasse der Wearables beinhaltet mobile Clients, die im Gegensatz zu PDAs nicht mehr in der Hand gehalten und bedient werden, sondern vielmehr direkt am Körper (Armbanduhr, Kette, Schmuckstücke) getragen oder sogar in die Kleidung integriert werden. Der größte Vorteil von Wearables ist die Flexibilität, die Nutzer dadurch erreichen, dass sie die Hände für andere Tätigkeiten frei haben und somit in ihren Aktionen völlig unabhängig von dem mobilen Computersystemen bleiben. Wearables befinden sich noch größtenteils im Forschungsstadium. Trotz der prototypischen Entwicklung einiger Clients hat es noch kaum ein Gerät in die Serienfertigung für den Massenmarkt geschafft. Die Leistungsfähigkeit von Wearable-Rechnersystemen kann der von Notebooks entsprechen. Als sinnvolles Einsatzgebiet für Wearables zeichnet sich aktuell vor allem der Bereich der medizinischen Überwachung ab. Durch die Verfügbarkeit neuartiger Sensoren, die mit direkt am Körper getragenen Komponenten interagieren, kann eine direkte Überwachung kritischer Patientendaten realisiert werden.

2.6.4 Smartcards Eine im Zuge steigender Miniaturisierung ebenfalls immer wichtiger werdende Variante mobiler Clients sind die Smartcards. Diese sind nicht autonom nutzbare Clients, da ihr Einsatz ein Lese/Schreibterminal voraussetzt. Sie verfügen über keine eigene Stromversorgung. Über ein integriertes Rechnersystem mit funktionsfähigem Prozessor und Speicher erlauben Smartcards die Verarbeitung von Daten und die Ausführung von Anwendungen. Darüber hinaus können sie mit geeigneten Hilfsmitteln programmiert werden, wodurch eine gute Anpassung an verschiedene Aufgabenbereiche und Anwendungen möglich wird. Datenbanksysteme auf Smartcards werden Pico-Datenbanksysteme genannt. Sie sind in ihrer Implementierung speziell an die technischen Charakteristika von Smartcards (wenig Speicher, äußert geringer Prozessortakt) angepasst. Kapitel 8 dieses Buches geht aus-

54

■ ■ ■

2 Mobile Computing

führlich auf Eigenschaften und Implementierungskonzepte dieses speziellen Typs von Datenbanksystemen ein.

2.7 Zusammenfassung In diesem Kapitel wurde ein Streifzug durch das umfassende Themengebiet des Mobile Computings unternommen. Zunächst wurden dabei die Begriffe Mobilität, Mobile Computing, Nomadic Computing und Ubiquitous Computing definiert. Verschiedene Typen von Mobilität (Endgeräte-Mobilität, Nutzer-Mobilität und DienstMobilität) wurden dann beschrieben und Mobilität zum Begriff Drahtlosigkeit abgegrenzt. Nach dieser noch allgemein gehaltenen Begriffsklärung wurden im sich anschließenden Abschnitt die wichtigsten technischen Grundlagen drahtloser Kommunikationsnetze erläutert. Techniken des Mobilfunks, Wireless-LANs und Wireless Personal Area Networks wurden genauer beschrieben. Nach diesen sehr technischen Erläuterungen standen im darauf folgenden Abschnitt wichtige Merkmale mobiler Anwendungen und konkrete Anforderungen an mobile Datenbanksysteme im Vordergrund. Von Interesse waren hier der Umgang mit Ortsunabhängigkeit, die Frage nach der Sicherheit und Identifizierbarkeit in mobilen Umgebungen sowie weitergehende Eigenschaften, wie Verteilung, Effizienz, Verfügbarkeit oder die Überwachung von Integritätsbedingungen. Um die Positionsbestimmung bei ortsabhängigen Anwendungen und den Ablauf bei der Erbringung eines Location Based Service ging es danach. Der letzte Abschnitt versuchte eine Klassifikation existierender mobiler Clients und deren Einordnung in Anwendungsszenarien mobiler Umgebungen. Mit Beginn des nächsten Kapitels rücken die mobilen Datenbank- und Informationssysteme in den Vordergrund.

2.7 Zusammenfassung

■ ■ ■

55

3 Architekturen mobiler Informationssysteme

In diesem Kapitel werden Architekturen mobiler Informationssysteme vorgestellt. Im Vordergrund steht dabei das Zusammenspiel der mobilen Datenbanksysteme auf den Clients mit den ServerDatenbanken im Backend, also globale Szenarien mobiler Datenverarbeitung. Auf Architekturdetails wie Replikation, Synchronisation oder mobile Transaktionsmodelle wird dann in den nachfolgenden Kapiteln detailliert eingegangen. Abschnitt 3.1 beschreibt die am häufigsten eingesetzte Standardarchitektur mobiler Datenverarbeitung, die Client/ServerArchitektur. Abschnitt 3.2. geht auf Architekturen mobiler Informationssysteme ein, die auf verteilten Datenbanksystemen basieren. Danach untersucht Abschnitt 3.3 die Möglichkeiten, die sich aus der Einführung von Middleware-Komponenten ergeben. Abschnitt 3.4 beschreibt abschließend ein Szenario mobiler Datenverarbeitung mit mobiler Agenten.

Motivation

3.1 Client/Server-Architekturen Wir betrachten zur Einführung und als Motivation für die nachfolgende Diskussion möglicher Client/Server-Architekturen zunächst die dynamische Prozessstruktur in Datenbanksystemen vom Booten bis zum verteilten Aufruf mehrerer Datenbanken von einer Anwendung aus. Dieses Prozessmodell ist als Abstraktion idealtypisch anzusehen. Es gilt aber für die meisten kommerziellen Datenbanksysteme mit kleinen Abweichungen analog.

3.1 Client/Server-Architekturen

Dynamische Prozessstruktur

■ ■ ■

57

3.1.1 Prozessmodell von Datenbanksystemen Die Prozessstruktur ist im Wesentlichen unabhängig davon, ob es sich um ein relationales oder ein objektorientiertes Datenbanksystem handelt. Beim Installieren eines Datenbanksystems (DBS) wird vom Systemadministrator der DBS-Kernel-Demon (oder auch DBSServer oder DB-Multiplexer) und ein DB-Administrations-Demon gestartet. Beide müssen immer laufen, ohne sie kann mit keiner Datenbank gearbeitet werden. Der DB-Administrations-Demon (DBAdmin) behandelt alle Befehle zum Erzeugen, Booten, Herunterfahren und Löschen von Datenbanken, während der DBS-Server die Zugriffswünsche auf die Datenbank bearbeitet. Datenbank ist hier als Anwendungsdatenbank, das heisst als belegter Plattenplatz für die Inhaltsdaten zu verstehen, im Gegensatz zum Datenbanksystem (DBS), das das Datenbankmanagementsystem (DBMS), also den Zugriff auf eine konkrete Datenbank bezeichnet. Abb. 3.1: Grundzustand nach der Installation eines Datenbanksystems

DB-Admin

DBS-Server

DB1

Shared Memory Architektur

58

■ ■ ■

DB2

Will eine Anwendung mit einer Datenbank arbeiten, so muss diese zunächst gebootet werden. Das Booten einer Datenbank bedeutet nichts anderes, als für die Datenbank den DB-Cache im virtuellen Hauptspeicher zu reservieren und zu initialisieren. Das Herunterfahren einer Datenbank bedeutet, diesen wieder zu löschen. Im Fall einer Shared Memory Architektur ist dies gleichbedeutend damit, einen Shared Memory Bereich (SHM) für die zu erzeugende oder zu bootende Datenbank anzulegen. Für jede Datenbank gibt es im gebooteten Zustand genau einen Shared Memory Bereich. Über diesen können später mehrere Datenbank-Kernels und damit mehrere Ap-

3 Architekturen mobiler Informationssysteme

plikationen auf die Datenbank zugreifen bzw. gemeinsame Daten, wie z.B. die Lock-Tabelle, austauschen. Da jede gebootete Datenbank sich einen SHM im virtuellen Hauptspeicher reserviert, können nicht beliebig viele Datenbanken gleichzeitig auf einer Maschine laufen (= gebootet sein). Der Zustand “gebootet” ist unabhängig davon, ob eine Applikation gerade mit dieser arbeitet oder nicht. Abb. 3.2: Booten einer Datenbank

Aufruf: boot DB1

DB-Admin

DBS-Server

erzeuge

SHM

DB1

DB2

Wird nun eine Applikation gestartet, die mit der Datenbank arbeiten will, so ruft die Applikation zunächst den DBS-Server auf. Dieser erkennt, dass die gewünschte Datenbank gebootet ist und forkt sich, erzeugt einen Sohnprozess, den eigentlichen Datenbank-Kernel, um selbst sofort wieder frei für weitere Initialisierungsaufrufe zu sein. Datenbank-Kernel Prozesse sind typischerweise code sharing (= reentrant coding) programmiert, das heisst ihr Objektcode wird nicht für jede weitere Initialisierung kopiert, sondern liegt pro Maschine nur einmal vor. Je Datenbank-Kernel-Prozess wird nur ein eigener Prozessadressraum verwaltet, das heisst eigene Halden und Kellersegmente. Zusätzlich reserviert sich jeder Datenbank-Kernel einen lokalen Cache (LC) im Hauptspeicher. Zwischen Applikation und Kernel liegt immer eine Prozessgrenze. Meist ist die Applikation als Client und der Kernel als Serverprozess realisiert. Daher kann die API im einfachsten Fall ein Stub mit RPC-Aufrufen sein oder eine Socket-Kommunikation, aber auch eine JDBC oder ODBCSchnittstelle. Die API wird jeweils durch eine im Client eingebundene DB-Kernel-Bibliothek realisiert. Sie kapselt die Kommunikation mit dem Kernel vor dem Anwendungsprogrammierer.

3.1 Client/Server-Architekturen

Datenbankzugriff

■ ■ ■

59

Multi-Tasking

Benutzeranbindung

Will nun eine zweite Applikation ebenfalls mit der Datenbank arbeiten, so ruft auch sie zuerst den DBS-Server auf. Dieser stellt fest, dass es für die Datenbank bereits einen SHM Bereich gibt, forkt sich und stellt auch der zweiten Applikation einen eigenen DatenbankKernel zur Verfügung. Damit ist Parallelarbeit innerhalb der Kernels möglich (z.B. bei der SQL-Übersetzung). Die Synchronisation beim Datenzugriff erfolgt dann über das SHM. Komplizierter kann die Prozessarchitektur bezüglich ihrer Verteilung auf verschiedene Rechner durch Einsatz von gegenseitig mittels eines Network File Systems (NFS) gemounteten Platten werden. Dann kann auch an allen Prozessgrenzen eine zusätzliche Rechnergrenze liegen. Dies führt zu einer ganzen Reihe an Client/Server-Ketten. Obwohl das Shared Memory auf demselben Rechner wie die Datenbank liegen muss, kann die Platte, auf der die Datenbank liegt, gemounted werden und damit physisch auf einem weiteren Host liegen (wovon aber im Allgemeinen abzuraten ist). Betrachten wir zur Vervollständigung noch die Benutzeranbindung etwas genauer. Der Benutzer muss nicht am selben Rechner sitzen, an dem die Applikation läuft. Er kann dort z.B. via Remote Login arbeiten. Weiterhin kann er z.B. in einer UNIX Umgebung mit einem X-Fenstersystem die Ausgabe auf einen weiteren Rechner umleiten. Es handelt sich hierbei bereits um eine komplexe Client/ Server-Kette.

3.1.2 Klassische Client/Server-Architekturen Architekturmodell

Unter einen Client/Server-Modell versteht man eine Aufteilung der Verarbeitung auf zwei oder mehrere Prozesse, wobei der Client Dienste vom Server anfordert, die dieser bereitstellt. Nach Ausführung der Operation wird das Ergebnis auf den Client zurück übertragen. Meist wird der Ablauf des Client während der Operation unterbrochen, jedoch ist auch eine nicht-blockierende Interaktion zwischen Client und Server möglich. Es gelten folgende Definitionen: ■

60

■ ■ ■

Client. Ein Client ist eine Anwendung, die auf einer ClientMaschine läuft und im Allgemeinen eine Anforderung initiiert, wobei sie den geforderten Dienst vom angeforderten Service erhält. Clients sind a-priori nicht bekannt. Sie sind Prozesse und werden als solche dynamisch erzeugt und gelöscht. Bedingt durch die unterschiedliche Leistungsfähigkeit verschiedener Clients existieren zwei verschiedene Ansätze zur Charakterisierung der Aufgaben und Rollen eines Clients. Der erste Ansatz

3 Architekturen mobiler Informationssysteme

geht von relativ leistungsschwachen Client-Maschine (Thin Client) aus, die lediglich die Rolle eines einfachen Ein- und Ausgabeterminals übernehmen. Dagegen sieht der zweite Ansatz die Clients als relativ leistungsstarke Client-Maschinen (Thick Clients), die in der Lage sind, komplexere Berechnungen und Operationen (eventuell auf lokal gehaltenen Daten) weitgehend selbständig auszuführen. In mobilen Umgebungen können in Online-Szenarien (vgl. Abschnitt 1.2) Thin Clients leichter eingesetzt werden als in Offline-Szenarien. Mobile Datenbanken im engeren Sinn verlangen also eher Thick Clients. ■

Service. Ein Service ist eine Softwareeinheit, die bestimmte Dienste erbringt und auf einer oder mehreren Maschinen läuft.

■

Server. Ein Server ist ein Subsystem, das auf einer Servermaschine läuft und einen bestimmten Service für a-priori unbekannte Clients bereitstellt; es ist die Ausführung der ServiceSoftware auf einer einzelnen Maschine. Ein Server bietet somit eine Menge an Operationen (Prozeduren, Dienste) an. Ein Service kann auch durch mehrere Server erbracht werden. Client

Server Request

Abb. 3.3: Grundschema der Kooperation

Ausführung Reply

Das Interaktionsszenario zwischen Server und Client gehorcht dem Request-Replay-Protokoll (Grundschema jeder Client/ServerKooperation) und gliedert sich somit in drei Phasen (dabei wird davon ausgegangen, dass Transaktionen immer clientseitig initiiert werden): ■

Initiierung (Request). Auf einem Client wird eine Transaktion durch eine Anwendung initiiert. Mit einer deskriptiven Datenbanksprache (beispielsweise SQL) wird eine Anfrage formuliert, die anschließend dem Datenbankserver übergeben wird.

■

Ausführung (Execution). Auf dem Datenbankserver wird die übermittelte Anfrage zuerst analysiert (Parser), danach optimiert (algebraische und kostenbasierte Optimierung) und schließlich auf den Daten des Datenbankservers ausgeführt.

3.1 Client/Server-Architekturen

Request-ReplyProtokoll

■ ■ ■

61

■

Server

Ergebnisübermittlung (Reply). Das Ergebnis der Anfrage wird dem Client übermittelt. Dieser kann die erhaltenen Ergebnisse anzeigen oder weiterverarbeiten.

Server sind dedizierte Prozesse (Dämonen), die kontinuierlich ablaufen, das heisst sie durchlaufen folgende Endlosschleife: while warte führe sende

ImportSchnittstelle des Clients

ExportSchnittstelle des Servers

true do { auf Anforderung von einem Client C; Anforderung aus (oder delegiere); Antwort an Client C}

Meist sind Clientmaschine und Servermaschine getrennt. Sie können aber auch auf demselben Rechner liegen (Interprozesskommunikation). Die Schnittstelle auf der Clientseite (Import-Schnittstelle) hat dabei folgende Aufgaben: ■

Repräsentation des Servers innerhalb des Clients;

■

Vorbereitung der Parameter und Senden der Nachricht an das Server-Subsystem;

■

Vorbereitung des empfangenen Ergebnisses des Servers für die Interpretation durch den Client.

Auf der Serverseite hat die Schnittstelle (Export-Schnittstelle) folgende Aufgaben: ■

Repräsentant aller Clients innerhalb des Servers;

■

Empfang von Anforderungen;

■

Vorbereitung der Parameter und Aufruf der entsprechenden Operationen;

■

Vorbereitung der Ergebnisse und Senden der Antwort an den entsprechenden Client.

Wenn ein Server einen Dienst nicht selbst erbringen kann, kann er selbst wiederum einen weiteren Server damit beauftragen. Er übernimmt dann für diesen die Client-Rolle. Insgesamt entstehen dann Client/Server-Ketten.

62

■ ■ ■

3 Architekturen mobiler Informationssysteme

Auftrag Client

Antwort

Auftrag Server / Client

Auftrag

Server

Die Interprozesskommunikation (IPC) zwischen Client und Server kann einerseits asynchron oder synchron erfolgen, andererseits botschaftenorientiert oder auftragsorientiert. Synchrone Kommunikation bedeutet für den Sender (= Client) ein Warten bis der Empfänger (= Server) zum Empfang der Nachricht bereit ist, bzw. die Antwort darauf wieder eingetroffen ist. Asynchrone Kommunikation erfordert dagegen ein pufferndes (= speicherndes) Transportmedium, da der Sender sofort weiterarbeitet. Auftragsorientierte Kommunikation erwartet auf jeden Auftrag eine Antwort (= Ergebnis), während botschaftenorientiertes Arbeiten nur das Austauschen von Nachrichten bedeutet. Damit ergibt sich für die obigen vier Verfahren folgendes Verhalten (meist wird der RPC verwendet): ■

No-Wait-Send. Senden einer Nachricht ohne zu warten bis sie ankommt und ohne Erwartung einer Rückantwort. Speicherndes Transportmedium nötig.

■

Rendezvous. Synchronisation von Sender und Empfänger für eine Nachricht (ohne Rückantwort).

■

RSI. Asynchrones Senden und Empfangen von Auftrag und Antwort, wobei der Auftraggeber (= Client) zwischenzeitlich nicht wartet, er wird also wieder unterbrochen.

■

RPC. Entfernter Prozeduraufruf. Senden und Empfangen von Auftrag und Antwort, wobei der Client auf die Antwort wartet. Kein speicherndes Transportmedium nötig.

Für die Abarbeitung von Client-Anforderungen durch den Server gibt es zwei Möglichkeiten: Der Server kann entweder die Aufträge alle der Reihe nach selbst ausführen oder bei einem Aufruf sich selbst forken, den Aufruf an den Sohnprozess übergeben, um selbst sofort wieder frei für weitere Aufrufe zu sein. Die EinServerprozess-Technik erlaubt keine parallele Abarbeitung von Anforderungen. Sie ist deshalb zeitaufwendig. Der Server kann durch aufwendige Anforderungen lahmgelegt werden. Diese können auch nicht für höherpriorisierte Anforderungen unterbrochen werden. Im anderen Fall erhalten wir je aktiven Client genau einen geforkten Server-Prozess. Diese beenden sich nach ihrer Abarbeitung wieder. Diese Technik erlaubt eine parallele Abarbeitung der Anfragen, der ursprüngliche Server wird zum Verteilerprozess und ist dadurch

3.1 Client/Server-Architekturen

Abb. 3.4: Kette an Client/ServerKomponenten Interprozesskommunikation

Ausführung von Client-Anfragen

■ ■ ■

63

meist frei, die Warteschlange ist also deutlich kürzer als oben. Einziger Nachteil ist die laufende Prozesserzeugung durch die Forks. Sie kann aufwendig sein. Es bieten sich zwei Lösungen an: ■

Dispatcher. Vorweginitialisierung einer festen Anzahl an Sohnprozessen, die wartend gesetzt werden und sich nach der Auftragsbearbeitung nicht beenden, sondern sich frei melden. Man spricht dann beim Verteilerprozess von einem Dispatcher.

■

Verwendung von Threads. Threads sind leichtgewichtige Prozesse, ohne eigenen Prozessadressraum. Sie enthalten nur einen eigenen Prozesskeller. Das ermöglicht einen schnellen Prozesswechsel, da der Prozesskontext im gemeinsamen Prozessadressraum hinterlegt werden kann.

In DB-Client/Server-Systemen wird vor allem die zweite Technik eingesetzt, in der sich der Server bei Anforderungen zunächst forkt. Zunehmend kommen allerdings auch Threads zum Einsatz.

3.1.3 Mobile Client/Server-Architekturen Client/Server Architekturen in mobilen Umgebungen

Es ist einfach, die zuvor beschriebene klassische Client/ServerArchitektur auf mobile Informationssysteme zu übertragen. Der einzige Unterschied von mobilen Clients gegenüber ihren herkömmlichen Pendants besteht darin, dass die Zugriffe auf den zentralen Datenbankserver drahtlos erfolgen (wir gehen also von einem Client, z.B. einem PDA aus, der sowohl durch Mobilität als auch durch Drahtlosigkeit charakterisiert ist). Die Mobilität der Clients bleibt, was den Zugriff auf den Datenbankserver anbelangt, transparent. Es kann jedoch nur dann auf den zentralen Datenbankserver zugegriffen werden, wenn zuvor eine drahtlose Verbindung zum Festnetz aufgebaut wurde.

3.2 Verteilte Datenbanksysteme Grundlagen

64

■ ■ ■

Neben Client/Server-Systemen existieren weitere wichtige Architekturkonzepte für Datenbanksysteme, die auch im mobilen Umfeld zum Einsatz kommen. Ein besonders wichtiges Konzept sind die verteilten Datenbanksysteme. Der Kerngedanke verteilter Datenbanksysteme ist die transparente Verteilung von Daten und dazu notwendiger Datenbankfunktionalität auf verschiedene Knoten (=

3 Architekturen mobiler Informationssysteme

Rechner). Alle Knoten zusammengenommen bilden das verteilte System. Jeder Knoten hat ein eigenes Datenbankmanagementsystemmodul installiert. Während es bei Client/Server-Ketten eine ausgezeichnete Richtung gibt, kann bei verteilten Datenbanksystemen jeder Knoten als Einstiegspunkt dienen. In Abschnitt 3.2.1 werden zunächst die Konzepte und Methoden der klassischen verteilten Datenbanksysteme vorgestellt, bevor im Anschluss daran in Abschnitt 3.2.2 die Anwendungsmöglichkeiten verteilter Datenbanksysteme in mobilen Umgebungen untersucht werden. Bei der Klassifikation von verteilten Datenbanksystemen sind drei Dimensionen von Bedeutung [Val98], anhand derer eine genauere Charakterisierung möglich ist (vgl. Abbildung 3.5). Dies sind die Dimensionen der Heterogenität (Heterogenity), der Verteilung (Distribution) sowie der Autonomie (Autonomy). Diese Dimensionen können wie folgt charakterisiert werden: ■

Klassifikation

Heterogenität. Unter Heterogenität versteht man die grundsätzliche Verschiedenheit von Konzepten. Heterogene Konzepte existieren bei Hardware, bei der Kommunikation oder auch bei Betriebssystemen. Im Bereich der Datenbanksysteme tritt Heterogenität vor allem aufgrund von a) unterschiedlicher Modellierung (und damit unterschiedlicher Datenbank-Schemata), b) unterschiedlicher Datenbanksysteme verschiedener Hersteller mit dem gleichen Datenbankmodell (beispielsweise alle objektrelational) oder aufgrund c) unterschiedlicher Datenmodelle (relational, objektorientiert, deduktiv, netzwerkorientiert, hierarchisch, …) und Anfragesprachen auf.

■

Verteilung. Die Verteilung beschreibt, ob das Datenbanksystem auf einem Computersystem zentral vorhanden ist oder ob (Teil-) Datenbanksysteme über mehrere Computersysteme hinweg verteilt sind.

■

Autonomie. Unter Entwurfsautonomie (Design Autonomy) versteht man die Fähigkeit eines Teildatenbanksystems, über das eigene Design selbständig zu entscheiden. Kommunikationsautonomie (Communication Autonomy) behandelt die Frage, ob und wenn ja, auf welche Weise eine Datenbanksystemkomponente mit anderen Datenbanksystemen kommunizieren kann. Bei der Ausführungsautonomie (Execution Autonomy) wird die Frage in den Mittelpunkt gestellt, ob Einzelknoten eines verteilten Datenbanksystems die Fähigkeit eingeräumt werden soll,

3.2 Verteilte Datenbanksysteme

■ ■ ■

65

lokale Operationen in jeder beliebigen Weise, vollständig unabhängig von anderen Komponenten auszuführen. Abb. 3.5: Einordnung verteilter Datenbanksysteme

Verteilung (Distribution)

Autonomie (Autonomy)

Heterogenität (Heterogenity)

3.2.1 Klassische verteilte Datenbanksysteme Funktionalität verteilter Datenbanksysteme

Die erforderliche Funktionalität eines verteilten Datenbanksystems kann anhand von 12 Forderungen5 beschrieben werden, die bereits 1987 formuliert wurden: ■

Lokale Autonomie. Jeder Knoten hat die maximale Kontrolle über die eigenen, lokalen Daten. Es besteht keine Abhängigkeit von anderen Knoten.

■

Unabhängigkeit. Es bestehen keine Abhängigkeiten von zentralen Systemfunktionen.

■

Hohe Verfügbarkeit. Idealerweise kommt es zu keinen Unterbrechungen bei Systemfehlern und Konfigurationsänderungen.

■

Orttransparenz. Die physische Lokation zugegriffener Daten bleibt vollständig vor den Nutzern verborgen.

5

Date, C. J. "Twelve Rules for a Distributed Database" Computer World; 1987 June 8; 2(23): 77-81

66

■ ■ ■

3 Architekturen mobiler Informationssysteme

■

Fragmentierungstransparenz. Relationen können verteilt auf mehrere Knoten gespeichert werden. Diese Zerlegung bleibt vollständig vor den Nutzern verborgen.

■

Replikationstransparenz. Daten können redundant auf mehreren Knoten eines Systems vorhanden sein. Diese replizierte Speicherung wird vollständig vor den Nutzern verborgen. Für die Administration replizierter Daten sind die Datenbankmanagementsystemmodule verantwortlich.

■

Verteilte Anfrageverarbeitung. Datenbank-Operationen müssen während ihrer Durchführung auf beliebige Knoten effizient zugreifen können.

■

Verteilte Transaktionsverwaltung. Auch bei einer verteilten Datenverarbeitung müssen die bekannten Transaktionseigenschaften erhalten bleiben.

■

Hardware-Unabhängigkeit. Der Datenbank-Zugriff von verschiedenen Plattformen aus muss möglich sein.

■

Netzwerkunabhängigkeit. Die Netzwerkprotokolle, mit denen einzelne Knoten eines verteilten Datenbanksystems untereinander verbunden sind, dürfen keinen Einfluss auf die Funktionsweise des Systems haben.

■

Datenbanksystemunabhängigkeit. Die Nutzung unterschiedlicher Datenbanksysteme aus einer Anwendung heraus muss möglich sein.

Ein verteiltes Datenbanksystem kann sehr gut anhand einer Schemaarchitektur (vgl. Abbildung 3.6) veranschaulicht werden. Globales konzeptionelles Schema Globales Verteilungsschema

Lokales konzeptuelles Schema #1

Lokales konzeptuelles Schema #2

Lokales konzeptuelles Schema #n ...

Lokales internes Schema #1

Lokales internes Schema #2

Lokales internes Schema #n

3.2 Verteilte Datenbanksysteme

Abb. 3.6: Schemaarchitektur eines verteilten Datenbanksystems

■ ■ ■

67

Struktur verteilter Datenbanksysteme

Partitionierung und Allokation

Systemarchitektur

Der logische Aufbau der Gesamt-Datenbank wird durch das globale konzeptuelle Schema beschrieben. Dieses wird von allen beteiligten Knoten unterstützt und sichert die oben bereits angesprochene Verteilungstransparenz. Direkt unter dem globalen konzeptuellen Schema kümmert sich das globale Verteilungsschema um die Festlegung der Datenverteilung, also um die Partitionierung6 und die Allokation. Bei der Datenverteilung werden zwei verschiedene Arten unterschieden: ■

Logische Ebene. Hier erfolgt lediglich eine prädikative Beschreibung der Verteilung (Datenverteilung auf dieser Ebene bezeichnen wir im Folgenden als Partitionierung).

■

Physische Ebene. Hier erfolgt eine genaue Festlegung des Speicherortes (Datenverteilung auf dieser Ebene bezeichnen wir im Folgenden als Allokation).

Der Zusammenhang zwischen Partitionierung, Allokation und der redundanten Speicherung von Daten in verteilten Datenbanksystemen kann wie folgt beschrieben werden. Eine Relation wird zunächst in logische Partitionen zerlegt. Jede Partition wird anschließend im Rahmen einer Allokation einem dedizierten physischen Knoten zugewiesen. Wird eine Partition auf mehreren Knoten physisch abgelegt, bezeichnet man dies als redundante Allokation, wird eine Partition nur einem einzigen Knoten zugeordnet, spricht man von einer nicht-redundanten Allokation. Die Systemarchitektur eines verteilten Datenbanksystems besteht also aus einer globalen Komponente und mehreren lokalen Komponenten. Eine lokale Komponente ist ein normales Datenbanksystem auf einem der Knoten. Zusammen bilden diese Komponenten das verteilte Datenbanksystem. Die globale Komponente implementiert die Funktionalität des verteilten Datenbanksystems. Ihre wichtigen Bestandteile sind: eine globale Anfrageverarbeitung, eine globaler Datenbankkatalog, eine globale Recovery-Komponente, eine globale Transaktionsverwaltung, ein globales Synchronisationsmodul und eine Komponente zur Verwaltung redundant gehaltener Daten (Kopien-Verwaltung).

6

Vor allem in der englischsprachigen Literatur wird für das Konzept der Partitionierung häufig der Begriff der Fragmentierung verwendet. Es ist jedoch zu beachten, dass beide Begriffe nicht in jedem Fall synonym verwendet werden können. Während Partitionen disjunkt und vollständig sind, muss dies für beliebige Fragmente nicht gelten.

68

■ ■ ■

3 Architekturen mobiler Informationssysteme

3.2.2 Mobile verteilte Datenbanksysteme Mobile Geräte können Bestandteil eines verteilten Datenbanksystems sein. Konsequenterweise ist nicht von mobilen Geräten, sondern von mobilen Knoten die Rede. Mobile Knoten sind drahtlos in ein verteiltes System eingebunden. Der einzige Unterschied zwischen normalen und mobilen Knoten besteht darin, dass mobile Knoten aufgrund ihrer drahtlosen Anbindung sehr häufig vom Gesamtsystem getrennt sind. Dies stellt eine Fehlersituation dar und wird auch als Netzpartitionierung bezeichnet. Zwar können auch stationäre Knoten vom Netz getrennt sein, doch kommt dies wesentlich seltener vor, als bei mobilen Knoten. Abbildung 3.7 zeigt eine erweiterte Klassifikation verteilter Datenbanksysteme. Dabei wird Mobilität als Erweiterung der Verteilungs-Dimension betrachtet [Dun97]. Auf der obersten Ebene existieren insgesamt vier verschiedene Varianten: ■

Mobile homogene DBMS,

■

Mobile heterogene DBMS,

■

Mobile heterogene Multidatenbanksysteme,

■

Mobile Multidatenbanksysteme. Mobile homogene DBMS

Verteilte homogene DBMS

Verteilung Mobile Multidatenbanksysteme

Heterogenität

Abb. 3.7: Erweiterte Klassifikation nach [Dun97]

Mobilität Verteilte Multidatenbanksysteme

Mobile heterogene DBMS

Verteilte heterogene DBMS

Klassifikation

Autonomie Mobile heterogene Multidatenbanksysteme Verteilte heterogene Multidatenbanksysteme

3.2 Verteilte Datenbanksysteme

■ ■ ■

69

Data Access Agents

Abb. 3.8: Architektur mobiler Multidatenbanksysteme

Eine dieser Varianten, das mobile Multidatenbanksystem (Mobile Multidatabase System) wird nachfolgend genauer beschrieben. Mobile Multidatenbanksysteme setzen auf der in Abschnitt 1.1 definierten Referenzarchitektur mobiler Umgebungen auf und bestehen aus einer Menge autonomer, homogener (einheitlicher) oder heterogener (unterschiedlicher) Datenbanksysteme, die als lokale Datenbanksysteme (LDBS) bezeichnet werden [Dir00]. Die lokalen Datenbanksysteme bilden also die lokalen Komponenten, während das mobile Multidatenbanksystem als Ganzes die globale Komponente darstellt. Ein mobiles Multidatenbanksystem bleibt gegenüber Nutzern transparent, das heisst alle lokalen Komponenten sind nur über die einheitliche globale Schnittstelle des Multidatenbanksystems ansprechbar. Die Anzahl und die Typen der lokalen Komponenten bleiben somit ebenfalls verborgen. Die globale Anwendungsschnittstelle wird nach [Dun97] durch Data Access Agents (DAA) realisiert, die auf den Basisstationen installiert sind. Jedes lokale Datenbanksystem definiert darüber hinaus eine Dienstschnittstelle (Interface), die genau festlegt, welche Anfragen auf dem lokalen Datenbestand ausgeführt werden können. Globale Nutzer Anwendungsschnittstelle Mobiles Multidatenbanksystem Globaler Transaktionsmanager

Interface LDBS #1

Anfrageausführung

70

■ ■ ■

Interface LDBS #2

Globale Komponenten

Lokale Komponenten

Jede Anfrage wird zunächst in einer globalen Transaktion gekapselt, die aus der Menge der auszuführenden Operationen besteht. Jede Operation muss dabei global durchführbar sein, was genau dann der Fall ist, wenn die Operation auf zumindest einem lokalen Datenbanksystem ausgeführt werden kann. Untermengen einer globalen Transaktion, die auf dem gleichen lokalen Datenbanksystem ausgeführt werden können, werden zu Subtransaktionen zusammengefasst. Danach wird jede Subtransaktion auf dem für sie relevanten lokalen Datenbanksystem wie gewöhnlich als lokale Transaktion ausgeführt. Für die Koordination mehrerer parallel auszuführender globaler Transaktionen und für die Generierung der erforderlichen

3 Architekturen mobiler Informationssysteme

Subtransaktionen ist ein globaler Transaktionsmanager zuständig. Dieser ist eine der wichtigsten globalen Komponenten eines mobilen Multidatenbanksystems (vgl. Abbildung 3.8).

3.3 Middleware-Architekturen Durch den Einsatz von Middlewaretechnologien können klassische Client/Server-Architekturen zu n-schichtigen Architekturen erweitert (n • 3) werden. Ziel ist die Auslagerung der Anwendungslogik auf eine eigene Schicht (oder wahlweise auch auf mehrere Schichten), um so eine bessere Skalierbarkeit und Administration des Gesamtsystems zu erreichen. Auch bei mobilen Informationssystemen wird auf Middleware-Komponenten zurückgegriffen. So verfolgt beispielsweise die in [Pi94] vorgestellte Architektur einen solchen Ansatz. Dazu werden verschiedene, unabhängige und autonome Datenquellen zu einem großen Informationssystem zusammengefasst, auf das der Zugriff über eine zwischengeschaltete Middleware-Komponente erfolgt. Die Architektur dieses Informationssystems unterstützt dabei die folgenden Anforderungen: ■

Einheitlicher mobiler Zugriff. Für den Zugriff auf die verschiedenen Datenquellen des Informationssystems muss eine einheitliche Schnittstelle existieren, da mobile Clients ansonsten für jede angebundene Datenquelle einen eigenen, systemspezifischen Adapter benötigen. Mit der Anzahl der Adapter steigt zudem die Belegung wertvoller Systemressourcen. Eine solche Schnittstelle für einen universellen Zugriff wird in [Pi94] durch eine Middleware-Komponente realisiert, einem Objektserver. Zwar muss auch in diesem Fall für jede anzubindende Datenquelle ein eigener Adapter programmiert werden, da die Adapter jedoch auf dem leistungsstarken Objektserver installiert werden, werden auf den leistungsschwachen mobilen Clients keine Systemressourcen belegt. Die Adapter bilden diejenigen Teilmengen von Anfragen ab, die an eine Datenquelle gerichtet sind, auf das entsprechende Datenmodell. Die Anfrage wird also so transformiert, dass sie auf dieser Datenquelle auch ausgeführt werden kann. Eine leistungsstarke Middleware-Plattform kann bezüglich der Adapterzahl besser skaliert werden als ein mobiler Client.

■

Heterogenität. Heterogenität ist stets ein Problem, wenn auf verschiedenartige Datenquellen in völlig heterogenen Systemlandschaften zugegriffen wird. Um Heterogenität zu integrieren,

3.3 Middleware-Architekturen

Grundlagen

Anforderungen

■ ■ ■

71

können plattformunabhängige Standards, wie die Common Object Request Broker Architecture (CORBA), eingesetzt werden. Aber auch durch andere Middlewaretechnologien kann von der Heterogenität der Datenquellen abstrahiert und eine einheitliche Sicht auf die Datenquellen generiert werden. Mit Hilfe von Middleware-Komponenten können zudem Legacy-Systeme sehr einfach um einen drahtlosen Zugang erweitert werden. Welche Middlewaretechnologie letztlich eingesetzt wird, bleibt ganz den Systemarchitekten überlassen. Distributed Object Management System (DOMS)

Abb. 3.9: MiddlewareArchitektur [Pit94]

Als konkretes Beispiel einer Middleware-Architektur wird nachfolgend kurz das in [Pi94] beschriebene Distributed Object Management System (DOMS) dargestellt. Es besteht aus einer Menge von Knoten, von denen jeder (egal ob stationär oder mobil) eine oder mehrere Datenquellen hostet, die zusammen als ein großes Informationssystem aufgefasst werden. Als Datenquellen kommen dabei Datenbanken mit einer fest definierten Zugriffsschnittstelle oder auch einzelne autonome Dateninseln in Frage. Wir verdeutlichen die Funktionsweise anhand eines Zugriffs auf das Informationssystem.

Mobiler, drahtloser Zugriff Interface

O2

...

On

Basisstation

O1

Mobile Object Server

Datenquellen LDBS 1

Mobile Object Server

72

■ ■ ■

LDBS 2

LDBS 3

Backend

Dabei wird angenommen, dass ein Datenbank-Zugriff nur in OnlineSzenarien erfolgen kann (das heisst der Disconnected Mode wird nicht unterstützt). Dazu wird auf jeder Basisstation ein so genannter Mobile Object Server installiert, der eine einheitliche, objektbasierte Zugriffsschnittstelle für den Zugriff durch mobile Clients anbietet (vgl. Abbildung 3.9). Der Mobile Object Server abstrahiert von den

3 Architekturen mobiler Informationssysteme

spezifischen Eigenheiten der Ressourcen des Informationssystems (also beispielsweise von dem jeweiligen Datenmodell) und präsentiert alle Datenquellen als abstraktes Objekt. Mobile Clients greifen dann auf das Informationssystem zu, indem sie ihre Anfragen an den Mobile Object Server ihrer aktuellen Basisstation richten. Die Middleware-Komponente der Basisstation transformiert eine Anfrage dann anhand der Anforderungen einzelner Datenquellen (beispielsweise auf das korrekte Datenmodell) und koordiniert schließlich die Ausführung der Anfrage. Im Normalfall verfügt jede Basisstation über einen eigenen Mobile Object Server, doch kann ein Mobile Object Server auch zentral aufgebaut werden, so dass er gleich eine ganze Reihe von Basisstationen versorgt.

3.4 Mobile Agenten In diesem Abschnitt werden Architekturen, die auf dem Einsatz mobiler Agenten basieren, vorgestellt. Die Ursprünge dieses Konzepts reichen bis in die 1960er Jahre zurück, als man begann, die Funktionsweise verteilter Systeme zu entwickeln und zu untersuchen. Heute werden mobile Agenten immer dann eingesetzt, wenn Programme innerhalb eines Netzwerks weitgehend autonom agieren und sich selbständig durch ein Netzwerk bewegen sollen.

3.4.1 Grundlagen Unter Agenten versteht man Programme in Form autonomer Objekte, die sich innerhalb eines heterogenen Netzes bewegen und im Auftrag eines Nutzers bestimmte Aufgaben erfüllen bzw. Dienstleistungen erbringen, zum Beispiel das Suchen von Inhalten oder die Ausführung von entfernten Anwendungen. Ein Agent behält stets die vollständige Kontrolle seiner Ausführung, agiert autonom und kann selbständig anhand lokaler Gegebenheiten entscheiden, ob, wann und auf welche Knoten er wechseln möchte. Während der Migration zwischen Knoten wird der dynamische Zustand eines Agenten eingefroren und zusammen mit zusätzlichen Kontextinformationen und einem variablen Datenteil (der die Anwendungsdaten enthält) in einer Nachricht gekapselt. Diese Nachricht wird anschließend an den neuen Zielknoten übermittelt und dort wieder ausgepackt, woraufhin der Agent seine Ausführung fortsetzen kann. Jeder lokale Knoten, auch Wirtssystem genannt, ermöglicht einem Agenten die Durchführung bestimmter Teilaufgaben. Das erfordert, dass

3.4 Mobile Agenten

Funktionsweise mobiler Agenten

■ ■ ■

73

Ursprung mobiler Agenten

Java als Laufzeitplattform

Abb. 3.10: Kommunikation über mobile Agenten

Agenten mit ihrer jeweiligen Umgebung interagieren. Kann innerhalb einer lokalen Umgebung nicht mehr weitergearbeitet werden bzw. ist die zu verrichtende (Teil-)Aufgabe erfüllt, bewegt sich der Agent auf einen anderen Knoten. Um Zwischenergebnisse zu übermitteln und neue Anweisungen zu empfangen, muss ein Agent über Kommunikationsmechanismen verfügen. Diese erlauben es ihm, mit dem Initiator seiner Ausführung zu kommunizieren. Aufgrund der Tatsache, dass sich Agenten innerhalb eines heterogenen Netzes bewegen, spricht man von mobilen Agenten. Die Idee, komplette Programme zu kapseln, zu versenden und auf entfernten Zielsystemen auszuführen ist jedoch nicht neu. Bereits in den 1960er Jahren gab es in Form des Remote Entry Job-Konzept der Batch-Betriebssysteme erste diesbezügliche Ansätze. Da mobile Agenten auf unterschiedlichen Hardware-Plattformen ausgeführt werden müssen, liegt es nahe, einen Agenten in einer Sprache zu programmieren, die auch auf vielen heterogenen Plattformen verfügbar ist. So profitiert das Konzept der mobilen Agenten stark vom Aufkommen der Programmiersprache Java. Der Grund ist klar. Mit der Java Virtual Machine (JVM) existiert auf vielen verschiedenen Systemen eine einheitliche Laufzeitumgebung für mobile Agenten, die den Einsatz dieser Technologie wesentlich erleichtert. Über die JVM wird es möglich, auf einem beliebigen Knoten einen Hintergrundprozess laufen zu lassen, der in mobilen Agenten gekapselten Programmcode dem Sprach- oder Kommandointerpreter der lokalen JVM zur Ausführung übergibt. NachrichtenAgent

NachrichtenAgent NachrichtenSystem

Konsolidierte Datenbank

Sicherheit

74

■ ■ ■

Mobile Datenbank

Die Sicherheitsproblematik, die durch den Einsatz mobiler Agenten entsteht, ist jedoch immens. Jeder Knoten gestattet es immerhin, völlig fremden, unbekannten Code auf einem System auszuführen. Entsprechend müssen Schutzmaßnahmen realisiert werden, die die Zugriffsmöglichkeiten mobiler Agenten auf lokale Ressourcen steuern können (beispielsweise eine Zugriffsrechteverwaltung oder eine Sand-Box-Implementierung, die die Ausführung kritischen Codes

3 Architekturen mobiler Informationssysteme

nur in einem speziellen, abgesicherten Speicherbereich gestattet). Mobile Agenten stellen eine Möglichkeit dar, verteilte Anwendungen in einer sich dynamisch ändernden, heterogenen Umgebung zu realisieren. Der Einsatz mobiler Agenten bringt folgende Vorteile mit sich: ■

Kommunikationsbandbreite. Müssen grosse Mengen entfernter Daten verarbeitet werden, kann es wesentlich effizienter sein, die Verarbeitungsmethode zu den Daten zu bringen (Function Shipping), als die Daten zur Verarbeitungsmethode (Data Shipping). In dem Fall, dass eine Verarbeitungsmethode bereits auf dem entsprechenden Server in parametrisierter Form existiert (Stored Procedures), gibt es allerdings keinen Vorteil.

■

Reaktionszeiten. Mobile Agenten können aufgrund ihrer lokalen Ausführung wesentlich schneller auf Änderungen der lokalen Ausführungsumgebung reagieren. Dies kann insbesondere bei kritischen Echtzeitanwendungen entscheidende Vorteile bringen.

■

Offline-Betrieb. Der Einsatz mobiler Agenten führt zu einer großen Flexibilität was bestehende Netzwerkverbindungen angeht. Ausschließlich für den Versand bzw. Empfang eines mobilen Agenten ist eine Netzwerkverbindung notwendig.

■

Lokale Betriebsmittel. Mobile Agenten können im Zuge ihrer lokalen Ausführung auf einem Knoten auf Systemressourcen zurückgreifen, die im Zuge eines klassischen entfernten Methodenaufrufs nicht ansprechbar wären, beispielsweise bestimmte Speicherbereiche oder Anwendungen. Unter Umständen können Systemressourcen sogar nicht nur selbst genutzt, sondern auch nach außen hin für andere Anwendungen durch den mobilen Agenten verfügbar gemacht werden.

3.4.2 Framework zur Ausführung mobiler Agenten Nachdem bisher die allgemeinen Architektur- und Funktionsprinzipien mobiler Agenten im Vordergrund standen, wird nun ein konkretes Framework [Dal97] für den Einsatz mobiler Agenten vorgestellt. Dieses setzt auf einem mobilen Multidatenbanksystem (vgl. Abschnitt 3.2.2) auf. Um eine globale Transaktion auszuführen, muss diese zunächst in mehrere Subtransaktionen zerlegt werden. Jede Subtransaktion wird dann auf dem für sie relevanten lokalen Datenbanksystem ausgeführt. Für die Koordination der globalen

3.4 Mobile Agenten

Framework

■ ■ ■

75

Ausführung von Transaktionen

Mobile Agent Server

Abb. 3.11: Architektur eines Mobile-AgentenFrameworks [Dal97]

Transaktionen und die Zerlegung in Subtransaktionen ist ein globaler Transaktionsmanager verantwortlich. Die Idee bei der Definition des vorgestellten Frameworks ist es, jede Subtransaktion unter Verwendung eines mobilen Agenten auszuführen. Ein mobiler Agent steuert die lokalen Datenbanksysteme an, auf denen der Agent ausgepackt und die Subtransaktion ausgeführt wird. Das Ergebnis der Subtransaktion wird erneut in dem mobilen Agenten gekapselt und an den globalen Transaktionsmanager zurückgesendet, der die Ergebnisse dann der anfragenden Instanz übermittelt. Der Zugriff auf die lokalen Datenbanksysteme erfolgt über spezielle Komponenten, als Mobile Agent Server (MAS) bezeichnet, die die Plattform für die Ausführung von mobilen Agenten darstellen und deswegen auf jedem beteiligten mobilen Datenbanksystem installiert werden müssen. Jeder Mobile Agent Server besteht aus zwei weiteren Komponenten, dem Agent System (AS) und der Database Bridge (DBB). Das Agent System ist für die Administration mobiler Agenten zuständig, während die Database Bridge die Verbindung an die lokalen Datenbanksysteme herstellt (vgl. Abschnitt 3.1.1). Jede Subtransaktion wird durch eine Database Bridge in das richtige Format transformiert. Für jede Datenbank, die von dem Framework unterstützt werden soll, muss somit eine eigene, plattformspezifische Database Bridge programmiert werden. Mobiler Client

Client

Database Directory and Statistics Information Service

Database Directory and Statistics Information Service

User Transaction

User Transaction Transaction Manager

Transaction Manager

Agent System

Agent System

Mobile Agent

Mobile Agent

Festnetz Mobile Agent

DB2 DB

76

■ ■ ■

Mobile Agent

Agent System

Agent System

Database Bridge

Database Bridge

Server

Server

3 Architekturen mobiler Informationssysteme

Oracle DB

Auf der Seite des Clients existieren zwei weitere wichtige Komponenten. Einerseits der Transaction Manager (TM), andererseits das Database Directory and Statistics Information Service (DDSIS). Der Transaction Manager selbst besteht wiederum aus zwei Komponenten, dem Transaction Decomposer (TD) und dem Transaction Coordinator (TC). Der Transaction Manager ist für die Generierung der Subtransaktionen verantwortlich. Um die Subtransaktionen den korrekten, das heisst relevanten lokalen Datenbanksystemen zu übermitteln, konsultiert der Transaction Manager während seiner Ausführung den Directory and Statistics Information Service, der Informationen über eine geeignete Route zum nächsten Knoten (ausgehend vom aktuellen Knoten) bereitstellen kann. Genau wie auf den Knoten, auf denen die Datenbanken installiert sind, existiert auch auf jedem Client ein Agent System, das für Ausführung und Administration der mobilen Agenten zuständig ist. Hat der Transaction Manager eine Menge an Subtransaktionen generiert, wird jede Subtransaktion vom Agent System in einen mobilen Agenten verpackt, und abgeschickt. Ab diesem Zeitpunkt arbeiten die mobilen Agenten autonom. Im Folgenden wird exemplarisch die Abarbeitung einer globalen Transaktion detailliert beschrieben (vgl. Abbildung 3.9). Nachdem eine SQL-Anfrage formuliert wird (1), wird sie durch einen SQL-Parser gescannt und analysiert. Der SQL-Parser ist die wichtigste Komponente des Mobile Agent User Interface (MAUI), das die Schnittstelle zwischen Framework und Nutzer bildet. Danach wird die Anfrage dem Transaction Manager übergeben (2). Der Transaction Decomposer des Transaction Manager interpretiert die Anfrage und generiert eine Menge von Subtransaktionen. Für jede Subtransaktion kontaktiert der Transaction Coordinator den Directory and Statistics Information Service, um die beste Route zum jeweiligen Zielknoten zu finden. Ist dies für alle Subtransaktionen geschehen, werden diese an das Agent System übergeben (3), welches die Subtransaktionen in mobile Agenten verpackt. Alle mobilen Agenten bewegen sich nun unabhängig voneinander zu ihren Zielknoten. Nachdem ein mobiler Agent am Zielknoten angekommen ist, wird er an das dort installierte Agent System weitergeleitet. Das Agent System packt die Subtransaktion aus und leitet sie an die Database Bridge weiter (5). Die Database Bridge bzw. der Query and Result Format Converter (QRFC) transformiert die Subtransaktion in ein auf dem lokalen Datenbanksystem verarbeitbares Format. Im Anschluss daran wird die Subtransaktion lokal durch den Query and Result Processing Service (QRPS) ausgeführt (6). Ist die Subtransaktion beendet, werden die Ergebnisse über die Database Bridge wieder an das Agent System zurückgegeben (7,8), das diese im mo-

3.4 Mobile Agenten

Subtransaktionen

Ablauf

■ ■ ■

77

bilen Agenten verpackt. Handelt es sich bei dem mobilen Agenten um einen Multiple Hop Mobile Agent (MHMA), migriert der mobile Agent zum nächsten Zielknoten (9), handelt es sich um einen Single Hop Agent (SHA), kehrt er zu seinem Ausgangspunkt zurück (9). Abb. 3.12: Funktionsweise eines MobileAgentenFramework [Dal97]

Server

Client

Mobile Agent

4 Agent System

Agent System 9

3 Transaction Manager

Database Directory and Statistic Information Service

Transaction Coordinator Transaction Decomposer 2

1

5Result 8

Query and Result Format Converter Query and Result Processing Service

Transaktion Local Query

SQL Parser

SQL Query

Subtransaktion

9

Server

6

7

Local DBMS

Mobile Agent User Interface (MAUI)

Database Bridge Result

DB

3.5 Zusammenfassung In diesem Kapitel wurden insgesamt vier Architekturen mobiler Informationssysteme beschrieben. Zunächst wurden Client/ServerArchitekturen, wie sie auch bei den kommerziellen mobilen Datenbanksystemen sehr häufig zu finden sind, beschrieben. Danach wurden verteilte Datenbanksysteme vorgestellt und verschiedene Varianten solcher Architekturen identifiziert und beschrieben. Eine mögliche Ergänzung der Client/Server-Architekturen stellen die im dritten Abschnitt vorgestellten Middleware-Architekturen dar. Als konkretes Beispiel dieses Ansatzes wurde das Konzept eines Mobile Object Server beschrieben. Zuletzt wurden die Einsatzmöglichkeiten mobiler Agenten genauer vorgestellt und dabei auch ein beispielhaftes Framework präsentiert, anhand dessen der funktionale Ablauf des Einsatzes mobiler Agenten verdeutlicht wurde.

78

■ ■ ■

3 Architekturen mobiler Informationssysteme

4 Replikation und Synchronisation

Nachdem im vorherigen Kapitel verschiedene Architekturen mobiler Informationssysteme vorgestellt und beschrieben wurden, werden in diesem Kapitel existierende Techniken der Replikation und der Synchronisation genauer untersucht. In der Literatur werden Replikation und Synchronisation häufig auf verschiedene Weise definiert und verwendet. Wir gehen im Folgenden davon aus, dass ■

Replikation die Einführung von Datenredundanz und

■

Synchronisation der Abgleich von redundant vorhandenen Daten, die verschiedene Änderungen erfahren haben, ist.

Begriffe

4.1 Motivation Replikation und Synchronisation sind deswegen von besonderer Wichtigkeit im Mobile Computing und für die mobile Datenverarbeitung, da erst durch die Einführung redundanter Datenelemente und funktionierender Synchronisationsmechanismen die in Kapitel 1 angesprochenen Offline-Szenarien möglich werden. Die Charakteristik solcher Offline-Szenarien ist es, auch im unverbundenen Zustand mobiler Clients (Disconnected Mode) eine fortgesetzte Datenverarbeitung möglich zu machen. Dazu ist es aber notwendig, dass während bestehender Offline-Phasen, also während Phasen, in denen keine Verbindung an das Festnetz besteht, trotzdem Daten auf dem mobilen Client lokal verfügbar sind, auf denen unabhängig gearbeitet werden kann. Diese Verfügbarkeit von Daten auf mobilen Clients wird durch Replikation erreicht. Im Disconnected Mode durchgeführte Änderungen müssen später wieder mit den Originaldaten synchronisiert werden, um Datenkonsistenz innerhalb der Replikationsumgebung zu garantieren. Wird dies nicht erreicht, entstehen meh-

4.1 Motivation

Replikation

■ ■ ■

79

Synchronisation

Kapitelübersicht

80

■ ■ ■

rere gleichzeitig gültige Versionen eines bestimmten Datenelements. Dies sind Inkonsistenzen die zu schwerwiegenden Fehlern führen können. Im Folgenden gehen wir davon aus, dass Replikation immer die erstmalige Einführung von Redundanz in einer mobilen Umgebung bedeutet. Replikation bezeichnet nach unserem Verständnis also beispielsweise den Vorgang einer erstmaligen Übertragung von Daten auf einen mobilen Client, auf dem zuvor noch keine Daten verfügbar waren. In allen anderen Fällen ist zur Replikation immer auch eine gleichzeitige Synchronisation nötig. Wir sprechen von Synchronisation, wenn innerhalb einer mobilen Umgebung, in der bereits redundante Daten vorhanden sind, ein Abgleich dieser redundanten Daten vorgenommen wird. Daten werden entweder von einer Replikationssenke (beispielsweise einem mobilen Client) auf eine Replikationsquelle (beispielsweise ein zentraler Datenbankserver) synchronisiert oder umgekehrt. In vielen Szenarien wird vereinfachend davon ausgegangen, dass Replikation lediglich eine Teiloperation der wesentlich umfassenderen Synchronisation ist. So ist in den Produktdokumentationen vieler kommerzieller mobiler Datenbanksysteme beispielsweise nur von Synchronisation und nicht von Replikation die Rede. Dieses Kapitel gliedert sich wie folgt: Abschnitt 4.2 betrachtet zunächst die theoretischen Grundlagen von Replikation und Synchronisation und bringt verschiedene formale Definitionen. Die Inhalte dieses Abschnitts besitzen einen allgemeingültigen Charakter für alle Umgebungen, in denen Replikation eingesetzt wird. Abschnitt 4.3 beschreibt danach kurz den inhärent vorhandenen Zielkonflikt des Einsatzes von Replikation. Im Anschluss daran werden in Abschnitt 4.4 klassische Replikationsverfahren vorgestellt. Nach einer Untersuchung der Frage, ob sich klassische Verfahren für einen Einsatz in mobilen Umgebungen eignen, stellt Abschnitt 4.5 drei neue, mobile Replikationsverfahren vor. In Abschnitt 4.6 wird die Synchronization Markup Language (SyncML), eine Spezifikation für eine plattformunabhängige Implementierung von Synchronisationsmechanismen, vorgestellt. Abschnitt 4.7 geht abschließend auf eine neue Klasse von Replikationsverfahren, das Data Hoarding, ein.

4 Replikation und Synchronisation

4.2 Technische Grundlagen In diesem Abschnitt werden nun die wichtigsten technischen Grundlagen von Replikation und Synchronisation beschrieben.

4.2.1 Replikation Ihren Ursprung hat die Replikation in den klassischen verteilten Systemen. Verteilte Systeme sind im Vergleich zu stark zentralistisch ausgelegten Systemen wesentlich anfälliger für Ausfälle, nicht nur was einzelne Knoten betrifft, sondern auch bezüglich der Kommunikationsverbindungen zwischen den Knoten. Wenn an ein beliebiges verteiltes System die Forderung gestellt wird, dass die Verfügbarkeit des Systems nur dann gegeben ist, wenn stets alle Knoten des Systems verfügbar sind, kann praktisch niemals von einer vollständigen Einsatzbereitschaft ausgegangen werden. Selbst wenn der Ausfall einzelner oder mehrerer Knoten hingenommen wird, ist die Ausfallswahrscheinlichkeit eines Systems insgesamt gesehen sehr hoch7. Von dieser Problematik sind auch verteilte Datenbanken betroffen. Verteilte Datenbanken sind durch die Verteilung von Daten auf mehrere Knoten charakterisiert. Jeder einzelne Knoten enthält ein eigenes Modul, das lokal Datenbankmanagementfunktionalität bereitstellt. Um den Ausfall einzelner Knoten zu kompensieren, ist es sinnvoll, wichtige Daten redundant auf verschiedenen Knoten zu speichern. Dadurch kann beim Ausfall eines Knotens auf die Daten eines anderen Knotens zugegriffen werden, um eine fortgesetzte Datenverarbeitung ohne Unterbrechung zu ermöglichen. Wichtig ist dies insbesondere bei kritischen Daten. Darunter sind solche Datenelemente zu verstehen, die eine vergleichsweise hohe Zugriffsrate aufweisen, denn eine hohe Zugriffrate ist Ausdruck der besonderen Relevanz der Daten. Die Methoden und Techniken zum Anlegen redundanter Datenelemente werden mit dem Begriff Replikation zusammengefasst. Alle Knoten, die replizierte Daten vorhalten, bilden zusammen die so genannte Replikationsumgebung.

Replikation in verteilten Systemen

Verteilte Datenbanken

7

Werden alle Komponenten eines verteilten Systems benötigt, addieren sich im Wesentlichen die Ausfallwahrscheinlichkeiten der Einzelkomponenten [Dad96].

4.2 Technische Grundlagen

■ ■ ■

81

Vorteile von Replikation

Replikation in Client/ServerUmgebungen

82

■ ■ ■

Die wichtigsten Vorteile von Replikation sind: ■

Verfügbarkeit. Auch wenn Knoten die Anbindung an das Gesamtsystem verlieren (was in mobilen Umgebungen relativ häufig der Fall ist) kann auf den redundanten Daten anderer Knoten weitergearbeitet werden. Durch die Einführung von Redundanz erhöht sich die Verfügbarkeit des Gesamtsystems.

■

Kommunikationskosten. Durch die Replikation von Daten und die dadurch in vielen Fällen möglich werdenden lokalen Datenzugriffe können die im Gesamtsystem anfallenden Kommunikationskosten erheblich reduziert werden, da für einzelne Datenzugriffe keine extra Verbindung mehr zum jeweiligen Knoten aufgebaut werden muss.

■

Performanz. Neben den geringeren Kommunikationskosten führt ein lokaler Zugriff auf Daten auch zu einer besseren Performanz, da die Verzögerungen des ansonsten notwendigen Netzwerkverkehrs entfallen.

■

Lastbalancierung. Existieren mehrere redundante Versionen eines Datenelements kann für einen Datenzugriff stets derjenige Knoten ausgewählt werden, auf dem aktuell die geringste Last existiert.

■

Datenverlust. Durch mehrere redundante Datenelemente existieren, wird einem möglichen Datenverlust vorgebeugt. Jeder Verlust von Daten auf einem Knoten kann mit Hilfe redundanter Datenelemente auf anderen Knoten sehr schnell behoben werden.

■

Disconnected Mode. Die Replikation von Daten ist die Grundvoraussetzung für das Arbeiten mit Clients, die sich im Disconnected Mode befinden.

In der Folge ist nicht nur die bloße Einführung von Datenredundanz von Interesse, sondern auch die Bestimmung intelligenter Verfahren zur Auswahl der zu replizierenden, also der kritischen Daten. Replikation ist nicht nur auf einen Einsatz in verteilten Systemen festgelegt. Das Konzept kann genauso in Client/Server-Architekturen eingesetzt werden, wobei Daten für gewöhnlich von einem Server auf einen oder mehrere Clients repliziert werden. Die Replikationsquelle ist also ein zentraler Datenbankserver, die Replikationssenken sind die Clients. Eine Replikationsumgebung in Client/Server-Architekturen ist die Kombination einer Replikationsquelle und mehrerer Replikationssenken.

4 Replikation und Synchronisation

Der Begriff des Replikats kann wie folgt definiert werden: Ein Replikat ist eine Kopie, das heisst eine redundante Speicherung eines existierenden Datenelementes. Ein Datenelement kann ein Tupel, eine Relation oder eine Partition sein. Dabei gibt es kein speziell ausgewiesenes Originalelement. Bei Bedarf kann ein solches Original jedoch festgelegt werden. Von einem Datenelement können beliebig viele Kopien existieren.

Definition 4.1: Replikat

Die zentralen Strategien im Zusammenhang mit dem Einsatz von Replikation werden in [Dad96] in vier Punkten zusammengefasst:

Strategien

■

Kopie-Update-Strategien. Kopie-Update-Strategien beschreiben, wie Datenoperationen auf einem einzelnen Replikat durchgeführt werden und wie daraus resultierende Änderungen an andere Kopien weitergegeben werden. Die Erlaubnis zur Ausführung der gewünschten Operation ist dabei oftmals an spezifische Bedingungen geknüpft. Ob eine Bedingung erfüllt werden kann, hängt in vielen Fällen von den anderen Kopien des zu ändernden Replikats ab.

■

Fehlerbehandlung. Die Fehlerbehandlung enthält Methoden, mit denen auf Fehlersituationen während der Replikation reagiert wird. Die Fehlerbehandlung repräsentiert den Ausnahmefall gegenüber dem durch die Kopie-Update-Strategien abgedeckten Normalfall. Die am häufigsten auftretenden Fehlersituationen sind typischerweise Netzpartitionierungen, die immer dann auftreten, wenn einzelne (oder auch mehrere) Clients dauerhaft vom Gesamtsystem getrennt werden. Da in mobilen Umgebungen Netzpartitionierungen aber sogar den Normalfall darstellen (Stichwort: Disconnected Mode), spielt Fehlerbehandlung für mobile Replikationsverfahren eine wichtige Rolle. Allerdings ist es in einem solchen Fall fraglich, ob es Sinn macht, überhaupt noch von „Fehlerbehandlung“ zu sprechen (da Netzpartitionierung ja der Normalfall ist).

■

Synchronisation konkurrierender Zugriffe. Im Mittelpunkt stehen Methoden zur Konsistenzsicherung innerhalb einer Replikationsumgebung. Die Aufgabe der Konsistenzsicherung besteht darin, eine geeignete Serialisierbarkeitsreihenfolge (man bezeichnet eine solche Reihenfolge auch als Schedule) zu finden, die alle auf Replikaten durchgeführten Transaktionen so ordnet, dass es zu keinen Konsistenzkonflikten kommt. Im Wesentlichen wird zwischen konventionellen, zeitstempelbasierten und semantischen Synchronisationsverfahren unterschieden.

4.2 Technische Grundlagen

■ ■ ■

83

Konventionelle Synchronisationsverfahren basieren auf einfachen Sperrverfahren, wohingegen Zeitstempelverfahren verschiedene zeitbehaftete Informationen benutzen, um eine geeignete Serialisierbarkeitsreihenfolge von Transaktionen zu bestimmen. Semantische Synchronisationsverfahren basieren auf der Einbeziehung speziellen Anwendungswissens. ■

Replikationsdefinition

84

■ ■ ■

Behandlung von Lesetransaktionen. Bei den Anforderungen an die von einer Lesetransaktion zugegriffenen Daten innerhalb einer Replikationsumgebung können drei verschiedene Fälle unterschieden werden: ■

Fall 1: Die zu lesenden Daten müssen aktuell und konsistent sein, das heisst an die Durchführung von Lesetransaktionen werden die gleichen Bedingungen wie bei Änderungstransaktionen geknüpft. Um aktuelle und konsistente Daten zu lesen, kann man Lesetransaktionen wie Änderungstransaktionen behandeln. Wenn Lese- und Änderungstransaktionen jedoch gleich behandelt werden, wirkt sich dies, bedingt durch den dadurch notwendigen Koordinationsaufwand, stark negativ auf den Gesamtdurchsatz von Transaktionen aus.

■

Fall 2: Die zu lesenden Daten müssen konsistent, dürfen aber auch etwas veraltet sein, das heisst Lesetransaktionen können unter Umständen auf einen etwas veralteten, trotzdem aber korrekten Datenbankzustands sehen. Mit der Ergänzung um ein Versionskonzept wird die Ausführung von Lesetransaktionen möglich, ohne dass eine Synchronisation mit parallel ablaufenden Änderungstransaktionen notwendig ist. Dieser Fall beschreibt die in den meisten kommerziellen Datenbanksystemen umgesetzte Vorgehensweise.

■

Fall 3: Die zu lesenden Daten dürfen etwas inkonsistent sein. Es wird dann jedoch die zusätzliche Bedingung gestellt, dass sich die Konsistenzabweichung nur innerhalb gewisser Toleranzgrenzen, die durch eine beliebig wählbare Konstante beschrieben werden, bewegen darf. Die Toleranzgrenze bestimmt die maximal erlaubte Abweichung vom aktuellen, konsistenten Datenbankzustand.

Wichtigste Einzelaufgabe bei der Replikation ist die Replikationsdefinition, die festlegt, welche Daten der Replikationsquelle auf welche Replikationssenken übertragen werden. Die Replikationsdefinition erfolgt auf der Replikationsquelle. Im Rahmen der Replikationsdefinition werden auch die Operationen bestimmt, die auf einem über-

4 Replikation und Synchronisation

tragenen Replikat ausgeführt werden dürfen. Eine solche Festlegung ist sinnvoll, um die Auftrittswahrscheinlichkeit späterer Synchronisationskonflikte zu reduzieren. In jedem Fall müssen aber trotzdem Strategien zur Behandlung von eventuellen Konsistenzkonflikten (Konfliktauflösungsstrategien) definiert werden. Die Replikationsdefinition untergliedert sich in die zwei Subaufgaben der Replikationsschemadefinition und der Replikatdefinition: ■

Replikationsschemadefinition. Das Replikationsschema ist derjenige Ausschnitt des Datenbankschemas auf der Replikationsquelle, der für die Datenreplikation genutzt wird. Teil der Replikationsschemadefinition ist die Beschreibung von Operationen, die auf den replizierten Daten ausgeführt werden dürfen und die Definition zusätzlicher Integritätsbedingungen, die vor allem bei einer späteren Synchronisation eine wertvolle Hilfe sein können. Für die Definition des Replikationsschemas ist der Datenbank-Administrator verantwortlich.

Replikationsschemadefinition

■

Replikationsdefinition. Die Replikatdefinition wählt die zu replizierenden Daten aus. Zur Auswahl stehen alle durch die Replikatsschemadefinition festgelegten Daten. Die Replikatdefinition kann immer erst nach der Replikationsschemadefinition erfolgen. Zusammen mit der Replikation ausgewählter Daten werden die definierten Integritätsbedingungen mit auf die Replikationssenke übertragen.

Replikationsdefinition

In Replikationsumgebungen wird die Forderung gestellt, dass die eingeführte Datenredundanz gegenüber den Nutzern transparent bleibt. Diese Forderung kann auch als Replikationstransparenz bezeichnet werden. Bei einer vollständigen Replikationstransparenz wird also gegenüber den Nutzern die Existenz verschiedener, redundanter Kopien versteckt. Innerhalb einer Replikationsumgebung kann der herkömmliche, aus der Datenbanktheorie bekannte Serialisierbarkeitsbegriff 8 zur 1-Kopie-Serialisierbarkeit erweitert werden. Dazu muss zunächst jedoch der Begriff Schedule eingeführt werden:

Replikationstransparenz

Sei T = {t1, . . . , tn} eine endliche Menge von Transaktionen. Dann bezeichnet P(T) die Menge aller Permutationen der Abfolge von t1, …, tn. Ein Schedule ist ein spezielles Element aus dieser Permutation, also eine beliebige Reihenfolge der ti (t İ 1, .., n).

Definition 4.2: Schedule

8

Das Konzept der Serialisierbarkeit von Ausführungsplänen kann als Entscheidungskriterium für die Frage verwendet werden, welche Ausführungspläne korrekt sind, wenn sich Datenbankoperationen verschiedener Transaktionen eines Ausführungsplanes überlappen.

4.2 Technische Grundlagen

■ ■ ■

85

Nachdem nun der Begriff des Schedules eingeführt ist, kann auch die 1-Kopie-Serialisierbarkeit formal eingeführt werden: Definition 4.3: 1-KopieSerialisierbarkeit

Ein Schedule S von Transaktionen, die auf replizierten Daten innerhalb einer Replikationsumgebung ausgeführt werden, heisst dann und nur dann 1-Kopie-serialisierbar, wenn es mindestens eine serielle Ausführung der Transaktionen aus S auf einer Datenbank ohne Replikate gibt, welche, angewandt auf denselben Ausgangszustand, derselben Endzustand erzeugt. Die 1-Kopie-Serialisierbarkeit beschreibt somit die Forderung, dass in Replikationsumgebungen die gleichen Korrektheitsprinzipien gelten, wie in Umgebungen, in denen auf Replikation verzichtet wird. Eng verbunden mit dem Begriff der 1-Kopie-Serialisierbarkeit ist auch der Begriff der Replikationskorrektheit. Um die globale Konsistenz innerhalb einer Replikationsumgebung nicht zu gefährden, fordert die Replikationskorrektheit, die auf einem replizierten Datum vorgenommenen Änderungen auf allen anderen Kopien dieses Datums nachzuziehen:

Definition 4.4: Replikationskorrektheit

Replikationskorrektheit heisst, dass alle redundanten Kopien stets konsistent im Sinne der jeweils definierten Korrektheitskriterien sind. Dies kann die Identität (strenge Korrektheit), aber auch durch Abweichung innerhalb bestimmter Schranken sein.

4.2.2 Synchronisation Zielsetzung der Synchronisation

Reintegration & Rückübertragung

86

■ ■ ■

Das Ziel der Synchronisation ist die Bewahrung bzw. Wiederherstellung eines konsistenten Zustands aller (auch von zwischenzeitlich veränderter) Kopien eines Datenelementes innerhalb einer Replikationsumgebung, also die Durchsetzung eines konsistenten Datenbankzustands. Dazu werden spezielle Synchronisationsverfahren eingesetzt, mit denen verschiedene Versionen redundant gehaltener Datenelemente abgeglichen werden können. Bei einer Synchronisation müssen nicht nur die auf Replikationssenken durchgeführten Änderungen auf die Replikationsquelle, sondern auch die zwischenzeitlich auf der Replikationsquelle durchgeführten Änderungen auf die Replikationssenken übertragen werden. Jeder Synchronisationsprozess besteht also aus zwei Phasen, der Reintegration und der Rückübertragung:

4 Replikation und Synchronisation

■

Reintegration. Reintegration ist der Abgleich von auf einer Replikationssenke durchgeführten Änderungen mit der Replikationsquelle. Auf Replikationssenken vorhandene Daten werden wieder auf der Replikationsquelle eingebracht bzw. reintegriert.

■

Rückübertragung. Rückübertragung ist der Abgleich von auf einer Replikationsquelle aktualisierter Daten mit dem Datenbestand von Replikationssenken. Dazu wird von der Replikationsquelle ein aktueller und konfliktbereinigter Datenzustand an eine oder mehrere Replikationssenken übertragen.

Die beiden Phasen der Reintegration und der Rückübertragung werden, wenn sie unmittelbar aufeinanderfolgend ausgeführt werden, auch als bidirektionaler Synchronisationsprozess bzw. bidirektionale Synchronisation bezeichnet. Wenn nur eine der beiden Phasen ausgeführt wird (also Reintegration oder Rückübertragung), bezeichnet man dies als unidirektionalen Synchronisationsprozess.

Unidirektionale Synchronisation, bidirektionale Synchronisation

4.3 Zielkonflikt der Replikation Inhärenter Bestandteil der Replikation ist ein Konflikt zwischen drei verschiedenen Forderungen, die gleichzeitig nicht zu erreichen sind: ■

Erhöhung der Verfügbarkeit (was die wichtigste Zielsetzung der Einführung von Replikation allgemein war),

■

Konsistenz aller Kopien und

■

niedrige Kosten der Replikation.

Diese drei Forderungen bilden das Spannungsfeld des Zielkonflikts (vgl. Abbildung 4.1). Verfügbarkeit

Abb. 4.1: Zielkonflikt der Replikation

Zielkonflikt der Replikation

Konsistenz

Kosten

4.3 Zielkonflikt der Replikation

■ ■ ■

87

Konflikte

Um die Verfügbarkeit von Daten zu maximieren, kann Replikation eingesetzt werden. Mit der Anzahl der Replikationssenken steigt dabei aber auch die Menge der redundant gehaltenen Daten. Gleichzeitig wird die Anforderung gestellt, alle existierenden Kopien eines Datenelementes bei Änderungen konsistent zu halten. Es gilt aber auch: je weniger Kopien eines Datenelementes existieren, desto einfacher wird es, die Konsistenz zu bewahren. Das Bestreben, möglichst wenige Replikate zu generieren, um die Konsistenzsicherung zwischen diesen möglichst einfach zu gestalten, läuft dann aber der Forderung einer maximalen Verfügbarkeit entgegen (denn je mehr Kopien existieren, desto schwieriger wird es auch, die Konsistenz zu garantieren). Aus diesem Grunde kann es sinnvoll sein, die Forderung nach einer einfachen Konsistenzsicherung zugunsten einer erhöhten Verfügbarkeit von Daten aufzuweichen. Darüber hinaus ist ein weiteres Ziel, die anfallenden Kosten der Replikation möglichst niedrig zu halten. Diese Forderung ist allerdings nur dann zu erfüllen, wenn im Zuge einer Änderungsoperation relativ wenige Kopien aktualisiert werden müssen. Indirekt widerspricht die Forderung dann aber der Forderung nach einer hohen Verfügbarkeit, die ja durch besonders viele Kopien erreicht werden kann. Mit der ansteigenden Anzahl der Kopien ist auch der Aufwand, durchgeführte Änderungen an andere Kopien weiterzugeben, entsprechend groß. Alle drei Forderungen sind also gleichzeitig nicht zu erreichen, so dass nie verhindert werden kann, dass man sich bei der Annäherung an zwei der drei Ziele von dem jeweils dritten Ziel entfernt.

4.4 Klassische Replikations- und Synchronisationsverfahren Klassische Verfahren

88

■ ■ ■

In diesem Abschnitt werden die wichtigsten klassischen Replikations- und Synchronisationsverfahren (vgl. beispielsweise [Dad96, Hoe01, Dat95, Elm02], u. A.) kurz vorgestellt und in ihren Konzepten beschrieben. Dabei wird bewusst darauf verzichtet, immer von einem Replikations- oder einem Synchronisationsverfahren zu sprechen. Fast alle Verfahren weisen Merkmale beider Konzepte auf. Gleichzeitig wird geklärt, welche dieser klassischen Verfahren auch in mobilen Umgebungen eingesetzt werden können. Im nächsten Abschnitt 4.5 werden dann neue mobile Verfahren vorgestellt.

4 Replikation und Synchronisation

4.4.1 Konsistenzerhaltende Verfahren Konsistenzerhaltende Verfahren stellen die strikte Durchsetzung von Konsistenz innerhalb einer Replikationsumgebung als Primärziel in den Vordergrund. Dagegen wird das Ziel der hohen Verfügbarkeit von Daten vernachlässigt. Konsistenzerhaltende Verfahren werden in pessimistische und optimistische Verfahren unterteilt. Pessimistische Replikationsverfahren vermeiden durch Sperrverfahren von vorne herein mögliche Inkonsistenzen. Optimistische Verfahren dagegen gehen davon aus, dass Inkonsistenzen nur äußerst selten auftreten, verzichten deswegen auf Sperren, prüfen aber am Ende jeder Transaktion, ob Inkonsistenzen vorliegen (Validierungsphase). 4.4.1.1 Pessimistische Verfahren Pessimistische Verfahren vermeiden mögliche Inkonsistenzen durch den Einsatz von Sperrverfahren (genauer: dem 2-Phasen-CommitProtokoll). Dabei wird grundsätzlich unterschieden, ob innerhalb einer Änderungstransaktion gleichzeitig auch alle anderen Replikate parallel aktualisiert werden oder ob diese Aktualisierung asynchron mit Hilfe einer gesonderten UPDATE-Transaktion zu einem späteren Zeitpunkt nach Beendigung der eigentlichen Transaktion durchgeführt wird. Im ersten Fall spricht man von Eager Replication, im zweiten Fall von Lazy Replication. Der Vorteil asynchroner Strategien besteht darin, dass vor allem auf systemübergreifende Sperren verzichtet werden kann, was die Verfügbarkeit der Daten stark erhöht. Die Vorgehensweise, alle Replikate in einem einzigen Schritt zu aktualisieren, kommt bei den Read-One-Write-All-Verfahren (ROWA) zum Einsatz. Die alternative Vorgehensweise einer asynchronen Aktualisierung wird bei den Primary- und Quorum-Verfahren realisiert. ■

Einsatz von Sperrverfahren

Vorgestellte Verfahren

ROWA. Kernidee der ROWA-Verfahren ist die synchrone, das heisst parallele Aktualisierung von (n-1) Kopien innerhalb der gleichen Änderungstransaktion (Read-One-Write-All). Die ROWA-Verfahren garantieren somit, dass stets alle Kopien eines Replikats vollständig konsistent sind. Da während eines Aktualisierungsvorgangs alle zu aktualisierenden Kopien von einer Änderungstransaktion gesperrt werden, kann es darüber hinaus auch nicht dazu kommen, dass Lesetransaktionen veraltete oder

4.4 Klassische Replikations- und Synchronisationsverfahren

■ ■ ■

89

inkonsistente Daten lesen. ROWA ist somit an die Erreichbarkeit aller Kopien angewiesen. In mobilen Umgebungen ist der Einsatz des klassischen ROWA-Verfahrens nicht sinnvoll, da die zwingend notwendige Schreibverfügbarkeit für alle Kopien praktisch nicht realisiert werden kann. Mobile Clients sind die meiste Zeit im Disconnected Mode, was die Wahrscheinlichkeit, dass zu jedem Zeitpunkt stets alle mobilen Clients auch tatsächlich verfügbar sind, gegen Null gehen lässt. Doch auch für den Fall, dass nicht alle Kopien erreichbar sind, existieren Varianten der ROWA-Verfahren, die allerdings ebenfalls keine wirklich sinnvollen Lösungsansätze darstellen: ROWAVarianten

Zentralistisches Verfahren

90

■ ■ ■

■

■

Variante 1: Write-All-Available. Hier ist die Verfügbarkeit aller existierenden Kopien in einem speziellen Verzeichnis hinterlegt. Dieses Verzeichnis enthält somit zu jedem Zeitpunkt eine Liste aller aktuell verfügbaren, das heisst erreichbaren Kopien. Vor jedem Aktualisierungsvorgang wird dieses Verzeichnis konsultiert, um Auskunft über die Kopien zu erhalten, die im Rahmen der Änderungstransaktion ebenfalls geändert werden können. Ein Einsatz dieses Verfahrens kann in mobilen Umgebungen zwar erfolgen, in diesem Fall muss jedoch zu einem späteren Zeitpunkt eine zusätzliche, asynchrone Aktualisierung noch nicht erreichter Replikate erfolgen.

■

Variante 2: Missing-Update. Das Missing-Update-Verfahren definiert ein hybrides Verfahren. Dabei wird das klassische ROWA-Verfahren nur während eines fehlerfreien Normalbetriebs eingesetzt. Kommt es aber zu Fehlern, beispielsweise aufgrund einer plötzlichen Netzpartitionierung, wird in einen speziellen Fehlermodus gewechselt, der ein anderes, an die Fehlersituation angepasstes Verfahren verwendet (welches Verfahren dies genau ist, kann beliebig festgelegt werden). Der Einsatz von Missing-Update in mobilen Umgebungen ergibt allerdings keinen Sinn, da eine Netzpartitionierung quasi dauerhaft vorliegt und das einfache, im Normalfall durchgeführte ROWA sowieso nicht zum Einsatz kommt; das im Fehlerfall vorgesehene alternative Verfahren dagegen ständig.

Primary-Verfahren. Bei den Primary-Verfahren handelt es sich um stark zentralistisch ausgelegte Verfahren. Dazu wird das Prinzip der Gleichheit aller Kopien aufgegeben. Wird auf einer Kopie eine Änderungstransaktion durchgeführt, erfolgt die

4 Replikation und Synchronisation

Aktualisierung der anderen Kopien in zwei Schritten: Zunächst wird in einem ersten Schritt von der Änderungstransaktion eine als Masterkopie oder Primärkopie festgelegtes Replikat gesperrt. Auf dieser Primärkopie wird anschließend die Änderungstransaktion erneut durchgeführt und mit COMMIT beendet. Für die asynchrone Aktualisierung der anderen Kopien ist nun die Primärkopie, nicht mehr die eigentliche Änderungstransaktion zuständig. Im Vergleich zu den ROWA-Verfahren stellen die Primary-Verfahren eine Vereinfachung dar. Die Änderungstransaktion muss nicht mehr alle Replikate, sondern nur noch die Masterkopie sperren, damit die durchgeführten Änderungen an die anderen Replikate propagiert werden können.

■

Primary-Verfahren können mit Einschränkungen in mobilen Umgebungen eingesetzt werden. Es muss nur festgelegt werden, dass eine Primärkopie niemals auf einem mobilen Client, sondern immer auf einem stationären Knoten verfügbar ist. Kann diese Bedingung nicht erfüllt werden, sinkt die Verfügbarkeit der Primärkopie stark, was die Durchführung von Änderungstransaktionen extrem erschwert. Doch auch im Fall, dass eine stationäre Primärkopie verfügbar ist, muss für die Durchführung einer Änderungstransaktion stets eine Netzwerkverbindung zur Masterkopie aufgebaut werden. Ist am Standort eines mobilen Clients gerade kein drahtloser Zugriff auf die Primärkopie möglich, kann eine Änderungstransaktion auch nicht durchgeführt werden. Insbesondere für Anwendungen, die eine hohe Frequenz von UPDATE-Transaktionen aufweisen, sind die PrimaryVerfahren von Nachteil, da erstens der Knoten der PrimaryKopie zum Hot-Spot (Bottleneck) wird, und zweitens da die Wahrscheinlichkeit, dass für eine Änderungstransaktion keine Netzwerkverbindung aufgebaut werden kann, mit der Anzahl der Knoten (d.h. Clients) steigt. Ein speziell für den Einsatz in mobilen Umgebungen entwickeltes Verfahren ist das VirtualPrimary-Copy-Verfahren, das später noch vorgestellt wird und genau diese Problematik fokussiert

Einsatz in mobilen Umgebungen

Quorum-Verfahren. Bei den Quorum-Verfahren basiert die Aktualisierung von Kopien auf einer vorangegangenen Abstimmung. Jede Kopie besitzt eine bestimmte Anzahl von Stimmen (meistens 1). Um Änderungen durchzuführen, muss eine Transaktion eine festgelegte Mehrheit an Stimmen anderer Kopien für sich gewinnen. Die Stimme einer Kopie gilt als gewonnen, wenn die Kopie durch die Änderungstransaktion gesperrt werden kann. Andere Methoden, zu einem Abstim-

Abstimmungsverfahren

4.4 Klassische Replikations- und Synchronisationsverfahren

■ ■ ■

91

mungsergebnis zu gelangen, sind möglich. Der etwas unpräzise Begriff eines Quorum kann formal wie folgt definiert werden: Ein Quorum ist eine entscheidungsfähige Anzahl an Stimmen, die von einer Transaktion vor einer Änderung einer Kopie angefordert werden muss. Dabei wird zwischen einem Lese- und Schreibquorum unterschieden. Nur wenn eine Transaktion die Mehrheit der Stimmen (Majority Consensus) gewinnt, dürfen die Änderungen vorgenommen werden. Welche Stimmenanzahl einer Mehrheit entspricht, kann beliebig definiert werden. Ein einfaches Verfahren ist es beispielsweise, bei n Kopien ein Schreibquorum von QW • (n/2) + 1 falls n gerade und QW • (n+1)/2 falls n ungerade. Für QR kann dann QR = n – QW +1 gesetzt werden. Allgemein müssen folgenden beiden Bedingungen erfüllt sein: ■

Die Summe aus Schreibquorum und Lesequorum muss größer als die Gesamtzahl an Stimmen n sein, das heisst QW + QR > n. Dadurch wird konkurrierendes Lesen und Schreiben verhindert.

■

Das Doppelte des Schreibquorums ist größer als die Gesamtsumme der Stimmen, das heisst 2 * QW > n. Dadurch wird konkurrierendes Mehrfachschreiben verhindert.

Der Extremfall: QW = n und QR = 1 entspricht wieder dem ROWA-Verfahren. QuorumVarianten

Bei Quorum-Verfahren wird darüber hinaus unterschieden, ob alle an einer Abstimmung beteiligten Kopien gleichberechtigt (ungewichtete Stimmen) sind oder ob bestimmte Kopien höhere Stimmengewichte als anderen Kopien zugeordnet (gewichtete Stimmen) werden. Werden die Mehrheiten fest vorgegeben, spricht man von statischen Quorum-Verfahren, können sie dynamisch zur Laufzeit angepasst werden, spricht man von dynamischen Quorum-Verfahren (zum Beispiel aufgrund der zum Abstimmungszeitpunkt verfügbaren Gesamtstimmen).

Abstimmung

Quorum-Verfahren eigenen sich, wie schon die PrimaryVerfahren, nur bedingt für einen Einsatz in mobilen Umgebungen. Ähnlich wie bei den zuvor vorgestellten Primary-Verfahren setzt auch dieses Verfahren für die Durchführung einer Änderungstransaktion den Aufbau einer Netzwerkverbindung zu einer Basisstation voraus. Diese ist dann für das Einholen des Quorums der anderen Kopien verantwortlich. Zudem kann davon ausgegangen werden, dass sich relevante Kopien auf anderen mobilen Knoten befinden, weswegen auch nicht garantiert werden kann, dass die Basisstation die Stimmen solcher Kopien

92

■ ■ ■

4 Replikation und Synchronisation

einholen kann. In mobilen Umgebungen wird aber immer die Schwierigkeit bestehen, ein erforderliches Quorum auch tatsächlich zu erreichen, da mit hoher Wahrscheinlichkeit nicht alle Kopien in eine Abstimmung mit einbezogen werden können. Den pessimistischen, konsistenzerhaltenden Verfahren, stehen die optimistischen Verfahren gegenüber, die davon ausgehen, dass Konflikte eher unwahrscheinlich sind bzw. dass auftretende Konflikte nachträglich erkannt und behoben werden können. 4.4.1.2 Optimistische Verfahren Optimistische Replikations- und Synchronisationsverfahren erlauben es, Änderungen auf einer Kopie vorzunehmen, ohne die durchgeführten Operationen sofort auf allen anderen Kopien nachzuvollziehen. Die Propagierung durchgeführter Änderungen erfolgt also asynchron. Dadurch kann es bei der späteren Wiedereinbringung zu Synchronisationskonflikten kommen. Stellt sich bei der Reintegration von Änderungen in die zentrale Datenbank beispielsweise heraus, dass die durchgeführten Änderungen auf einem (zum Zeitpunkt der Änderung) nicht mehr aktuellen Datenbestand ausgeführt wurden (was beispielsweise durch einen Vergleich von Zeitstempeln feststellbar ist), kommt es zu einem Konflikt. Erkannte Konflikte müssen aufgelöst werden, um die globale Konsistenz des Systems nicht zu gefährden. Um Konflikte erkennen und behandeln, das heisst auflösen zu können, machen sich optimistische Verfahren häufig semantisches Wissen zunutze. Solche semantischen Verfahren sind beispielsweise summierende Verfahren, regelbasierte Prioritätsverfahren oder „neueste Info zählt“-Verfahren. Andernfalls bleibt nur das Rücksetzen einer der Änderungen (meist der jüngeren). Die wichtigsten Vertreter optimistischer Verfahren sind die LogTransformation und das Data-Patch-Verfahren: ■

Verzicht auf Sperren

Log-Transformation. Im Zuge der Log-Transformation werden die auf einer Kopie durchgeführten Änderungen zunächst auf der zentralen Datenbank, danach asynchron auf allen anderen Kopien nachgezogen. Auf Kopien kann somit stets lokal gearbeitet werden. Inkonsistenzen während eines Synchronisationsprozesses müssen erkannt werden und führen zu einem sofortigen Rücksetzen der betroffenen Transaktion. Die Rücksetzung und eine spätere Neuausführung einer Transaktion werden anhand protokollierter Logbuch-Einträge über die lokal ausgeführten Operationen vorgenommen. Der Nachteil dieses Verfahrens liegt, trotz der Existenz von Minimierungsregeln für die

4.4 Klassische Replikations- und Synchronisationsverfahren

■ ■ ■

93

Protokollierung, in den umfangreichen Logging-Mechanismen und dem ineffizienten und gegebenenfalls auch kaskadierenden Zurücksetzen kompletter Transaktionen. Der Vorteil liegt in der einfachen Auflösung von Konflikten. ■

Data-Patch-Verfahren. Das Data-Patch-Verfahren vermeidet das Zurücksetzen von Transaktionen durch bereits beim Datenbankentwurf festgelegte, anwendungsbezogene Regeln. Die anwendungsbezogenen Regeln geben vor, auf welche Weise aus zwei verschiedenen Versionen eines Replikats ein neuer, einheitlicher und konsistenter Zustand generiert werden kann. Bei anwendungsbezogenen Regeln wird zwischen zwei verschiedenen Klassen von Regeln unterschieden. Einfügeregeln definieren Regeln für Tupel, die in eine Relation eingefügt werden. Integrationsregeln definieren Regeln für Tupel, die geändert werden. Das Data-Patch-Verfahren ist ein Beispiel eines Verfahren, dass aufgrund seiner Eigenschaften sowohl den konsistenzerhaltenden, als auch den im nächsten Abschnitt behandelten verfügbarkeitserhaltenden Verfahren zugeordnet werden kann. DataPatch-Verfahren können in mobilen Umgebungen eingesetzt werden.

Nachdem nun einige wichtige konsistenzerhaltende Verfahren diskutiert wurden, wird nachfolgend auf die zweite grosse Klasse an Verfahren, die verfügbarkeitserhaltenden Verfahren eingegangen.

4.4.2 Verfügbarkeitserhaltende Verfahren Erhöhung der Verfügbarkeit

94

■ ■ ■

Konsistenzerhaltende Verfahren schränken aufgrund des hohen Stellenwerts der Datenkonsistenz die (Lese-)Verfügbarkeit der Daten stark ein. Ein System ist solange nicht für Lese- und Schreibzugriffe verfügbar, wie Konsistenzsicherungs- oder Konfliktbehebungsmaßnahmen ausgeführt werden. Im Gegensatz zu den konsistenzerhaltenden Verfahren haben verfügbarkeitserhaltende Verfahren (schwache Konsistenzmodelle) die Zielsetzung einer höheren Verfügbarkeit von Daten. Dies wird dadurch erreicht, dass Inkonsistenzen in bestimmten Situationen zugelassen werden. Verfügbarkeitserhaltende Verfahren tolerieren auftretende Inkonsistenzen allerdings nur innerhalb gewisser, dynamisch bestimmbarer Grenzen. Werden Konflikte erkannt, müssen diese selbstverständlich in geeigneter Weise gelöst werden, zum Beispiel durch semantische Verfahren (wie zum Beispiel summierende Verfahren, regelbasierte Pri-

4 Replikation und Synchronisation

oritätsverfahren oder „neueste Info zählt“-Verfahren) oder durch Rücksetzen. Werden keine Abweichungen toleriert, kann wieder von konsistenzerhaltenden Verfahren gesprochen werden. Verfügbarkeitserhaltende Verfahren sind eine Variante optimistischer Verfahren. Beispiele verfügbarkeitserhaltender Verfahren sind die EpsilonSerialisierbarkeit und das Quasi-Copy-Verfahren: ■

Epsilon-Serialisierbarkeit. Dieses Verfahren definiert ein Konsistenzmodell, bei dem mit Epsilon ein globaler (beliebig definierbarer) Faktor existiert, der eine tolerierbare Abweichung von Replikaten gegenüber einem bestimmten Konsistenzzustand festlegt (jedes Replikat dokumentiert selbst die eigene individuelle Abweichung von diesem globalen Epsilon-Faktor). Unter Berücksichtigung des durch den Epsilon-Faktor definierten Toleranzbereiches wird eine überlappte Ausführung von Transaktionen mit Lesezugriff auf eigentlich inkonsistente Replikate gestattet. Dadurch kann die Verfügbarkeit der Daten wesentlich erhöht werden. Eine solche Ausführung ist dabei nur dann erlaubt, wenn die individuelle Abweichung eines Replikats geringer als die durch den globalen Epsilon-Faktor bestimmte Toleranzgrenze ist.

■

Quasi-Copy-Verfahren. Dieses Verfahren basiert auf einem ähnlichen Prinzip, wie die Epsilon-Serialisierbarkeit. Die tolerierbare Inkonsistenz, innerhalb deren Grenzen direkte Lesetransaktionen erlaubt sind, wird hier über die Anzahl lokal erlaubter Änderungen auf einer Kopie oder über die fest vorgegebene Zeitspanne zwischen Updatetransaktionen bestimmt.

4.4.3 Data Caching Eng mit Replikation verbunden sind auch verschiedene Varianten des Cachings von Daten. Ein Cache ist ein schneller Zwischenspeicher, der zwischen dem Primärspeicher, also dem Arbeitsspeicher, und den Prozessorregistern eingefügt wird. Caches halten Daten des Primärspeichers redundant vor. Durch die hohe Verarbeitungsgeschwindigkeit eines Caches gelingt es, den Zugriff auf Daten stark zu beschleunigen, da der „langsame“ Zugriff auf den Primärspeicher vermieden wird. Dazu müssen allerdings die gewünschten Daten bereits im Cache eingelagert sein. Das Ziel ist es deshalb, Daten möglichst vorausschauend im Cache einzulagern, so dass bei Datenzugriffen die Wahrscheinlichkeit hoch ist, dass auf den schnellen

4.4 Klassische Replikations- und Synchronisationsverfahren

Caches

■ ■ ■

95

Caches in mobilen Umgebungen

Semantisches Cachen

Cache und nicht auf den langsameren Arbeitsspeicher zugegriffen werden muss. Dadurch kann die durchschnittliche Antwortzeit des Systems erheblich verkürzt werden. Bei einer Aktualisierung eines Speicherwerts durch einen Synchronisationsvorgang muss zusätzlich auch die Cache-Kohärenz sichergestellt werden, das heisst dass auch nach dem Datenabgleich auf dem Sekundärspeicher nicht noch alte Cache-Inhalte weiterverwendet werden dürfen. Bei einem Cache handelt es sich um einen höchst dynamischen Speicher mit einer hohen Aktualisierungsrate bezüglich dem Einlagern neuer und dem Verdrängen alter Daten. Mittlerweile existieren viele verschiedene Strategien, um die Aktualisierungen eines Caches möglichst intelligent durchzuführen. Auch in mobilen Umgebungen müssen die auf mobilen Clients verwendeten Caches regelmäßig aktualisiert werden. Aktualisierungen der im Cache eingelagerten Daten müssen zeitabhängig (bei Server-Updates) oder ortsabhängig (bei Standortveränderungen mobiler Nutzer) durchgeführt werden. Die intelligente Auswahl der einzulagernden Daten (dieser Vorgang wird auch als Prefetching bezeichnet) ist dabei von entscheidender Bedeutung, ja sogar zwingend erforderlich, da Caches für gewöhnlich sehr klein sind. Eine weitere Variante ist das semantische Cachen von Daten (Semantic Caching). Dabei wird zusammen mit den eigentlichen Anwendungsdaten eine Beschreibung der Daten gespeichert. Anhand dieser zusätzlichen Informationen können intelligente Einlagerungsstrategien implementiert werden. Mit der Menge der verwendeten semantischen Informationen steigt aber auch der Speicherplatzbedarf stark an.

4.4.4 Data Hoarding Eine besondere Variante des intelligenten Prefetchings bei Caches, das speziell für mobile Umgebungen konzipiert wurde, ist das Data Hoarding [Kue97, Kub00, Kub01]. Dabei erfolgt jeglicher Datenaustausch zwischen Server und Client nur an speziellen Infostationen. Infostationen sind mit WLAN ausgestattete Terminals, die untereinander über ein Hochgeschwindigkeitsnetzwerk verbunden sind. Eingesetzt wird Data Hoarding in mobilen Umgebungen vor allem dann, wenn potentielle Nutzer keine eigenen mobilen Clients nutzen, sondern dass stattdessen ein anwendungsspezifischer Client ausgegeben wird. Man denke an ein Museum, das an seine Besucher museumseigene PDAs ausgibt, um über diese interaktive, standort-

96

■ ■ ■

4 Replikation und Synchronisation

abhängige Museumstouren sowie Kunst- und Gemäldeinformationen anzubieten. Ein spezieller Proxy-Server koordiniert sämtliche HoardingProzesse, die in ihrem Ablauf wie folgt beschrieben werden können: ■

Schritt 1: Drahtloser Download der wahrscheinlich benötigten Information an einer Infostation auf den Client (Prefetching),

■

Schritt 2: Trennung der drahtlosen Verbindung zur Infostation, Client arbeitet autonom

■

Schritt 3: Gelegentliche Übertragung des protokollierten Nutzerverhaltens an erreichbare Infostationen. Bei Bedarf können diese dann anhand der erhaltenen Informationen neue, anwenderspezifische Daten auf den Client replizieren. Betriebssystem

Traditionelle Speicherarchitektur

Dateisystem

Funktionsweise

Abb.4.2: Speicherarchitekturen mobiler Clients

Flash Speicher

Betriebssystem

Hoardingbasiertes Dateisystem

Flash-Speicher (Hoarding Cache)

Hoardingbasierte Speicherarchitektur

Harddisk (Primärspeicher)

4.4.5 Verzicht auf Replikation In mobilen Umgebungen ist es nur in Einzelfällen sinnvoll, auf Replikation zu verzichten. Dann nämlich, wenn auf eine zuverlässige und hochverfügbare Infrastruktur drahtloser Netzwerktechnologien (beispielsweise in Form eines leistungsstarken WLAN) in einem geographisch begrenzten Gebiet zurückgegriffen werden kann.

4.4 Klassische Replikations- und Synchronisationsverfahren

Hochverfügbare, drahtlose Funknetze

■ ■ ■

97

Ein typisches Beispiel ist ein firmeninternes, gegenüber externen Nutzern abgeschottetes drahtloses Netzwerk. In einem solchen Szenario kann es unter Umständen tatsächlich einfacher sein, sämtliche Daten zentral zu halten und lediglich eine Schnittstelle für einen drahtlosen Online-Zugriff anzubieten, als eine aufwendige Replikation und Synchronisation zu implementieren, wie es bei OfflineSzenarien notwendig ist.

4.5 Neue mobile Verfahren Anforderungen in mobilen Umgebungen

Neue Anforderungen an Verfahren für einen Einsatz in mobilen Umgebungen betreffen vor allem die Kopie-Update-Strategien. Dabei kann davon ausgegangen werden, dass in mobilen Umgebungen gerade die pessimistischen Verfahren nicht oder nur sehr eingeschränkt eingesetzt werden können, da diese zumeist auf dem Einsatz von Sperren basieren. Auf mobilen Clients kann es allerdings sehr kritisch sein, lokale Sperren zu setzen, da solche Sperren im Falle des Wechsels eines mobiles Clients in den Disconnected Mode unverhältnismäßig lang bestehen bleiben können. Grundlage der Replikation in mobilen Umgebungen sind sinnvollerweise also die optimistischen Verfahren sein. Trotzdem wurden auch pessimistische Verfahren für einen Einsatz in mobilen Umgebungen entwickelt. Ein Beispiel ist das nachfolgend zunächst präsentierte Virtual-Primary-Copy-Verfahren.

4.5.1 Virtual-Primary-Copy

Kernidee

98

■ ■ ■

Das Verfahren Virtual-Primary-Copy ist eine Erweiterung der bereits vorgestellten Primary-Copy-Verfahren. Es basiert auf den konsistenzerhaltenden, pessimistischen Verfahren, das heisst Inkonsistenzen zwischen verschiedenen Kopien eines Datenelements werden nicht toleriert. Die Verfügbarkeit rückt somit in den Hintergrund. Kernidee dieses Verfahrens ist die Forderung, dass sich die Primärkopie eines Replikats – entgegen der Vorgehensweise bei den klassischen Primary-Verfahren – immer auf einem mobilen Client befindet. Da Masterkopien auf mobilen Clients aber sehr häufig nicht erreichbar sind (nämlich immer dann, wenn sich der entsprechende Client im Disconnected Mode befindet), kann sich die Durchführung von Änderungstransaktionen als schwierig erweisen. Zwar kann der Client, der die Masterkopie vorhält, selbst uneinge-

4 Replikation und Synchronisation

schränkt auf dieser arbeiten, doch sind dann alle anderen Kopien bezüglich Änderungen blockiert, solange sie nicht eine Netzwerkverbindung zu diesem Client aufbauen können. Um diese Problematik zu entschärfen, das heisst um die mobilen Clients von der Verfügbarkeit der Masterkopie zu entkoppeln, wird zu jeder realen Masterkopie auf einem Client eine virtuelle Primärkopie generiert. Ist die reguläre Primärkopie auf dem Client nicht verfügbar, übernimmt die „virtuelle“ Kopie gegenüber allen anderen Replikaten und den auf diesen ausgeführten Änderungstransaktionen die Rolle der Primärkopie (auf der dann sowohl Lese- als auch Schreibtransaktionen möglich sind). Später muss allerdings ein Abgleich beider Kopien, das heisst der regulären und der virtuellen Primärkopie erfolgen. An die virtuelle Kopie wird nur die Forderung gestellt, dass sich diese physisch irgendwo im Festnetz befindet. Wo genau, kann frei gewählt werden.

Verfügbarkeit der Masterkopie

4.5.2 Snapshot-Verfahren Ein sehr gut in mobilen Umgebungen einsetzbares Verfahren ist das Snapshot-Verfahren. Snapshots sind materialisierte Sichten nichtlokaler Datenbestände. Jeder Snapshot basiert auf einer Originaltabelle, die auch als Mastertabelle oder Mastersicht bezeichnet wird. Snapshots können von verschiedener Granularität sein, von einzelnen Tupeln, bis hin zu kompletten Relationen. Replikationsquelle ist eine zentrale Datenbank, mobile Clients sind die Replikationssenken. Replikationsserver werden als Master-Sites, die mobilen Clients als Snapshot-Sites bezeichnet. Die Kommunikation zwischen einer Replikationsquelle und einer Replikationssenke kann verbindungsbasiert (synchron) oder dateibasiert (asynchron) erfolgen. Synchronisation kann als Abgleich von Snapshots verstanden werden. 4.5.2.1 Publish & Subscribe Eine snapshotbasierte Replikation basiert oft auf einem Publish & Subscribe-Modell. Dabei werden Publikationen erzeugt, die selbst wiederum aus einer Menge von Publikationsartikeln bestehen. Publikationsartikel sind nichts anderes als Snapshots beliebiger Granularität. Einzelne Publikationsartikel werden beispielsweise durch SQLAnweisungen definiert und dann zu größeren logischen Einheiten, den Publikationen zusammengefasst.

4.5 Neue mobile Verfahren

Master-Sites, Snapshot-Sites

Publikationen, Publikationsartikel

■ ■ ■

99

Subskriptionen

OfflineSzenarien

Die Zuordnung von Publikationen zu bestimmten mobilen Clients erfolgt anhand von Subskriptionen, die bei Bedarf auch parametrisiert sein können (beispielsweise kann ein Platzhalter für verschiedene mobile Clients gesetzt werden). Die Subskriptionen sind es somit, die die Zuordnung von der Replikationsquelle zu den Replikationssenken bestimmen. 4.5.2.2 Einfache vs. Komplexe Snapshots Analog dem View-Update-Problem bei relationalen Datenbanken kann auch bei Snapshots zwischen einfachen und komplexen Snapshots unterschieden werden. Einfache Snapshots basieren auf einer einzelnen Tabelle und zwischen der Originaltabelle (der Replikationsquelle) und jedem und auf einen mobilen Client replizierten Snapshot muss eine bijektive Abbildung existieren. Nur durch die bijektive Abbildung können die durchgeführten Änderungen bei der Synchronisation korrekt nachvollzogen werden. Komplexe Snapshots entsprechen komplexen Sichten, das heisst sie können sich auf mehrere Tabellen, aber auch auf andere, bereits existierende Snapshots beziehen, die auf der aktuellen Replikationsquelle verfügbar sind. Für komplexe Snapshots ist keine Reintegration auf der Replikationsquelle im Rahmen eines Synchronisationsprozesses möglich, weswegen auf sie auf den mobilen Clients auch nur lesend zugegriffen werden darf. Snapshots unterstützen den Disconnected Mode mobiler Clients, das heisst auf einfachen Snapshots können auch während einer Offline-Phase beliebige Updateoperationen ausgeführt werden. Im Zuge der Synchronisation müssen die durchgeführten Änderungen wieder mit der zentralen Datenbank abgeglichen werden. Dabei können Synchronisationskonflikten auftreten, die erkannt und durch adäquate Konfliktauflösungsroutinen aufgelöst werden müssen (vgl. Kapitel 9.2).

4.5.3 Nutzerdefinierte Replikation Interaktive Informationssysteme

100

■ ■ ■

Der in diesem Abschnitt vorgestellte Ansatz der nutzerdefinierten Replikation [Gol03] behandelt die Replikation von relationalen Datenbankinhalten in interaktiven Informationssystemen. Ziel ist eine anwendungsgesteuerte, dynamische Auswahl von Replikaten. Um eine solche dynamische Auswahl treffen zu können, werden an SQL angelehnte, deskriptive Schnittstellen angeboten, über die auch die Replikationsdefinition (vgl. Abschnitt 4.1) erfolgen kann. Als

4 Replikation und Synchronisation

Einsatzmöglichkeiten dieses Verfahrens wird vor allem die Realisierung neuer mobiler Datenbankanwendungen (beispielsweise von adaptiven Reiseinformationssystemen) genannt. 4.5.3.1 Architektur In [Gol00] wird vorgeschlagen, klassische Client/Server-Architekturen um spezielle Replikationsserver (Replication Proxy Server) zu erweitern, die den Datenbankserver von der Koordination von Replikation und Synchronisation entlasten und entkoppeln. Die nutzerdefinierte Replikation basiert auf einer 3-stufigen Architektur (vgl. Abbildung 4.3). Von einer mobilen Einheit respektive einem Nutzer initialisierte Replikationsanforderungen werden über einen oder mehrere zwischengeschaltete Replikationsserver (Replication Proxy Server) an einen zentralen Datenbankserver übermittelt. Jeder Replikationsserver hält eine Kopie der Daten des Datenbankservers in Form konsolidierter Tabellen vor und hat zwei Aufgaben: einerseits ist er für die Pflege von Daten- und Schemaelementen zuständig, andererseits muss er bestimmen, welche Datenund Schemaelemente, unter Berücksichtigung der bereits replizierten Daten, denn überhaupt noch repliziert werden müssen. Wie üblich wird von einem dreistufigen Arbeitsmodell ausgegangen. Während einer Online-Phase werden Daten auf einen mobilen Client repliziert (Phase 1), um das unabhängige Arbeiten auf diesen Daten nach Beendigung der Netzwerkverbindung möglich zu machen (Phase 2). Später müssen auf einer mobilen Datenbank vorgenommene Änderungen auch wieder mit der konsolidierten Datenbank synchronisiert werden (Phase 3). Da Replikation und Synchronisation erhebliche Last verursachen, die die Skalierbarkeit des Datenbankservers beeinflusst, ist der Einsatz von Replikationsservern sinnvoll. Skalierbarkeit bezieht sich hier also auf die Datenbankzugriffe einer größer werdenden Anzahl von Clients. Zusätzlich zu den Transaktionen mobiler Clients muss ein Datenbankserver oft auch Transaktionen stationärer Clients ausführen. Muss zusätzlich noch die Koordination von Replikation und Synchronisation durch den Datenbankserver übernommen werden, entsteht weitere Last auf der Serverseite. Durch den Einsatz spezieller Replikationsserver, die im Festnetz der Backend-Datenbank vorgeschaltet sind, können die Lastspitzen vom Datenbankserver weg verteilt werden. Replikationsserver können auf eigenständigen Hosts, aber auch als ergänzende Komponente auf bestehenden Hosts (beispielsweise als Bestandteil der Basisstationen) realisiert werden.

4.5 Neue mobile Verfahren

3-stufige Architektur

Arbeitsmodell

Skalierbarkeit

Lastspitzen

■ ■ ■

101

Mobiler Client Anwendung

Abb. 4.3: Architektur [nach Gol03]

Replikationsserver

Quellserver

Daten und Updates

DBMS Dienstaufrufe

DBMS

DBMS

Kommunikation zu anderen RPS

Der Datenaustausch zwischen mobilen oder stationären Clients kann dabei ausschließlich indirekt, das heisst über den Umweg des Datenbankservers oder zumindest eines Replikationsservers erfolgen. Die direkte Kommunikation zwischen Clients ist im Normalfall nicht möglich. Weitere Kommunikationskosteneinsparungen und Performanzvorteile können durch eine Hierarchie von Replikationsservern erreicht werden. Jede neue Hierarchiestufe führt zu einer Aufspaltung der Replikate der vorherigen Hierarchiestufe. Die Aufteilung kann, muss aber nicht disjunkt erfolgen.

Neue mobile Datenbankanwendungen

Interaktive Anwendungen

102

■ ■ ■

4.5.3.2 Anforderungen und Ablauf Bis heute fokussieren kommerzielle mobile Datenbanklösungen – wie sie später in Kapitel 9 vorgestellt werden – vor allem auf traditionelle Szenarien mobiler Datenverarbeitung, wie beispielsweise den Zugriff auf einen gemeinsam genutzten Informationspool. Neue mobile Datenbankanwendungen nutzen dagegen verstärkt Location Based Services (LBS), die es erlauben, eine mobile Einheit abhängig von Aufenthaltsort oder Tätigkeitsgebiet mit kontextspezifischen Informationen zu versorgen. Darüber hinaus sollen Nutzer nicht nur auf bereits existierende Daten zugreifen können, sondern in Form einer interaktiven Pflege auch selbst für die Aktualisierung und Ergänzung verfügbarer Informationen sorgen. Dazu müssen sie das Recht besitzen, Änderungen bestehender Daten vorzunehmen und neue Daten in die gemeinsam genutzte Datenbank einzubringen. In [Gol03] wird in diesem Zusammenhang auf die Konzeption des datenbankbasierten, interaktiven Reiseinformationssystems HERMES verwiesen. Dieses soll Nutzern eine individuelle Reiseplanung ermöglichen und ihnen dazu ortsabhängige Dienstleistungen anbieten. Dabei wird eine starke Interaktion der Nutzer mit der zentralen Datenbank vorausgesetzt. Die zentrale Datenbank stellt standardmäßig nur die Basisinformationen bereit, für die Ergänzung

4 Replikation und Synchronisation

zusätzlicher, detaillierter Informationen sind dann die Nutzer verantwortlich. Das HERMES-System kann somit als „Reiseinformationssystem von Nutzern für Nutzer“ charakterisiert werden. Zentrale Kernforderung ist ein Dienst, mittels dessen eine mobile Anwendung in die Lage versetzt wird, Daten dynamisch zur Laufzeit, abhängig von Zeit und Ort für eine Replikation auszuwählen, um eine fortgesetzte Ausführung lokaler Transaktionen im Disconnected Mode zu realisieren. Ein solcher Dienst wird als nutzerdefinierte Replikation bezeichnet. Die speziellen Anforderungen an die Implementierung einer solchen mobilen Anwendung können anhand von 5 Punkten beschrieben werden: ■

Replikation. Eine mobile Anwendung muss dazu in der Lage sein, nach den spezifischen Vorgaben eines Nutzers relevante Daten einer zentralen Datenbank lokal zu replizieren. Dies muss insbesondere auch zur Laufzeit möglich sein.

■

Replikationseffizienz. Bereits lokal vorhandene, noch aktuelle Daten sollen nicht erneut repliziert werden.

■

Speicherplatzbeschränkung. Reicht der auf einem mobilen Client verfügbare Speicherplatz für die Replikation neuer, zusätzlicher Daten nicht aus, müssen bereits replizierte Daten, die nicht mehr relevant sind, gelöscht werden.

■

Zugriff. Um Operationen auf replizierten Daten zu ermöglichen, muss jeder Nutzer über die dazu notwendigen Änderungsund Einfügerechte verfügen.

■

Konsistenz. Da auf replizierten Daten Änderungen vorgenommen werden können, müssen Routinen für eine automatische Konflikterkennung und -behandlung implementiert werden, um die Konsistenz der Daten zu garantieren.

Anforderungen

Die genannten Punkte beschreiben abstrakte Anforderungen an eine Implementierung des Konzepts der nutzerdefinierten Replikation. Weitere konkretere Punkte sind (an einer prototypischen Implementierung wird nach [Gol03] noch gearbeitet): es muss eine Schnittstelle implementiert werden, die Anwendungen (speziell zur Laufzeit) die dynamische Replikation von Daten gestattet, unabhängig von Ort oder Zeit. Replikate müssen zudem auch mit Zusicherungen (beispielsweise einem garantierten Einfügerecht) ergänzt werden. Deskriptive, an SQL angelehnte Konstrukte erlauben eine einfache Konzeption dieser Schnittstelle. Der Abgleich der Daten zwischen Replikationsserver und Quellserver erfolgt asynchron. Zusammenfassend lässt sich sagen, dass

4.5 Neue mobile Verfahren

■ ■ ■

103

das Primärziel der Einführung der Replikationsserver die Entkopplung mobiler Nutzer vom Quellserver ist.

4.6 Synchronization Markup Language (SyncML) Grundlagen

Zielsetzung

Architektur des SyncMLFrameworks

Mit der Synchronization Markup Language (SyncML) existiert eine Spezifikation, die eine herstellerunabhängige Technologie für den Abgleich bzw. die Synchronisation von Daten in einem (mobilen) Client/Server-Szenario definiert. Der weitere Standardisierungsprozesses obliegt mittlerweile der Open Mobile Alliance9, in der das ursprüngliche SyncML-Herstellerkonsortium (unter anderem Nokia, IBM, Panasonic, Ericsson, Motorola, …) aufgegangen ist. Eine erste Aufgabe bei der Entwicklung von SyncML bestand in der Definition eines plattformunabhängigen Datenformates der zu übertragenden Synchronisationsnachrichten. Letztlich wurde die Entscheidung getroffen, kein neues Datenformat zu definieren, sondern auf XML zurückzugreifen. Das zweite Problem der Abhängigkeit von spezifischen Netzwerkprotokollen wurde dadurch umgangen, dass der physikalische Transport der Daten in der SyncML-Spezifikation ausgeklammert wurde. Welches Transportprotokoll benutzt wird, hängt von der jeweiligen Implementierung ab. Ein bekannter SyncML-Client ist der Nokia Communicator 9210. Demgegenüber existiert mittlerweile auch eine ganze Reihe an Server-Produkten, die SyncML ebenfalls unterstützen und dadurch den Aufbau geräte- und plattformunabhängiger Synchronisationsarchitekturen erlauben. Ziel von SyncML ist es, eine einfach zu nutzende Möglichkeit zu schaffen, sämtliche in einer bestimmten Umgebung anfallenden Synchronisationsaufgaben über einen einzigen Mechanismus abzuwickeln, anstatt für jede Anwendung einen eigenen Synchronisationsmechanismus zu implementieren. SyncML führt dazu, dass alle an einem Synchronisationsprozess beteiligten Instanzen (Hersteller, Anwendungsentwickler, …) nur mehr eine einzige Spezifikation implementieren müssen, um eine Vielzahl an Anwendungen, Netzwerkinfrastrukturen und Dienste integrieren zu können. Das SyncML-Framework besteht aus verschiedenen Komponenten, wobei die wichtigsten Bestandteile die zwei Subprotokolle SyncML Sync Protocol und SyncML Representation Protocol sind. Während das erste Protokoll dazu dient, die an einem Synchronisati9

104

■ ■ ■

http://www.openmobilealliance.org/syncml/

4 Replikation und Synchronisation

onsvorgang beteiligten Parteien zu koordinieren und eine gemeinsame Kommunikationsgrundlage definiert, spezifiziert das zweite Protokoll, auf welche Weise die zu transportierenden Daten kodiert werden und welche Grundszenarien einer Datensynchronisation existieren. Im Normalfall geht die Initiative zu einem Synchronisationsvorgang von einem Client aus.

4.6.1 Synchronisationsszenarien Es werden sieben Synchronisationsszenarien unterschieden: ■

Zwei-Wege-Synchronisation. Diese Form der Synchronisation wird auch als bidirektionale Synchronisation bezeichnet. Client und Server teilen sich nacheinander gegenseitig alle seit dem letzten Synchronisationsvorgang angefallenen Änderungen mit.

■

Langsame Synchronisation. Dieses Szenario basiert darauf, dass ein Client bei ihm durchgeführte Änderungen an den Server übermittelt und dieser die empfangenen Änderungen feldweise mit seinem eigenen Datenbestand vergleicht. Dies benötigt einige Zeit, wodurch auch der Name zu erklären ist.

■

Einweg-Synchronisation (Client). Der Client übermittelt alle seit dem letzten Synchronisationsvorgang angefallenen Änderungen an den Server. Eventuelle Änderungen auf dem Server werden ohne Nachfrage überschrieben.

■

Erneuerungs-Synchronisation (Client). Der Client überträgt seinen gesamten Datenbestand an den Server, dessen Datenbestand vollkommen überschrieben wird.

■

Einweg-Synchronisation (Server). Der Server übermittelt alle seit dem letzten Synchronisationsvorgang angefallenen Änderungen an den Client. Eventuelle Änderungen auf dem Client werden ohne Nachfrage überschrieben.

■

Erneuerungs-Synchronisation (Client). Der Server überträgt seinen gesamten Datenbestand an den Client, dessen Datenbestand vollkommen überschrieben wird.

■

Serverinitiierte Synchronisation. Dieser Synchronisationstyp beschreibt einen Synchronisationsvorgang auf einer generischen Ebene. Dabei stellt der Server lediglich die Forderung an den Client, einen Synchronisationsvorgang, der einen der ersten sechs Typen besitzt, zu initialisieren.

4.6 Synchronization Markup Language (SyncML)

■ ■ ■

105

Logging

Anwendung

SyncEngine

Anwendung

SyncServer Agent

SyncClient Agent

SyncMLInterface

Abbildung 4.4: SyncMLFramework

Um Daten mit SyncML synchronisieren zu können, müssen die Daten einige Anforderungen erfüllen, beispielsweise die Separierung einzelner Datensätze. Darüber hinaus muss jeder Datensatz eindeutig identifizierbar sein. Identifikatoren werden serverseitig als Global Unique Identifier (GUID), clientseitig dagegen als Local Unique Identifier (LUID) bezeichnet. Werden für einen Datensatz auf Server und Client verschiedene Identifikatoren verwendet, muss der Server eine korrekte Zuordnung vornehmen können (beispielsweise anhand von Mapping-Dateien). Datenänderungen werden stets in Logdateien protokolliert. Diese Logdateien sind dann die Grundlage späterer Synchronisationsvorgänge. Als Transportprotokolle für Synchronisationsnachrichten können HTTP, aber auch andere Kommunikationsprotokolle wie das Infrarot-Protokoll Object Exchange Protocol (OBEX) (vgl. IrDA in Abschnitt 2.3.3.2) verwendet werden.

SyncMLAdapter

SyncML XML-Objekte

SyncMLAdapter

SyncMLInterface

Anforderungen an zu synchronisierende Daten

Transport (z.B. HTTP)

Synchronisationsprotokolle

106

■ ■ ■

Das zugehörige Framework (vgl. Abbildung 4.4) mit seinen Komponenten sieht wie folgt aus: um Daten synchronisieren zu können, müssen die an diesem Prozess beteiligten Anwendungen das SyncML Sync Protocol implementieren. Dieses Protokoll wird als Prozessinstanz der beteiligten Synchronisationsengines (SyncEngine) ausgeführt. In Abbildung 4.4 ist die Synchronisationsengine nur für den Server gezeigt. Zwar ist auch clientseitig eine entsprechende Engine vorhanden, aufgrund des eingeschränkten Funktionsumfangs der Client-Komponente (clientseitig wird das Protokoll nur in Teilen implementiert) wird in der Skizze auf die Darstellung der Engine

4 Replikation und Synchronisation

verzichtet. Die Synchronisation selbst erfolgt über spezielle Synchronisationsnachrichten, die nichts anderes als XML-Dokumente sind. Das SyncML-Interface und der zugehörige SyncML-Adapter haben die Aufgabe, die originalen Daten (server- und clientseitig) in das vorgesehene XML-Austauschformat zu transformieren. Die Kommunikation zwischen den am Synchronisationsprozess beteiligten Instanzen erfolgt ausschließlich über diese Adapter. Im Verlauf des Transformationsprozesses wird jeder Synchronisationsprozess zu einem SyncML Package zusammengefasst, das selbst wiederum mehrere SyncML Messages enthält. Jede solche Nachricht ist ein einzelnes XML-Dokument, in dessen Header unter Anderem wichtige Versionierungsinformationen übermittelt werden. Der Rumpf des XML-Dokumentes enthält, neben den zu synchronisierenden Nutzdaten, weitere relevante Informationen, unter anderem Befehle zur Steuerung der Synchronisation. Für das globale Management aller Synchronisationsprozesse wird ein Synchronisationsserver eingesetzt.

Transformationsprozess

4.6.2 Synchronisationskonflikte Wie immer beim Abgleich von Daten, die redundant auf mehreren Clients existieren und dort auch parallel geändert werden können, kann es zu Synchronisationskonflikten kommen. Die Erkennung und Auflösung von Konflikten fällt bei SyncML grundsätzlich in den Aufgabenbereich des Servers bzw. der SyncEngine. Stellt die SyncEngine einen Konflikt fest, übermittelt sie diesen Sachverhalt an denjenigen Client, der durch die eingebrachten Änderungen den Konflikt verursacht hat. Danach werden Konfliktauflösungsroutinen initialisiert, die auf speziellen Regeln basieren und durch deren Anwendung ein Konflikt aufgelöst werden kann. SyncML legt jedoch nicht fest, welche Konfliktauflösungsroutinen in welchem Konfliktfall konkret angewandt werden sollen. Nachfolgend werden einige Beispiele von Konfliktauflösungsmethoden aufgelistet: ■

Kapitulation. Die gewünschte Synchronisation wird nicht durchgeführt, die beiden Parteien über den Fehlschlag informiert. Es kommt zu keiner Konfliktauflösung.

■

Duplikat. Von dem Datensatz, der den Konflikt ausgelöst hat, wird ein Duplikat angelegt. Die beiden in Konkurrenz stehenden, den Konflikt verursachenden Änderungen werden dann auf

4.6 Synchronization Markup Language (SyncML)

Konfliktbehandlung

■ ■ ■

107

jeweils einem der verfügbaren Datensätze und unabhängig voneinander ausgeführt. ■

Priorität. Auf Datenoperationen können Prioritäten definiert werden. Im Konfliktfall kann dann beispielsweise eine höher priorisierte Löschoperation (DELETE) vor einer niedriger priorisierten Aktualisierungsoperation (UPDATE) ausgeführt werden.

■

Gewinner. Dieses Konzept ähnelt der zuvor vorgestellten Priorisierung. Dabei gewinnt immer eine der beiden Konfliktparteien. So kann beispielsweise definiert werden, dass stets der Client gewinnt, dieser also immer lokal durchgeführte Änderungen garantiert auf einer zentralen Datenbank nachziehen kann. Dieses Konzept setzt auf einer semantisch höheren Ebene als die Priorisierung an.

4.7 Zusammenfassung In diesem Kapitel standen die für mobile Datenbanksysteme sehr wichtigen Konzepte Replikation und Synchronisation im Mittelpunkt. Nach einer Einführung und Darstellung der wichtigsten Grundlagen wurden anschließend Vorgehensweisen konkreter Replikations- und Synchronisationsverfahren vorgestellt und auf ihre Tauglichkeit für einen Einsatz in mobilen Umgebungen hin untersucht. Dabei wurde schnell ersichtlicht, dass viele klassische Verfahren, wie sie typischerweise in verteilten Umgebungen eingesetzt werden, im mobilen Umfeld nicht sinnvoll oder oft sogar gar nicht eingesetzt werden können. In jedem Fall lassen sich verfügbarkeitserhaltende Verfahren besser an den mobilen Kontext adaptieren als konsistenzerhaltende Verfahren. Bei den konsistenzerhaltenden Verfahren ist zudem den optimistischen Verfahren der Vorzug vor den pessimistischen Verfahren zu geben. Anschließend wurden mit Virtual-Primary-Copy und dem Snapshot-Verfahren zwei neue mobile Verfahren vorgestellt. Mit der nutzerdefinierten Replikation wurde dann nicht nur ein Verfahren beschrieben, sondern auch eine dazugehörige Architektur. Eine Beschreibung der wichtigsten Konzepte der Synchronization Markup Language (SyncML) rundete dieses Kapitel schließlich ab. SyncML ist eine XML-Sprache für die herstellerunabhängige Definition von Synchronisationsmechanismen.

108

■ ■ ■

4 Replikation und Synchronisation

5 Mobile Transaktionen

In Datenbanksystemen geht es oft zu wie auf einem Rangierbahnhof: sehr viele verschiedene Aktionen (Rangierbewegungen) laufen innerhalb des gleichen Areals (dem Rangierbahnhof) gleichzeitig ab. Damit der Verkehr auf dem Rangierbahnhof nicht zusammenbricht, muss eine zentrale Instanz mit erprobten Methoden und anhand definierter Regeln sicherstellen, dass keine Kollisionen auftreten. Übertragen auf den Bereich der Datenbanksysteme entspricht der Rangierbahnhof einer Datenbank, die ablaufenden Aktionen sind Transaktionen und die zentrale Instanz, die die parallele Ausführung von Transaktionen steuert, ist die Concurrency Control. Die Unterstützung von Transaktionen und von adäquaten Koordinationsmechanismen für eine nebenläufige Ausführung sehr vieler Transaktionen ist eine der wichtigsten Eigenschaften von Datenbanksystemen. In mobilen Umgebungen erfordern Transaktionen weitere Anpassungen, die bei der Konzeption und Entwicklung eines Ausführungsmodells berücksichtigt werden müssen. Aus diesem Grund werden in diesem Kapitel verschiedene für mobile Umgebungen (mehr oder weniger gut) geeignete Transaktionsmodelle vorgestellt, die in ihrem Reifegrad oft aber nicht über eine Implementierung in Forschungsprotoptypen hinausgekommen sind.

Motivation

Anforderungen

Die vorgestellten Transaktionsmodelle gehen in ihren Anforderungen und Vorgehensweisen wesentlich weiter, als es bei den zuvor beschriebenen Konzepten der Replikation und der Synchronisation der Fall war. Entscheidend ist jetzt nicht die Definition eines relativ isolierten Konzeptes für einen relativ kleinen Anwendungsbereich, sondern die Verschmelzung von Konzepten der Replikation, der Synchronisation und der Ausführung von Datenbankoperationen zu einem umfassenden, integrierenden Gesamtmodell. Ein so definiertes Modell sollte einfach, flexibel, gleichzeitig aber auch mächtig und gut zu implementieren sein.

4.7 Zusammenfassung

■ ■ ■

109

5.1 Klassische Transaktionen Transaktionen

Begriffe

Eine Transaktion ist die logische Ausführungseinheit auf einer Datenbank. Meist werden mehrere Datenbankoperationen zu einer Transaktion zusammengefasst. Von einer schreibenden Transaktion spricht man dann, wenn mindestens eine Operation einer Transaktion Daten modifiziert, also einfügt, ändert oder löscht. Im Fall, dass alle Operationen nur lesend auf vorhandene Daten zugreifen, spricht man von lesenden Transaktionen. Transaktionsverarbeitungssysteme sind Anwendungssysteme, die auf großen Datenbanken aufsetzen, auf denen hunderte oder tausende von Nutzern gleichzeitig arbeiten und die sich durch eine hohe Anzahl parallel ausgeführter Transaktionen auszeichnen. Typische Beispiele solcher Anwendungssysteme sind Reservierungssysteme, Wertpapierhandelssysteme oder Bank- und Versicherungsanwendungen. Wichtige Anforderungen sind eine hohe Verfügbarkeit der Datenbank und geringe Antwortzeiten.

5.1.1 Nebenläufigkeit Nebenläufigkeitsproblem

Fehlersituationen

110

■ ■ ■

Gerade in Transaktionsverarbeitungssystemen kommt der Nebenläufigkeit mehrerer Transaktionen eine besondere Bedeutung zu. Diese müssen dann geeignet serialisiert und gegeneinander abgeschottet werden, um sich nicht gegenseitig zu stören. Andernfalls bekommt man die typischen Nebenläufigkeitsprobleme: Lost Update, Dirty Reads oder Unrepeatable Reads: ■

Lost Update. Zwei verschiedene schreibende Transaktionen A und B, die auf die gleichen Datenbankobjekte (z.B. ein Tupel) zugreifen, überlappen sich zeitlich so, dass es zur Abspeicherung eines falschen Datenwertes (also zu einer Inkonsistenz) in der Datenbank kommt. Dabei überschreibt Transaktion B einen bereits von Transaktion A aktualisierten Wert.

■

Dirty Read. Zunächst schreibt eine Transaktion A ein Datenobjekt (z.B. ein Tupel). Anschließend liest eine Transaktion B diesen geschriebenen Wert, bevor Transaktion A beendet wurde. Wird Transaktion A abgebrochen und zurückgesetzt, wird auch der durch Transaktion A geschriebene Wert zurückgesetzt. In diesem Fall hat Transaktion B einen Wert gelesen, der nie in der Datenbank hätte stehen dürfen. Transaktion B arbeitet dann mit einem falschen Datenwert.

5 Mobile Transaktionen

■

Unrepeatable Read. Zu dieser Problemsituation kann es kommen, wenn eine Transaktion A ein Datenobjekt zweimal hintereinander liest und das gelesene Datenobjekt zwischen den beiden Lesezugriffen durch eine Transaktion B geändert wird. In diesem Fall werden Transaktion A zwei verschiedene Versionen des Datenobjektes innerhalb derselben Transaktion präsentiert.

Eine Transaktion, die nicht erfolgreich mit COMMIT beendet werden kann, muss zurückgesetzt werden. Die Transaktion ist dann in ihrer Ausführung fehlgeschlagen. Als Ursachen dafür kommen verschiedene Möglichkeiten in Frage: ■

Rechnerfehler bzw. Systemabsturz. Hardware-, Software- und Netzwerkfehler.

■

Transaktions- oder Systemfehler. Überlauf einer Zahl, Division durch Null oder fehlerhafte Parameterwerte.

■

Lokale Fehler- oder Ausnahmebedingungen. Bedingungen, die den sofortigen Transaktionsabbruch nach sich ziehen.

■

Nebenläufigkeitskontrolle. Verletzung der Serialisierbarkeit, Blockierung der Transaktionsausführung (Deadlock).

■

Plattenfehler. Lese- oder Schreibfehler durch Unbrauchbarkeit eines Lese-/Schreibkopfes einer Festplatte.

■

Physikalische Probleme und Katastrophen. Ausfall der Netzversorgung oder Lüftung, Brand, Diebstahl, Sabotage, versehentliches Überschreiben von Festplatten.

Fehler in der Transaktionsausführung

5.1.2 Transaktionszustände Jede Transaktion ist eine atomare Ausführungseinheit und wird entweder ganz oder gar nicht ausgeführt. Diese Eigenschaft wird mit Atomizität bezeichnet. Um Atomizität zu erreichen, werden für die Transaktionsausführung verschiedene Zustände definiert. Mit Ausführungsbeginn geht jede Transaktion in den Zustand AKTIV über, in dem die Lese- und Schreiboperationen der Transaktion ausgeführt werden. Mit Ende der letzten Datenbankoperation wechselt die Transaktion dann in den Zustand TEILWEISE BESTÄTIGT. Nachdem sichergestellt ist, dass die durchgeführten Änderungen auch im Falle eines plötzlichen Systemfehlers permanent in der Datenbank vorhanden sind, erfolgt der endgültige Abschluss und die Transaktion geht zunächst in den (eigentlich nur lo-

5.1 Klassische Transaktionen

Phasen der Transaktionsausführung

■ ■ ■

111

gischen) Zustand BESTÄTIGT und sofort danach in den Zustand BEENDET über. Kommt es während der beiden Phasen AKTIV und TEILWEISE BESTÄTIGT zu einem Fehler, geht eine Transaktion in den Zustand FEHLGESCHLAGEN, nach der notwendigen Kompensation der bisher schon ausgeführten Datenbankoperationen in den Zustand BEENDET über. Dieser ist identisch zum Zustand unmittelbar vor Beginn der Transaktion.

5.1.3 ACID-Transaktionen Motivation

In der Einleitung zu diesem Kapitel wurde die Metapher eines Rangierbahnhofes verwendet, um ein Datenbanksystem zu beschreiben. Dabei soll eine zentrale Instanz (Concurrency Control) verhindern, dass es zu einem Zustand des völligen Chaos kommt. Dazu definiert die Concurrency Control Verhaltensregeln, die von allen beteiligten Instanzen (Transaktionen) einzuhalten sind. Ein populäres Beispiel eines solchen Regelsatzes ist das ACID-Prinzip, das Transaktionsinkonsistenzen ausschließt. Es formuliert vier grundlegende Anforderungen, deren Anfangsbuchstaben A-C-I-D dieser vier Anforderungen dem Konzept auch seinen Namen geben:

Atomizität

■

Atomizität (Atomicity). Jede Transaktion wird entweder ganz oder gar nicht ausgeführt. Wenn eine Transaktion fehlschlägt, müssen auf einer Datenbank bereits durchgeführte Änderungen wieder rückgängig gemacht werden. Zur Veranschaulichung dient das folgende klassische Beispiel: eine Banktransaktion, die 50 € von Konto A auf Konto B überweisen soll, führt dazu, dass entweder der Saldo von Konto A um 50 € reduziert und der Saldo von Konto B um 50 € anwächst, oder dass gar nichts passiert. Eine Situation, in der das Geld von Konto A abgebucht, aber nicht auf Konto B gutgeschrieben wurde, ist inakzeptabel und wird durch das Prinzip der Atomizität verhindert.

Konsistenz

■

Konsistenz (Consistency). Mit jeder Transaktion wird die Datenbank von einem konsistenten Zustand in einen konsistenten Zustand überführt. Transaktionen sind damit konsistenzbewahrend. Während einer Transaktion ist ein konsistenter Datenbankzustand nicht immer gegeben. Diese Zwischenzustände dürfen daher nicht nach außen sichtbar sein. Darüber hinaus garantiert die Konsistenz die Einhaltung der im Datenbankschema

112

■ ■ ■

5 Mobile Transaktionen

definierten Integritätsbedingungen beim Abschluss der Transaktionen. ■

Isolation. Jede Transaktion soll isoliert von anderen Transaktionen ausgeführt werden. Jede Transaktion läuft unabhängig von anderen Transaktionen und wird von diesen nicht beeinflusst. Damit wird ein virtueller Einbenutzerbetrieb realisiert. Das bedeutet auch, dass Zwischenergebnisse einer Transaktion für andere Transaktionen nicht sichtbar sind. Der Isolationsumfang (auch Isolationslevel) eines Transaktionsmodells bestimmt, wie stark eine Transaktion von den Auswirkungen anderer Transaktionen abgeschirmt wird. Im Normalfall werden die Änderungen einer Transaktion erst mit dem abschließenden COMMIT für andere Transaktionen sichtbar. Dieser restriktivste Isolationsumfang garantiert, dass beispielsweise die oben beschriebenen Fehlersituationen Lost Update oder Dirty Read nicht auftreten.

Isolation

■

Dauerhaftigkeit (Durability). Dauerhaftigkeit bedeutet, dass die Änderungen einer beendeten Transaktion auf jeden Fall in der Datenbank enthalten sind, das heisst auf einem nichtflüchtigen Sekundärspeicher stehen, nicht mehr in irgendeinem Puffer. Werden die Änderungen nur im Hauptspeicher vorgenommen, so sind geeignete Maßnahmen notwendig, um die Änderungen auch nach einem Systemausfall wiederherstellen zu können. Dies wird in der Regel durch Logdateien erreicht.

Dauerhaftigkeit

Wenn von Transaktionen in Datenbanksystemen die Rede ist, wird in vielen Fällen davon ausgegangen, dass es sich um ACIDTransaktionen handelt, also um Transaktionen, die die oben genannten Eigenschaften besitzen. Dies muss jedoch nicht immer der Fall sein. Gerade bei mobilen Transaktionsmodellen werden einige ACID-Eigenschaften wieder aufgegeben. Wir werden darauf und auf die Konsequenzen jeweils gesondert eingehen.

5.1.4 Serialisierbarkeit von Transaktionen In diesem Abschnitt stehen die Ausführungspläne und die Serialisierbarkeit von Transaktionen im Mittelpunkt. Dies spielt gerade im Mehrbenutzerbetrieb eine entscheidende Rolle und gehört zu den elementaren Grundkonzepten in Datenbanksystemen. Ein Ausführungsplan (Schedule) S von n Transaktionen T1, T2, …, Tn ist eine Sequenz von Datenbankoperationen, die die Eigenschaft besitzt, dass die Operationen jeder Transaktion Ti, die Be-

5.1 Klassische Transaktionen

Ausführungsplan, Schedule

■ ■ ■

113

Serielle vs. nicht-serielle Ausführungspläne

Definition 5.2: Serialisierbarer Ausführungsplan

standteil von S ist, in S in der gleichen Reihenfolge wie in Ti erscheinen. Allerdings können die Datenbankoperationen einer Transaktion Ti mit Datenbankoperationen anderer Transaktionen Tj von S verschachtelt werden Eine triviale Spezialform von Ausführungsplänen sind serielle Ausführungspläne. Ein Ausführungsplan ist genau dann seriell, wenn alle Operationen einer Transaktion im Ausführungsplan direkt nacheinander ausgeführt werden. Bei einem solchen Ausführungsplan kommt es zu keinen Überlappungen von Datenbankoperationen. Er ist damit immer korrekt. Ist dieser Trivialfall einer sequentiellen Transaktionsausführung nicht gegeben, spricht man von einem nicht-seriellen Schedule. Serielle Ausführungspläne sind häufig sehr ineffizient und führen zu einem schlechten Gesamtdurchsatz. Dies kann durch geeignetes Verschachteln der Transaktionen verhindert werden. Nicht-serielle Transaktionen sind aber nicht per se korrekt. Nur serialisierbare Ausführungspläne sind korrekt. Ein Ausführungsplan S mit n Transaktionen ist genau dann serialisierbar (und korrekt), wenn er zu einem seriellen Ausführungsplan der n Transaktionen äquivalent ist, das heisst den gleichen Datenbankzustand produziert (Resultatsäquivalenz). Diese Definition ist leider nicht konstruktiv. Das heisst, aus ihr kann kein Verfahren abgeleitet werden, wie man zu serialisierbaren Schedules kommt, noch wie man diese effizient auf ihre Korrektheit testet. Es kann allerdings gezeigt werden, dass das Zwei-Phasen-Sperrprotokoll immer serialisierbare und damit korrekte Schedules erzeugt. Dieses fordert je Transaktion in der ersten Phase sukzessive alle Sperren an, führt dann die Änderungen durch und gibt sie in der zweiten Phase wieder sukzessive wieder frei. Um ein kaskadierendes Rücksetzen von Transaktionen zu vermeiden, kommt meist das strenge Zwei-Phasen-Sperrprotokoll zum Einsatz, das alle Sperren bis zum COMMIT hält und dann auf einen Schlag freigibt. Nachdem nun die wichtigsten Grundlagen der klassischen Transaktionsverarbeitung kurz erläutert wurden, stehen im weiteren Verlauf die Besonderheiten der Transaktionsverarbeitung in mobilen Umgebungen im Vordergrund.

114

■ ■ ■

5 Mobile Transaktionen

5.2 Mobile Transaktionen Der Unterschied zwischen klassischen und mobilen Transaktionen ist, dass mobile Transaktionen ihren Ursprung auf mobilen Clients haben, das heisst sie werden auf diesen initiiert und in mobilen Umgebungen ausgeführt und müssen damit auch mit dem Wechsel von Funkzellen (Handover) und dem temporären Disconnected Mode, zumindest aber dem Modus Schwach-Verbunden, umgehen können. Unterschiedliche mobile Transaktionsmodelle haben aber – ausgehend von dieser doch recht allgemeinen Definition – ein unterschiedliches Verständnis darüber, wie eine mobile Transaktion im Detail ausgeführt wird. So charakterisieren einige der nachfolgend vorgestellten Transaktionsmodelle eine mobile Transaktion als eine einzige, langlebende Transaktion, die auch durch einen Wechsel zwischen den verschiedenen Betriebszuständen eines mobilen Clients in ihrer Ausführung nicht unterbrochen wird, während andere Transaktionsmodelle zweistufige Verarbeitungsmodelle vorsehen. Auch was die Architekturen der Informationssysteme anbelangt, in denen eine Transaktion ausgeführt wird, existieren unterschiedliche Vorgaben. Einige Transaktionsmodelle fokussieren die Ausführung in Multidatenbanksystemen, andere gehen von Client/ServerUmgebungen aus und wiederum andere betrachten die Transaktionsausführung in verteilten Datenbanken. Der Einfachheit halber wird in den nachfolgenden Abschnitten von einer Client/ServerArchitektur ausgegangen (wenn es diesbezüglich keine anders lautenden Aussagen gibt). Mehreren mobilen Clients steht dabei ein zentraler Datenbankserver gegenüber. Mobile Transaktionsmodelle können in zwei unterschiedliche Klassen unterteilt werden. Das entscheidende Unterscheidungskriterium ist die Unterstützung des Disconnected Mode mobiler Clients, da mit diesem Betriebszustand Anforderungen an die Transaktionsverarbeitung geknüpft sind. Nach Kapitel 1 wird zwischen den beiden Betriebszuständen Schwach-Verbunden (Connected Mode) und Unverbunden (Disconnected Mode) unterschieden und diese Betriebszustände sind es auch, die eine Klassifikation mobiler Transaktionsmodelle ermöglichen: ■

Klassische vs. Mobile Transaktionen

Klassifikation mobiler Transaktionsmodelle

Klasse 1: Schwach-Verbunden (Connected Mode). Bei den Transaktionsmodellen dieser Klasse kann zwar keine permanent bestehende Netzwerkverbindung vorausgesetzt werden, bei Bedarf kann eine solche Verbindung jedoch stets aufgebaut werden. Transaktionsmodelle dieser Klasse arbeiten entweder oft direkt auf einem Datenbankserver im Backend, oder sehen zu-

5.2 Mobile Transaktionen

■ ■ ■

115

mindest mit jedem COMMIT einer Transaktion eine Kontaktaufnahme mit dem Datenbankserver vor, wenn lokal auf Daten des mobilen Clients gearbeitet wird. Eine Variante ist, direkt nach dem Abschluss einer clientseitig ausgeführten Transaktion eine Verbindung zwischen Client und Datenbankserver aufzubauen, um die clientseitig bereits beendete Transaktion auf dem Datenbankserver einzubringen. Alternativ kann aber auch definiert sein, dass sogar zum Abschluss jeder einzelnen Datenbankoperation einer Transaktion eine Verbindung zum Datenbankserver aufgebaut werden muss. Andere Transaktionsmodelle führen Transaktionen stets direkt auf dem Datenbankserver aus. Transaktionsmodelle, die dieser Klasse zugeordnet werden können sind die Kangaroo-Transaktionen, die Preserialization Transaction Management Technique, die offen-geschachtelten Transaktionen und die Prewrite-Transaktionen. ■

116

■ ■ ■

Klasse 2: Unverbunden (Disconnected Mode). Bei den Transaktionsmodellen dieser Klasse wird davon ausgegangen, dass Transaktionen zunächst immer lokal auf replizierten Daten des mobilen Clients ausgeführt werden, unabhängig davon, in welchem Betriebszustand dieser sich aktuell befindet. Auf den mobilen Clients können dabei Transaktionen ausgeführt werden, ohne dass mit dem COMMIT einer Transaktion – wie bei der zuvor vorgestellten Klasse – ein Zugriff auf einen zentralen Datenbankserver notwendig ist. Um die globale Datenkonsistenz innerhalb der Replikationsumgebung zu erhalten, müssen die auf einem Replikat lokal durchgeführten Transaktionen zu einem späteren Zeitpunkt jedoch mit den anderen Kopien des Replikats abgeglichen werden. Die Beschreibung dieses Synchronisationsprozesses und der Replikationsverfahren stellt einen wichtigen Teil der Transaktionsmodelle dieser Klasse dar (vgl. Kapitel 4). Bei der Synchronisation kann es zu Konflikten kommen, die zunächst erkannt, danach unter Verwendung geeigneter (automatisierter oder manueller) Konfliktbehandlungsmethoden aufgelöst werden müssen. Gelingt die Konfliktauflösung nicht, muss die den Konflikt verursachende Transaktion temporär zurückgesetzt werden. Gelingt die Synchronisation auch in einem erneuten, späteren Versuch nicht, ist es notwendig, die Transaktion endgültig abzubrechen und zurückzusetzen. Dies kann, wenn andere Transaktionen auf dem mobilen Client die Ergebnisse bereits nutzen, zu kaskadierenden Rücksetzungen führen. Transaktionsmodelle dieser Klasse sind die provisorischen Transaktionen, die semantischen Transaktionen, die schwachen/strikten Transaktionen, die Isolation-OnlyTransaktionen und die Promotion-Transaktionen.

5 Mobile Transaktionen

Nachdem nun ein Kriterium vorgestellt wurde, welches eine einfache Klassifizierung mobiler Transaktionsmodelle gestattet, werden in den nächsten Abschnitten konkrete Transaktionsmodelle und ihre wichtigsten Konzepte und Methoden vorgestellt.

5.3 Transaktionsmodelle der Klasse 1 Nachfolgend werden vier Transaktionsmodelle vorgestellt, die für eine Transaktionsausführung den Betriebszustand SchwachVerbunden (Connected Mode) mobiler Clients erfordern, den Disconnected Mode mobiler Clients also nicht unterstützen. Es sind dies: die Kangaroo-Transaktionen, die PSTMT-Transaktionen, die offen-geschachtelten Transaktionen und die Prewrite-Transaktionen.

Klasse 1Modelle

5.3.1 Kangaroo-Transaktionen Das Transaktionsmodell der Kangaroo-Transaktionen [Dun97] setzt auf der in Kapitel 1 definierten Referenzarchitektur einer mobilen Umgebung auf und verlangt die Ausführung sämtlicher Operationen einer Transaktion (Transaktionsbeginn, Lese- und Schreiboperationen, Transaktionsabschluss) direkt auf dem Datenbankserver im Backend. Der Zugriff auf den Datenbankserver erfolgt dabei über die jeweils aktuelle Basisstation. Die Basisstationen koordinieren über eine spezielle Komponente die Ausführung einer Transaktion. Die Besonderheit dieses Transaktionsmodells besteht darin, dass mit der Migration eines mobilen Clients auch die Koordination einer Transaktion und somit eine Transaktion selbst an die neue Basisstation übergeben wird, gleichzeitig aber die bereits in Ausführung befindlichen Operationen der Transaktion weiterhin von der alten Basisstation kontrolliert und ausgeführt werden. Diese auf verschiedene Basisstationen verteilte Transaktionsausführung hat dem Modell auch seinen einprägsamen Namen gegeben. Zusammen mit der Bewegung eines mobilen Clients springt eine Transaktion wie ein australisches Känguru von einer Basisstation zur nächsten. Der Disconnected Mode wird von diesem Transaktionsmodell wie bereits erwähnt nicht unterstützt, was implizit auch bedeutet, dass auf den Einsatz von Replikation verzichtet werden kann (und wird). Das Szenario unterstützt verschiedene Architekturen. Die für Kangaroo-Transaktionen im Originalpapier vorgesehene Architektur ist aber ein Multidatenbanksystem.

5.3 Transaktionsmodelle der Klasse 1

■ ■ ■

117

5.3.1.1 Architektur Ein Multidatenbanksystem besteht aus einer Menge voneinander unabhängiger Datenbanksysteme, die die Datenquellen des Informationssystems sind. Die Datenquellen werden auch als lokale Datenbanksysteme des Multidatenbanksystems bezeichnet. Alle diese Datenquellen können aus Anwendungen heraus entweder direkt oder über eine gemeinsame, einheitliche Schnittstelle des Multidatenbanksystems angesprochen werden. Auf den Basisstationen des Festnetzes sind Datenzugriffsagenten (DAA - Data Access Agents) installiert, die für die Koordination und Ausführung von auf mobilen Clients initiierten Transaktionen verantwortlich sind. Synchronisationskonflikte können somit unberücksichtigt bleiben, da die Voraussetzung für deren Entstehung, ein nebenläufiger Zugriff auf replizierte Daten, in diesem Modell nicht vorgesehen ist. Eine Transaktion besteht aus Datenbankoperationen, die direkt auf den lokalen Datenbanksystemen ausgeführt werden. Auf den Einsatz mobiler Datenbanksysteme wird verzichtet. Dies bedeutet, dass ausschließlich der Betriebszustand Verbunden von mobilen Clients unterstützt wird. Die Mobilität von Clients ist bei Verbindungsabbrüchen dadurch nicht transparent. Abb. 5.1: Architektur zur Unterstützung von KangarooTransaktionen

Globale Nutzer Anwendungsschnittstelle Mobiles Multidatenbanksystem Globaler Transaktionsmanager

Interface LDBS #1

Interface LDBS #2

Globale Komponenten

Lokale Komponenten

5.3.1.2 Konzepte der Ausführung Das Modell der Kangaroo-Transaktionen stellt den mobilen Charakter einer Transaktion in den Vordergrund. Initiiert ein Client eine Transaktion, wird diese der aktuellen Basisstation und dem dort installierten Datenzugriffsagenten übermittelt. Dieser ist dann für die weitere Ausführung der Transaktion verantwortlich. Bewegt sich ein mobiler Client in eine andere Funkzelle (und erhält eine neue Basisstation zugewiesen), werden dem Datenzugriffsagenten der neuen

118

■ ■ ■

5 Mobile Transaktionen

Basisstation alle erforderlichen Informationen, die zur weiteren Verarbeitung der Transaktion notwendig sind, von der alten Basisstation mitgeteilt. Eine Transaktion kann also über verschiedene Basisstationen ausgeführt werden – welche Basisstationen genau an der Ausführung einer Transaktion beteiligt waren, kann erst mit Beendigung der Transaktion gesagt werden. Für die Koordination aller parallel auf einer Basisstation ablaufenden Transaktionen ist ein mobiler Transaktionsmanager (MTM - Mobile Transaction Manager) verantwortlich. Jede Transaktion besteht aus einer Sequenz von Operationen, die auf einem oder mehreren lokalen Datenbanksystemen ausgeführt werden. Die auf einem konkreten lokalen Datenbanksystem ausgeführten Transaktionsbestandteile werden zu einer SiteTransaction bzw. Subtransaktion zusammengefasst. Das lokale Datenbanksystem, auf das sich eine einzelne Subtransaktion bezieht, kann dabei erneut ein Multidatenbanksystem ein, so dass eine Subtransaktion in diesem Fall eigentlich eine weitere globale Transaktion darstellt. Dies erlaubt die Definition rekursiver Transaktionsstrukturen (vgl. Abbildung 5.2) mit einer beliebigen Verschachtelungstiefe. Was die Architektur der lokalen Datenbanksysteme anbelangt, werden keinerlei Vorgaben gemacht. Eine Transaktion wird auch als globale Transaktion (GT – Global Transaction) bezeichnet. Abb. 5.2: Rekursive Struktur einer globalen Transaktion

GT

LT1

GT1

GT2

LT2

Wird durch einen mobilen Client eine Transaktion initiiert, generiert der Datenzugriffsagent der aktuellen Basisstation zunächst eine entsprechende globale Kangaroo-Transaktion. Mit jeder neuen globalen Transaktion wird dabei eine Datenstruktur erzeugt, die alle für die Ausführung einer globalen Transaktion notwendigen Informationen speichert. Diese Datenstruktur ist die Transaktionsstatustabelle.

Transaktionsstatustabelle

Mit der Generierung einer Transaktion wird jeder globalen Transaktion eine eindeutige Kangaroo-Transaction-ID (KTID) zugewiesen. Diese wird in der Transaktionsstatustabelle abgelegt. Die ID wird dabei wie folgt gebildet: KTID = BasestationID + SequenceNumber

5.3 Transaktionsmodelle der Klasse 1

■ ■ ■

119

Joey Transaktionen

120

■ ■ ■

Die ID der Basisstation (BasestationID) ist systemweit eindeutig, während die Sequenznummer (SequenceNumber) nur im Versorgungsbereich der aktuellen Basisstation eindeutig ist. Alle von einer globalen Transaktion auf einzelnen lokalen Datenbanksystemen auszuführenden Subtransaktionen werden zusammen als Beutel (Pouch) bezeichnet. Zwei globale Transaktionen sind genau dann äquivalent, wenn sie den identischen Beutel besitzen. Mit jeder Migration eines mobilen Clients in eine andere Funkzelle und dem gleichzeitigen Wechsel der Basisstation wird eine Zerlegungsoperation durchgeführt, bei der die bereits abgeschlossenen und noch in Bearbeitung befindlichen Subtransaktionen einer globalen Transaktion von der Menge der noch nicht bearbeiteten Subtransaktionen abgespalten werden. Für die Administration dieser Zerlegungsoperationen wird eine zusätzliche Ausführungsebene in das Transaktionsmodell eingeführt. Die Idee dahinter ist, alle auf einer einzelnen Basisstation ausgeführten Subtransaktionen zu einer so genannten Joey-Transaktion (JT) zusammenzufassen. Eine Joey-Transaktion kann dabei nur vollständige Subtransaktionen enthalten, das heisst, das Transaktionsmodell garantiert die Atomizität von Subtransaktionen. Mit der Initialisierung einer globalen Transaktion wird dann auch sofort eine erste Joey-Transaktion angelegt, die zunächst alle Subtransaktionen der globalen Transaktion umfasst (da zunächst ja alle Subtransaktionen über die aktuelle Basisstation ausgeführt werden). Bei einem Wechsel der Basisstation wird durch den Datenzugriffsagenten der alten Basisstation die Transaktionsstatustabelle der globalen Transaktion an den Datenzugriffsagenten der neuen Basisstation übermittelt. Zusätzlich kommt es zu der angesprochenen Zerlegungsoperation, deren Ergebnis eine neue Joey-Transaktion auf der neuen Basisstation ist. Die neue Joey-Transaktion umfasst also all diejenigen Subtransaktionen, deren Ausführung noch nicht begonnen wurde. Gleichzeitig bleibt die weiterhin bestehende, alte Joey-Transaktion auf der alten Basisstation ebenfalls aktiv und koordiniert die weitere Ausführung der zum Migrationszeitpunkt gerade ablaufenden Subtransaktionen. Somit müssen bei einem Wechsel der Basisstation die gerade aktiven Subtransaktionen nicht unterbrochen werden. Darüber hinaus speichert die alte Joey-Transaktion auch die Ergebnisse der Subtransaktionen. Das Transaktionsmodell der Kangaroo-Transaktionen setzt voraus, dass alle Subtransaktionen einer einzelnen Joey-Transaktion strikt nacheinander ausgeführt werden. Eine neue Subtransaktion wird also in jedem Fall erst nach Beendigung der vorhergehenden Subtransaktion angestoßen (auch wenn dies zu erheblichen Performanzeinbußen führt), da nur durch diese Vorgehensweise die vorge-

5 Mobile Transaktionen

sehene Zerlegungsoperation durchgeführt werden kann. Erst dies garantiert, dass eine Joey-Transaktion JTi der nächsten JoeyTransaktion JTi+1 in einer serialisierbaren Reihenfolge vorausgeht. Initialisierung auf mobilen Clients Mobile Transaktion

Abb. 5.3: Transaktionsmodell

Basisstationen Kangaroo-Transaktion

Joey-Transaktionen

Site-Transaktionen

Lokale Transaktion

Globale Transaktion

LDBS des Multidatenbanksystems

Jeder neuen Joey-Transaktion wird eine eindeutige JoeyTransaction-ID (JTID) zugewiesen, die ebenfalls in der Transaktionsstatustabelle abgelegt wird. Die JTID wird dabei auf ähnliche Weise wie die KTID definiert: JTID = KTID + SequenceNumber

Zusätzlich wird für jede neue Joey-Transaktion die Transaktionsstatustabelle um eine weitere Substruktur ergänzt, die diejenigen Informationen speichert, die für die Verwaltung der Joey-Transaktion benötigt werden. Jede solche Substruktur wird um weitere Substrukturen ergänzt, in denen wiederum Informationen gespeichert werden, die für die Ausführung der Subtransaktionen der Joey-Transaktion gebraucht werden. Das Ausführungsmodell für die globalen Transaktionen sieht zwei verschiedene Ausführungsvarianten vor: den Kompensationsmodus (Compensating Mode) und den Splitmodus (Split Mode). Wird eine globale Transaktion im Kompensationsmodus ausgeführt, muss bei einem Fehler während der Ausführung einer Subtransaktion die aktuelle Joey-Transaktion zusammen mit den bereits beendeten Joey-

5.3 Transaktionsmodelle der Klasse 1

Ausführungsmodi

■ ■ ■

121

Transaktionen kompensiert, das heisst rückgängig gemacht werden. Dies bedeutet, dass letztlich die gesamte globale Transaktion zurückgesetzt wird. Dagegen wird im alternativen Splitmodus (Standardfall) bei einem Fehler lediglich die Forderung gestellt, keine neuen globalen Transaktionen oder Subtransaktionen mehr zu initiieren. Bereits beendete Subtransaktionen müssen nicht kompensiert werden und noch in Ausführung befindliche Subtransaktionen können abgebrochen oder wahlweise beendet werden. Abb. 5.4: Schematische Darstellung des Ausführungsmodells [Dun97]

KT Zellenwechsel (Hand-Off)

JT1

GT11

LT12

GT12

JT2

GT21

GT22

Basisstation #2

Basisstation #1

Zellenwechsel (Hand-Off)

JT3

GT31 BS #3

MULTIDATENBANK

Alle an der Ausführung einer globalen Transaktion beteiligten Basisstationen sind in Form einer doppelt verketteten Liste miteinander verbunden. Dies ist für das Zurücksetzen der Joey-Transaktionen einer Kangaroo-Transaktion im Kompensationsmodus wichtig. Kommt es zu einem Fehlerfall, müssen die bisherigen Auswirkungen einer globalen Transaktion rückgängig gemacht werden, indem die aktuelle und die vorherigen Joey-Transaktionen kompensiert werden. Um die zu kompensierenden Joey-Transaktionen zu erreichen, muss nur die doppelt verkettete Liste rückwärts durchlaufen werden. 5.3.1.3 Bewertung Das Modell der Kangaroo-Transaktionen ist ein Transaktionsmodell, das explizit die Bewegung mobiler Clients und der damit verbundenen Schwierigkeiten berücksichtigt. Alle Wechsel zu einer neuen Basisstation werden dazu über eine spezielle Datenstruktur, Transaktionsstatustabelle genannt, nachgeführt. Diese Datenstruktur kapselt alle Informationen, die für die Ausführung von globalen Kangaroo-Transaktionen, Joey-Transaktionen und Subtransaktionen benötigt werden. Mit jedem Handover wird die Transaktionsstatustabelle von der alten auf die neue Basisstation übertragen. Ein Nachteil die-

122

■ ■ ■

5 Mobile Transaktionen

ses Transaktionsmodells ist jedoch, dass für die Initiierung einer Transaktion stets eine Verbindung zu einer Basisstation aufgebaut werden muss.

5.3.2 Preserialization Transaction Management Technique Auch die Preserialization Transaction Management Technique (PSTMT) [Dir00] wurde explizit für einen Einsatz in mobilen Umgebungen entwickelt. Wie bei den Kangaroo-Transaktionen wird auch in diesem Fall angenommen, dass das Transaktionsmodell auf einem Multidatenbanksystems aufsetzt. Wiederum werden globale Transaktionen in Subtransaktionen aufgespalten, die dann auf den einzelnen Knoten bzw. lokalen Datenbanksystemen des Multidatenbanksystems ausgeführt werden. Wie zuvor muss für die Ausführung einer globalen Transaktion stets eine Verbindung zu einer Basisstation bestehen, die auch die Ausführung einer globalen Transaktion koordiniert. Dieses Transaktionsmodell fokussiert den effizienten Umgang mit dem Abbruch bestehender Netzwerkverbindungen während der Ausführung globaler Transaktionen. Bei PSTMT-Transaktionen wird der Disconnected Mode mobiler Clients unterstützt (wenn auch in stark begrenztem Umfang). Trotzdem wird dieses Transaktionsmodell zur Klasse 1 gezählt, da die Unterstützung des Disconnected Mode nicht weit genug geht, um tatsächlich zur Klasse 2 gezählt werden zu können. Die Möglichkeit, während länger andauernder Offline-Phasen auf replizierten Datenbeständen lokale Transaktionen auszuführen, ist für mobile Clients bei PSTMT nicht gegeben. Globale Transaktionen, die auch Preserialization-Transaktionen oder PS-Transaktionen bezeichnet werden, sind charakterisiert als langlebende Transaktionen, die in ihrer Ausführung für einen kurzen Zeitraum temporär unterbrochen werden können. Mobile Clients initiieren dabei die globalen Transaktionen. Unterbrechungen in der Transaktionsausführung können vorhersehbar (vorbereitetes Handover) oder unvorhersehbar (plötzliches Funkloch) sein. Das Transaktionsmodell stellt dabei aber vor allem die Behandlung vorhersehbarer, nur kurz andauernder Unterbrechungen in den Vordergrund. Das Ziel ist es, die Ausführung einer globalen Transaktion so zu gestalten, dass durch Subtransaktionen belegte Ressourcen auf den lokalen Datenbanksystemen möglichst schnell wieder freigegeben werden. Dies soll verhindern, dass bei plötzlichen Verbindungsab-

5.3 Transaktionsmodelle der Klasse 1

■ ■ ■

123

brüchen wertvolle Ressourcen unnötig blockiert werden, wenn Subtransaktionen verwaisen. 5.3.2.1 Konzepte der Ausführung Globale Transaktionen bestehen aus Subtransaktionen. Eine einzelne Subtransaktion besteht aus all denjenigen Operationen, die auf demselben lokalen Datenbanksystem des Multidatenbanksystems ausgeführt werden. Wie zuvor können Subtransaktionen selbst wiederum globale Transaktionen anderer Multidatenbanksysteme sein. Im Gegensatz zu den Kangaroo-Transaktionen müssen PS-Transaktionen auch nicht strikt seriell ausgeführt werden. Jede Subtransaktion wird unabhängig von der übergeordneten globalen Transaktion ausgeführt und belegt auf einem lokalen Datenbanksystem Ressourcen. Um die von Subtransaktionen belegten Ressourcen noch vor dem Ende der globalen Transaktion wieder freigeben zu können, wird versucht, Subtransaktionen durch ein vorgezogenes COMMIT frühzeitig zu beenden. Die Koordination und Ausführung globaler Transaktionen übernimmt ein globaler Transaktionsmanager. Dieser besteht aus einer globalen Koordinationsschicht (GC – Global Coordination Layer) und einer darunter liegenden Systemmanagementschicht (SM – Site Manager Layer). Beide Schichten sind logisch gesehen über alle Basisstationen respektive lokale Datenbanksysteme aufgespannt. Auf der globalen Koordinationsschicht wird für jeden mobilen Client ein globaler Transaktionskoordinator (GTC – Global Transaction Coordinator) als Instanz des globalen Transaktionsmanagers erzeugt. Die wichtigsten Komponenten der tiefer liegenden Systemmanagementschicht sind für jedes lokale Datenbanksystem bereitgestellte Subtransaktionsmanager (STM – Site Transaction Manager). Die mobilen Clients selbst sind nach der Initiierung einer Transaktion nicht mehr an der Ausführung einer Transaktion beteiligt und müssen lediglich die Verbindung zu einer Basisstation aufrechterhalten, um das Ergebnis der Transaktion zu empfangen. Nach ihrer Aufsplittung in Subtransaktionen wird jede einzelne Subtransaktion an die relevanten Subtransaktionsmanager weitergeleitet. Diese führen anschließend die Subtransaktionen auf den lokalen Datenbanksystemen aus. Zu jedem Zeitpunkt befindet sich eine Transaktion in einem der fünf folgenden Transaktionszustände: ■

124

■ ■ ■

Aktiv (Active). Der mobile Client, der die Transaktion initiiert hat, ist mit der Basisstation verbunden und die Transaktion befindet sich in Ausführung.

5 Mobile Transaktionen

GTC 1

Basisstation

GTC 2

GC Layer

Mobile Clients initialisieren mobile Transaktionen

Abb. 5.5: Architektur des Global Transaction Manager (GTM)

STM1

STM2

STM3

SM Layer

Globaler Transaktionsmanager

■

Verbindungslos (Disconnected). Der mobile Client, der die Transaktion initiiert hat, ist nicht mit der Basisstation verbunden und die Transaktionsausführung ist unterbrochen. Der Abbruch der Verbindung war jedoch vorhersehbar und der erneute Aufbau einer Verbindung und die weitere Fortsetzung in der Transaktionsausführung kann erwartet werden.

■

Unterbrochen (Suspended). Der mobile Client, der die Transaktion initiiert hat, ist nicht mit der Basisstation verbunden und die Transaktionsausführung ist unterbrochen. Im Gegensatz zum vorherigen Zustand kann jedoch davon ausgegangen werden, dass die Verbindung dauerhaft unterbrochen bleibt, das heisst der genaue Zeitpunkt für eine weitere Transaktionsausführung kann nicht abgeschätzt werden.

■

Abgeschlossen (Committed). Die Transaktion wurde erfolgreich beendet.

■

Abgebrochen (Aborted). Die Transaktion wurde abgebrochen.

Transaktionszustände

Die zur Verwaltung einer Transaktion notwendigen Informationen werden wie zuvor bei den Kangaroo-Transaktionen, in einer speziellen Datenstruktur gespeichert, die durch den globalen Transaktionsmanager administriert wird. Wie bei den Kangaroo-Transaktionen wandert diese Datenstruktur zusammen mit dem mobilen Client von Basisstation zu Basisstation. Sobald die Verbindung eines mobilen Clients zur aktuellen Basisstation abbricht, muss entschieden werden, in welchen Zustand die Transaktion wechselt. Jeder Zustandswechsel wird in einer Transaktionsstatustabelle (TST – Transaction Status Table) eingetragen. Wird davon ausgegangen, dass die abge-

5.3 Transaktionsmodelle der Klasse 1

■ ■ ■

125

brochene Verbindung bald wieder hergestellt werden kann, wechselt die mobile Transaktion in den Zustand Verbindungslos. Die Ausführung der Subtransaktionen auf den lokalen Datenbanksystemen wird dabei nicht unterbrochen. Da die Ergebnisse der Transaktion jedoch nicht an den mobilen Client übertragen werden können, wird eine weitere Datenstruktur dazu benutzt, bereits erzielte Ergebnisse zwischenzuspeichern. Bei der erneuten Etablierung einer Verbindung werden diese gepufferten Ergebnisse dann an den mobilen Client übermittelt. Kann stattdessen davon ausgegangen werden, dass eine Verbindungsunterbrechung von dauerhafter Natur ist, wird die Ausführung der Subtransaktionen unterbrochen. Bereits beendete Subtransaktionen werden dabei nicht explizit zurückgesetzt. Dadurch wird verhindert, dass bereits belegte Ressourcen auf den lokalen Datenbanksystemen auf unbestimmte Zeit blockiert werden. Eine Transaktion kann jederzeit endgültig abgebrochen werden (Wechsel vom Zustand Unterbrochen in den Zustand Abgebrochen), wenn sie durch ihre temporäre Unterbrechung die Ausführung anderer globaler Transaktionen auf massive Weise behindert. 5.3.2.2 Analyse der Transaktionseigenschaften Subtransaktionen können lebendig (Vital) oder nicht-lebendig (NonVital) sein. Während nicht-lebendige Subtransaktionen im Falle einer Fehlersituation keinen Abbruch der übergeordneten globalen Transaktion verursachen, müssen lebendige Subtransaktion stets erfolgreich beendet werden, um die vollständige Ausführung der übergeordneten Transaktion nicht zu gefährden. Diese Zielsetzung erfordert eine strikte Durchsetzung von Atomizität und Isolation. Um Atomizität und Isolation für lebendige Transaktionen tatsächlich durchsetzen zu können, wird ein zusammen mit dem Transaktionsmodell definierter Algorithmus, der Partial Global Serialization Graph (PGSG), verwendet. Mit diesem kann am Ende jeder Lebendigkeitsphase ein Test auf Atomizität und Isolation durchgeführt werden. Danach hat die Transaktion die Garantie, dass keine Konflikte mit konkurrierenden Transaktionen auftreten, was zu einem Abbruch einer mobilen Transaktion führen würde. Aufgrund seiner Komplexität wird der PGSG-Algorithmus hier nicht vorgestellt. Zu weitergehenden Informationen sei auf die Originalliteratur verwiesen [Dir00]. Unabhängig davon kann eine Transaktion jederzeit weitere nicht-lebendige Subtransaktionen initiieren, da dies keine unmittelbaren Auswirkungen auf die Ausführung einer Transaktion hat. Im Falle von Fehlern führen die Subtransaktionen zu keinem Abbruch der übergeordneten Transaktion.

126

■ ■ ■

5 Mobile Transaktionen

5.3.2.3 Bewertung Bei den PS-Transaktionen handelt es sich um ein effizientes mobiles Transaktionsmodell, das trotz seiner Ähnlichkeit zu den KangarooTransaktionen den Disconnected Mode mobiler Einheiten in einem begrenzten Umfang unterstützt. Zwar kann im Disconnected Mode nicht auf lokal replizierten Daten gearbeitet werden, allerdings führt der Abbruch einer Netzwerkverbindung auch nicht sofort zu einem Abbruch der Ausführung bereits initiierter Transaktionen. Der Nachteil dieses Verfahrens ist jedoch seine Komplexität, insbesondere die des PGSG-Algorithmus’.

5.3.3 Offen-geschachtelte Transaktionen Auch das Transaktionsmodell der offen-geschachtelten Transaktionen [Chr93, Ser02] unterstützt wie Kangaroo-Transaktionen lediglich den Connnected Mode mobiler Clients. Offen-geschachtelte Transaktionen werden für gewöhnlich in Client/Server-Umgebungen eingesetzt. Auf den mobilen Clients sind dabei durchaus Installationen mobiler Datenbanksysteme vorgesehen. Dieses Transaktionsmodell setzt sich vor allem zwei Ziele. Einerseits sollen so viele Datenbankoperationen einer Transaktion wie möglich direkt auf den Datenbankserver verlagert werden, andererseits soll die Verfügbarkeit von Daten (die zum Zeitpunkt eines Transaktionszugriffs für andere Transaktionen gesperrt sind) durch einen frühen Abschluss von Teiltransaktionen erhöht werden. Grundsätzlich werden alle Transaktionen auf dem Datenbankserver ausgeführt und mit COMMIT abgeschlossen. Dies erfordert intensive Kommunikation zwischen Client und Datenbankserver über die Basisstationen. Die Auswirkungen von Transaktionen sind auf dem Datenbankserver für andere Transaktionen erst nach dem COMMIT sichtbar. 5.3.3.1 Konzepte der Ausführung Eine Transaktion wird als eine Folge von Datenbankoperationen bzw. Teiltransaktionen definiert. Jede Teiltransaktion wird auch als Transaktionskomponente bezeichnet. Eine mobile Transaktion t besteht aus m verschiedenen Transaktionskomponenten t1, ... , tm. Schachtelungen beliebiger Tiefe sind möglich. Teiltransaktionen können kompensierbar, also zurücksetzbar sein, müssen es aber nicht. Die für eine Kompensation der Auswirkungen einer Teiltrans-

5.3 Transaktionsmodelle der Klasse 1

■ ■ ■

127

aktion notwendige Kompensationstransaktion wird mit comp_ti bezeichnet. Kompensationstransaktionen machen Teiltransaktionen lediglich semantisch rückgängig, ohne dass dabei die Wiederherstellung des gleichen Datenbankzustandes zu garantieren, wie er vor der Durchführung der Teiltransaktion vorhanden war. Teiltransaktionen können unabhängig von anderen Teiltransaktionen frühzeitig mit COMMIT abgeschlossen werden, müssen aber bis zum Ende der Globaltransaktion rücksetzbar sein. Teiltransaktionen werden stets serverseitig ausgeführt. Es werden verschiedene Typen von Teiltransaktionen unterschieden. Atomare Teiltransaktionen untergliedern sich in kompensierbare und kompensierende Teiltransaktionen (Kompensationstransaktionen). Atomare Teiltransaktionen sind immer zurücksetzbar, wobei Kompensationstransaktionen aus Konsistenzgründen immer in umgekehrter Reihenfolge zur Abfolge ihrer korrespondierenden kompensierbaren Teiltransaktionen ausgeführt werden müssen. Den atomaren Transaktionen stehen die nicht-kompensierbaren Teiltransaktionen gegenüber. Diese können durch keine Kompensationstransaktion rückgängig gemacht werden. Zwar können auch sie mit COMMIT vorzeitig beendet werden, ihre Änderungen dürfen jedoch nicht dauerhaft gemacht werden, da sie sonst nicht rückgängig gemacht werden können. Stattdessen werden nach erfolgtem COMMIT die von der Teiltransaktion ausgeführten Operationen direkt an die übergeordnete globale Transaktion delegiert. Unter Delegation versteht man dabei die Möglichkeit einer Teiltransaktion ta, die Verantwortung über ABORT oder COMMIT an eine andere Teiltransaktion tb weiterzureichen. So kann die Illusion geschaffen werden, als ob Teiltransaktion tb und nicht Teiltransaktion ta die Operationen ausgeführt hat. Erst mit dem COMMIT der übergeordneten Transaktion werden auch die Auswirkungen nichtkompensierbarer Teiltransaktionen, die ihr COMMIT delegiert haben, endgültig in die Datenbank eingebracht. Daneben wird noch zwischen berichtenden Teiltransaktionen (Reporting-Transactions) und mitwirkenden Teiltransaktionen (CoTransactions) Transaktionen unterschieden. Erstere erlauben es, Zwischenergebnisse zu einem beliebigen Zeitpunkt (sicher aber zum Zeitpunkt des COMMIT) während der Ausführung an die übergeordnete Transaktion zu delegieren. Die Letzteren sind eine spezielle Variante berichtender Teiltransaktionen. Der Unterschied liegt vor allem in der Behandlung der Delegation und der damit verbundenen Verantwortlichkeiten. Mit der Delegation von Zwischenergebnissen an eine andere Transaktion erfolgt in diesem Fall auch die Übergabe der Ausführungskontrolle. Nach Abgabe der Kontrolle setzt eine

128

■ ■ ■

5 Mobile Transaktionen

mitwirkende Teiltransaktion ihre Ausführung dabei solange aus, bis sie die Kontrolle von der Transaktion, an die zuvor die Kontrolle delegiert wurde, erneut zugeteilt bekommt. Dadurch ist es mitwirkenden Teiltransaktionen möglich, ihren Zustand über die Ausführung mehrerer anschließender Teiltransaktionen hinweg behalten. In mobilen Umgebungen ist der aufeinander abgestimmte Einsatz berichtender und mitwirkender Teiltransaktionen entscheidend. Mitwirkende Teiltransaktionen können dabei aus mehreren berichtenden Transaktionskomponenten bestehen. Dabei kommt es zu einer Delegation von Zwischenergebnissen der berichtenden an die mitwirkenden Transaktionskomponenten. Bricht eine mitwirkende Teiltransaktionskomponente ab, müssen die zugehörigen berichtenden Teiltransaktionen ebenfalls abgebrochen werden (Abbruchabhängigkeit). Dies hat die Konsequenz, dass die von einer berichtenden Transaktion vorgenommenen Änderungen erst dann festgeschrieben werden, wenn alle mitwirkenden Teiltransaktionen mit COMMIT abschließen. Gleichzeitig besteht für mitwirkende Teiltransaktionen eine zwingende COMMIT-Abhängigkeit. Diese führt dazu, dass eine berichtende Transaktion mit COMMIT beendet wird, sobald die mitwirkende Teiltransaktion ebenfalls mit COMMIT abschließt. Zusammenfassen lassen sich beide Abhängigkeiten mit der Aussage, dass entweder beide Transaktionskomponenten zusammen (also berichtende und mitwirkende Teiltransaktionen), oder keine mit COMMIT beendet werden. 5.3.3.2 Analyse der Transaktionseigenschaften In diesem Abschnitt wird untersucht, welche Aussagen das Transaktionsmodell der offen-geschachtelten Transaktionen bezüglich der Durchsetzung des ACID-Prinzips erlaubt: ■

Atomizität (Atomicity). Dadurch, dass Teiltransaktionen bereits frühzeitig mit COMMIT beendet werden können, ist die Durchsetzung von Atomizität für globale Transaktionen nicht in jedem Fall gegeben. Für Teiltransaktionen kann Atomizität dagegen stets garantiert werden.

■

Konsistenz (Consistency). Die Durchsetzung der Konsistenz ist durch die Delegation und das Konzept der kompensierbaren Transaktionen in jedem Fall garantiert.

■

Isolation. Durch das vorzeitige COMMIT von Teiltransaktionen sind Änderungen frühzeitig sichtbar. Die Eigenschaft der Isolation ist aber gerade dafür zuständig, die Sichtbarkeit von Zwischenergebnissen einer Transaktion zu verhindern. Als Konse-

5.3 Transaktionsmodelle der Klasse 1

■ ■ ■

129

quenz der Nicht-Durchsetzbarkeit von Isolation kann es zu Dirty Reads kommen, bei denen die Ergebnisse von Teiltransaktionen bereits von anderen Transaktionen genutzt werden, bevor die globale, übergeordnete Transaktion überhaupt beendet ist. ■

Dauerhaftigkeit (Durability). Wird davon ausgegangen, dass das Zurücksetzen von bereits beendeten Teil-Transaktionen durch kompensierende Transaktionen zu keiner Verletzung der Dauerhaftigkeit führt, ist diese bei offen-geschachtelten Transaktionen stets garantiert.

5.3.3.3 Bewertung Als einzige Anforderung dieses Transaktionsmodells wird die Kompensierbarkeit einiger Teiltransaktionen gefordert. Darüber hinausgehende Anforderungen an die Transaktionen oder die Daten existieren nicht. Dadurch wird grosse Flexibilität erreicht, die einen Einsatz dieses Transaktionsmodells in unterschiedlichen Szenarien mobiler Datenverarbeitung zulässt. Der Disconnected Mode mobiler Clients wird nicht unterstützt, was die Einsatzmöglichkeiten auf der anderen Seite aber wieder stark einschränkt.

5.3.4 Prewrite-Transaktionen Eine Prewrite-Transaktion [Mad01, Ser02] ist eine sich über die gesamte Anwendungsnutzung erstreckende, langlebende Transaktion, deren Ausführung den Disconnected Mode mobiler Clients nicht unterstützt. Der Einsatz von Replikation und schwach-verbundener mobiler Datenbanksysteme ist dagegen vorgesehen. Die Idee dieses Transaktionsmodells ist die Aufsplittung der Ausführung einer Transaktion zwischen mobilem Client und Datenbankserver. Eine Transaktion wird dabei in jedem Fall auf den replizierten Daten auf einem mobilen Client ausgeführt. Ein spezieller Transaktionsmanager sorgt dafür, dass durchgeführte Änderungen nach ihrer lokalen Beendigung sofort an den zentralen Datenbankserver weitergereicht und auf diesem nachgeführt werden. Dem vorläufigen Charakter einer solchen zunächst client-, dann serverseitigen Transaktionsausführung wird durch die Bereitstellung spezifischer Datenbankoperationen (PREWRITE, PREREAD und PRECOMMIT) Rechnung getragen. Alle diese Operationen werden durch das mobile Datenbanksystem ausgeführt und führen zu einem stets vorläufigen Datenbankzustand. Mit dem clientseitigen PRECOMMIT wird eine Transaktion an den Datenbankserver übermittelt und auf diesem

130

■ ■ ■

5 Mobile Transaktionen

durch einen Data Manager nachgeführt (und dadurch endgültig geschrieben). Die Ausführung von Prewrite-Transaktionen gliedert sich also immer in zwei Phasen. In einer ersten Phase werden auf lokal gehaltenen Daten die gewünschten Operationen ausgeführt. Jede Transaktion wird mit einem vorläufigen PRECOMMIT beendet. Unmittelbar danach werden auf dem entfernten Datenbankserver Sperren für die von einer Transaktion geänderten Daten angefordert. Mit Bestätigung der Verfügbarkeit der Sperren wird die Transaktion auf den Datenbankserver übertragen, auf diesem nachvollzogen und danach endgültig mit COMMIT beendet. Erst ab diesem Zeitpunkt sind die auf dem mobilen Client durchgeführten Änderungen für andere Transaktionen sichtbar. Durch den Einsatz von Sperren können Konflikte auf dem Datenbankserver vermieden werden. Gleichzeitig leidet allerdings die Verfügbarkeit der Daten. Ist eine Sperre nicht innerhalb einer festgelegten Zeitspanne verfügbar, so dass eine Transaktion auf dem Datenbankserver eingebracht werden kann, muss die weitere clientseitige Transaktionsverarbeitung unterbrochen werden. 5.3.4.1 Analyse der Transaktionseigenschaften Das Transaktionsmodell der Prewrite-Transaktionen garantiert die ACID-Prinzipien vollständig. Atomizität ist sowohl für die vorläufigen als auch für die auf dem Datenbankserver nachgezogenen Transaktionen stets gegeben. Gleiches gilt für die anderen Eigenschaften. Der Grund dafür liegt in den strikten Anforderungen dieses Transaktionsmodells. Jede Transaktion muss zwingend auf dem Datenbankserver nachgezogen und dort mit COMMIT beendet werden. Dies ist nur dann möglich, wenn entsprechende Sperren auf dem Datenbankserver gesetzt werden konnten. Andernfalls wird die bereits mit PRECOMMIT beendete Transaktion zurückgesetzt werden. In jedem Fall können die ACID-Prinzipien somit strikt durchgesetzt werden. 5.3.4.2 Bewertung Das Transaktionsmodell setzt keine spezifischen Datenbanksystemarchitekturen voraus – wenn auch in den meisten Fällen eine Client/Server-Architektur am sinnvollsten erscheint. Ein erheblicher Nachteil kann die Verwendung von serverseitigen Sperren sein. Wenn es zu Einbringungskonflikten kommt, sinkt der clientseitige Transaktionsdurchsatz drastisch, dagegen bedeutet es eine serverseitige Reduktion des Transaktionsdurchsatzes, wenn Sperren längere

5.3 Transaktionsmodelle der Klasse 1

■ ■ ■

131

Zeit gesetzt sind. Die Performanzeigenschaften dieses Transaktionsmodells sind denn auch vergleichsweise schlecht.

5.4 Transaktionsmodelle der Klasse 2 Neben den bereits vorgestellten Transaktionsmodellen der Klasse 1 existieren Transaktionsmodelle der Klasse 2. Diese sind speziell für einen Einsatz in temporär verbindungslosen mobilen Umgebungen konzipiert und zeichnen sich vor allem durch eine Unterstützung des Disconnected Mode aus. Gerade dies vereinfacht den Einsatz mobiler Datenbanktechnologie wesentlich. Die wichtigsten Transaktionsmodelle dieser zweiten Klasse von Transaktionsmodellen werden in den nächsten Abschnitten vorgestellt und bewertet.

5.4.1 Provisorische Transaktionen Das Ziel des Transaktionsmodells der provisorischen Transaktionen [Gra96, Hoe01, Ser02] ist es, mobilen Clients während einer Offline-Phase eine fortgesetzte Transaktionsausführung auf lokal replizierten Daten zu erlauben. Provisorische Transaktionen weisen dabei grosse Ähnlichkeiten zu den zuvor vorgestellten PrewriteTransaktionen auf. Der wichtigste Unterschied besteht darin, dass nicht nach jeder einzelnen Transaktion eine Verbindung zu einem zentralen Datenbankserver aufgebaut werden muss. Vielmehr können beliebig viele Transaktionen auf einem mobilen Client ausgeführt werden, bevor dieser irgendwann die durchgeführten Änderungen auf dem Datenbankserver einbringt. Je länger die Offline-Phase und je höher die Anzahl der ausgeführten Transaktionen, desto höher ist auch die Wahrscheinlichkeit, dass es zu Einbringungskonflikten kommt. Dieses Transaktionsmodell wird auch als 2-Phasen-Replikation oder Bayou-Transaktionsmodell 10 bezeichnet. Provisorische Transaktionen sind eines der wenigen Transaktionskonzepte, das in kommerziellen Produkten Verwendung findet (auch in Varianten).

10 Ein Prototyp – das Bayou-System [Dem94] –, der wiederum das Transaktionsmodell [Ser02, Hoe01] verwendet, wurde von 1993 bis 1997 am Xerox Palo Alto Research Center entwickelt und implementiert

132

■ ■ ■

5 Mobile Transaktionen

5.4.1.1 Konzepte der Ausführung Provisorische Transaktionen sind eine Weiterentwicklung des Master-Replikationsschemas, bei dem jedem in einer Replikationsumgebung auftretenden Replikat ein dedizierter Host im Festnetz als Besitzer (Master) zugewiesen wird. Dieses wiederum ist eine Variante der Primary-Replikationsverfahren. Einzig der Master besitzt das Recht, Änderungen auf einem Replikat endgültig zu manifestieren, das heisst zu schreiben – nachdem eine Änderung lokal bereits durchgeführt wurde. Der Prozess der Zuordnung von Replikaten zu Mastern erfolgt dynamisch und ist keinen festen Regeln unterworfen. Wenn wir im Folgenden eine Client/Server-Architektur zugrunde legen, können wir von nur einem Master, referenziert als Datenbankserver, ausgehen (obwohl auch der Einsatz mehrerer Server, die als Master fungieren, möglich ist11). Während bestehender Offline-Phasen können mobile Clients auf den lokal verfügbaren, replizierten Daten beliebige Transaktionen ausführen. Eine Kommunikation zwischen Datenbankserver und Client ist dabei nicht notwendig (vgl. Abschnitt 5.3.4 zu PrewriteTransaktionen). Das clientseitige mobile Datenbanksystem stellt über ein lokales Transaktionsmanagement die notwendige Transaktionssicherheit bereit, die für lokal ausgeführte Transaktionen eine strikte Durchsetzung der ACID-Eigenschaften garantiert. Clientseitig mit COMMIT beendete Transaktionen besitzen jedoch einen rein provisorischen Charakter und werden deswegen als provisorische Transaktionen (Tentative Transactions) bezeichnet. Provisorische Transaktionen führen immer zu provisorischen Versionen (Tentative Versions) der durch die lokalen Transaktionen geänderten Daten. Um die lokal durchgeführten Transaktionen auf dem Datenbankserver (der Replikationsquelle) wieder einzubringen, werden die provisorischen Transaktionen als Basistransaktionen (Base Transactions) auf den Daten (Base Versions) des Datenbankservers erneut ausgeführt. Dazu ist es erforderlich, alle clientseitig durchgeführten Transaktionen systematisch und geeignet zu protokollieren. Da die Basistransaktionen dabei auf einem anderen, dem serverseitigen Datenbestand ausgeführt werden, kann eine Basistransaktion zu einem

Ursprung

11

Dabei werden die Server in Primär- und Sekundärserver unterteilt, die beide jeweils komplette Kopien der zentralen Datenbank (Replikationsquelle) vorhalten. Die Sekundärserver agieren als Middleware-Komponenten, die für die Weiterleitung der Änderungen provisorischer Transaktionen an die Primärserver zuständig sind. Die Primärserver stellen die Besitzer von Datenelementen dar, die Änderungen auf diesen endgültig schreiben dürfen. Die auf den Servern vorgehaltenen Kopien der zentralen Datenbank müssen untereinander konsistent gehalten werden, wozu verschiedene Verfahren eingesetzt werden können (vgl. Kapitel 4).

5.4 Transaktionsmodelle der Klasse 2

■ ■ ■

133

anderen, unerwarteten Ergebnis und somit zu einem inkonsistenten Datenbankzustand führen. Um solche Konfliktsituationen zu erkennen, muss deshalb vor der Ausführung einer Basistransaktion und dem endgültigen Schreiben von Änderungen ein Test durchgeführt werden, der die zu erwartende Basistransaktion auf Korrektheit und Verträglichkeit mit den serverseitigen Daten überprüft und mögliche Konflikte erkennt. Ein solcher Test kann mit Hilfe des Akzeptanzkriteriums durchgeführt werden. Dieses definiert anwendungsspezifische Regeln, die strikt eingehalten werden müssen, damit eine Basistransaktion zu einem korrekten Ergebnis führt. Bei einer Verletzung des Akzeptanzkriteriums muss auf dem Datenbankserver eine Konfliktauflösung versucht werden. Abb. 5.6: Funktionsweise provisorischer Transaktionen

Das Akzeptanzkriterium für die Konflikterkennung kann über Abhängigkeitsmengen implementiert werden. Diese bestehen aus einer Sammlung spezifischer Datenbankanfragen und deren Ergebnissen. Ein Konflikt ist erkannt, wenn die Ausführung der in der Abhängigkeitsmenge spezifizierten Datenbankanfragen nicht das erwartete, Ergebnis liefert. Abhängigkeitsmengen werden für jede Anwendung einzeln implementiert. Die Überprüfung des Akzeptanzkriteriums erfolgt immer auf dem Datenbankserver. Für die Auflösung von Konflikten werden spezielle semantische Informationen wie Zeitstempel verwendet. Zeitstempel können mehrere parallel eingebrachte provisorische Transaktionen in die richtige Reihenfolge bringen. Andere Konfliktlösungsmethoden definieren andere, teils automatische, teils manuelle Vorgehensweisen zur Konfliktauflösung, die sich die Semantik von Daten und Transaktionen zunutze machen. Das Ziel aller Methoden ist das Finden einer alternativen Reihenfolge der eingebrachten provisorischen Transaktionen, so dass deren Ausführung als Basistransaktion zu keinem Konflikt mehr führt. Oft können automatisierte semantikbasierte Konfliktauflösungsmethoden keine Garantie dafür geben, dass auch tatsächlich alle Konflikte aufgelöst werden können, so dass unter Umständen auch ein manuelles Eingreifen notwendig sein kann. Kommt es bei der Einbringung provisorischer Transaktionen auf dem Datenbankserver aber zu Konflikten, kann Atomizität unter Umständen nicht mehr garantiert werden, da Konfliktauflösungsmethoden beispielsweise Teilausführungen einer provisorischen Transaktion als

134

■ ■ ■

5 Mobile Transaktionen

Basistransaktion vorsehen können. In diesem Fall werden einzelne Teile einer provisorischen Transaktion als Basistransaktion ausgeführt, andere Bestandteile werden zurückgewiesen und zu einem späteren Zeitpunkt eingebracht. Das Transaktionsmodell der provisorischen Transaktionen kann auch in mobilen Umgebungen auch zusammen mit verteilten Datenbanken eingesetzt werden. Um zu verhindern, dass mobile Knoten als Master eines Replikats fungieren, wird das Konzept des Gültigkeitsbereichs einer Transaktion (Transaction Scope) eingeführt. Dieses Konzept soll garantieren, dass Clients ausschließlich diejenigen lokalen Daten ändern, deren Besitzer ein Knoten im Festnetz oder der mobile Knoten selbst ist. Dadurch wird vermieden, dass mobile Knoten anderen Knoten gegenüber als Replikationsquelle auftreten. 5.4.1.2 Analyse der Transaktionseigenschaften Bezüglich der Durchsetzung des ACID-Prinzips ergibt sich damit für provisorische Transaktionen: ■

Atomizität (Atomicity). Auf einem mobilen Client ausgeführte Transaktionen werden in Offline-Phasen zunächst nur provisorisch mit COMMIT abgeschlossen. Atomizität wird dabei clientseitige auf jeden Fall durchgesetzt. Wenn es zu keinen Konflikten kommt, kann Atomizität stets durchgesetzt werden.

■

Konsistenz (Consistency). Die clientseitige Datenkonsistenz ist zu keinem Zeitpunkt gefährdet, da provisorische Transaktionen durch das lokale Transaktionsmanagement in jedem Fall einen konsistenten Datenbankzustand in einen anderen konsistenten Datenbankzustand überführen. Durch die Erkennung von Wiedereinbringungskonflikten über ein Akzeptanzkriterium und durchgeführte Konfliktauflösungen führen auch Basistransaktionen immer wieder zu einem konsistenten Datenbankzustand. Selbst für den Fall, dass der durch eine eingebrachte provisorische Transaktion verursachte Konflikt nicht aufgelöst werden kann, wird die Konsistenz garantiert, da dann die provisorische Transaktion clientseitig zurückgesetzt wird.

■

Isolation. Isolation kann nur in eingeschränktem Umfang durchgesetzt werden, da die von einer provisorischen Transaktion durchgeführten Änderungen auf dem Datenbestand mobiler Clients nach dem lokalen COMMIT sofort für andere, ebenfalls noch provisorische Transaktionen sichtbar sind. Diese Sichtbarkeit ist in jedem Fall gegeben, auch wenn die durchgeführten Änderungen serverseitig noch nicht als Basistransaktion nach-

5.4 Transaktionsmodelle der Klasse 2

■ ■ ■

135

gezogen wurden. Die Forderung nach Isolation ist in diesem Fall also verletzt. ■

Dauerhaftigkeit (Durability). Für auf den mobilen Clients durchgeführte provisorische Transaktionen kann Dauerhaftigkeit nicht in jedem Fall garantiert werden. Denn wenn es bei der Einbringung provisorischer Transaktionen auf dem Datenbankserver zu Konflikten kommt, kann die Konfliktauflösungsprozedur eine teilweise oder komplette Zurücksetzung dieser provisorischen Transaktionen verlangen. Dauerhaftigkeit ist nur für diejenigen provisorischen Transaktionen garantiert, die als Basistransaktion auf dem Datenbankserver mit COMMIT beendet werden.

Clientseitige Anwendungen müssen damit immer berücksichtigen, dass sie im Disconnected Mode auf potentiell inkonsistenten bzw. nicht validierten Daten arbeiten. Selbst wenn Daten nicht geändert werden, greifen doch auch Lesetransaktionen immer nur auf schwach konsistente Daten zu. 5.4.1.3 Bewertung Das Modell der provisorischen Transaktionen implementiert ein in seinen Basiskonzepten sehr einfaches Transaktionsmodell, welches jedoch durch zusätzliche Mechanismen und Verfeinerungen schnell an Komplexität gewinnen kann. An die Daten und Transaktionen auf den Clients werden keine spezifischen Anforderungen gestellt, was zu einer großen Flexibilität und variablen Einsatzmöglichkeiten führt. Der Disconnected Mode wird unterstützt, allerdings mit der Folge, dass es im Zuge der Einbringung von provisorischen Transaktionen auf dem Datenbankserver zu Konflikten kommen kann. Mobile Anwendungen müssen somit auch stets berücksichtigen, dass alle provisorischen Transaktionen zunächst immer auf schwach konsistenten Daten erfolgen.

5.4.2 Semantische Transaktionen Motivation

136

■ ■ ■

Auch die semantischen Transaktionen [Chr95, Ser02] unterstützen wie die provisorischen Transaktionen zuvor die Transaktionsausführung im Disconnected Mode. Das Ziel dieses Transaktionsmodells ist vor allem die Reduzierung des Kommunikationsbedarfs zwischen mobilen Clients und Datenbankserver. Wie immer in Transaktionsmodellen, die eine Transaktionsausführung in Offline-Phasen erlau-

5 Mobile Transaktionen

ben, kann es zu Synchronisationskonflikten kommen, für deren Erkennung und Auflösung der Datenbankserver verantwortlich ist. Die Einführung von zwei neuen, semantikbasierten Konzepten versucht jedoch die frühzeitige Vermeidung bzw. Reduzierung von Konflikten. 5.4.2.1 Konzepte der Ausführung Das erste semantikbasierte Konzept basiert auf einer effizienten und intelligenten Fragmentierung der serverseitigen Daten (also beispielsweise einer Tabelle) in kleinere Objektfragmente spezifischer Granularität, die dann auf Clients repliziert werden. Grundlegende Eigenschaften gelten sowohl für ein Gesamtobjekt als auch für dessen Fragmente. Durch eine intelligente Fragmentierung und die anschließende Replikation der Fragmente auf mobile Clients soll es bei der späteren Wiedereinbringung nur noch zu wenigen Konflikten kommen. Je feiner die Granularität und je kleiner die Anzahl von Clients, auf die ein einzelnes Fragment repliziert wird, desto unwahrscheinlicher ist es, dass es zu Konfliktsituationen kommt. Objektfragmente, die günstige Konfliktprognosen aufweisen, werden als unkritische Objektfragmente bezeichnet. Unkritische Objektfragmente sind also Datenobjekte, für die Synchronisationskonflikte unwahrscheinlich sind bzw. diese sogar ganz vermeiden. Um unkritische Objektfragmente zu generieren, werden im Rahmen des Fragmentierungsprozesses verschiedene semantische Informationen, wie die Tabellengröße oder die Attributanzahl eines Tupels genutzt. Replizierte Objektfragmente können als Grundeinheit der Konsistenz dieses Transaktionsmodells angesehen werden. Um Konsistenz beliebigen Grades durchzusetzen, können für einzelne Objektfragmente zusätzliche Konsistenzbedingungen formuliert werden. Als zweites neues Konzept wird auf die Umsortierbarkeit zurückgegriffen, die auf der Kommutativität von Datenbankoperationen basiert. Der Einsatz dieses Konzeptes zielt auf eine Reduzierung bzw. Vermeidung von Abhängigkeiten zwischen den auf Replikaten durchgeführten Operationen. Dies soll zu einer höheren Verfügbarkeit der Daten führen, da Transaktionen sich weniger häufig gegenseitig in ihrer Ausführung blockieren. Von kommutativen Datenbankoperationen spricht man dann, wenn die Auswirkungen einer Menge von Operationen auf den Zustand eines Objekts von der Ausführungsreihenfolge der Operationen unabhängig sind. In einem solchen Fall muss jede Ausführungsreihenfolge immer zu dem gleichen Ergebnis führen. Der Vorteil dieses Konzeptes ist groß. Wenn alle Datenbankoperationen von

5.4 Transaktionsmodelle der Klasse 2

Fragmentierbarkeit

Objektfragmente

Einheit der Konsistenz

Umsortierbarkeit

Kommutative Datenbankoperationen

■ ■ ■

137

Transaktionen, die auf einem replizierten Objektfragment ausgeführt werden sollen, kommutativ sind, kann der konkrete Schedule zur Transaktionsausführung so angepasst werden, dass mögliche erfolgskritische Abhängigkeiten zwischen einzelnen Datenbankoperationen bzw. Transaktionen vermieden werden. Relevanz

Methoden zur Fragmentierung SPLIT

Objektfragmente sind die Basiseinheit der Konsistenz innerhalb der Replikationsumgebung. Für grosse und komplexe Datenobjekte wird nun versucht, diese in möglichst unkritische Objektfragmente zu zerlegen. Jedes Objektfragment kann dabei auf beliebig viele mobile Clients repliziert werden. Ziel ist vor allem eine möglichst intelligente Replikation in dem Sinn, dass nur diejenigen Objektfragmente repliziert werden, die aus der Warte des Clients relevant sind. Ein zu fragmentierendes, großes Datenobjekt wird als ein Objekt definiert, das um die zwei folgenden Methoden ergänzt wird: ■

SPLIT-Methode. Die SPLIT-Methode implementiert die Aufteilung eines Datenobjektes in kleinere Objektfragmente. Fragmentierung kann logisch oder physisch erfolgen. Bei der logischen Fragmentierung wird ein Datenobjekt anhand logischer Vorgaben, wie beispielsweise zusammengehöriger Tupel, aufgeteilt. Bei der physischen Fragmentierung ist die Zerlegung durch die tatsächliche physische Speicherung eines Objektes bestimmt. Die Granularität von Objektfragmenten wird durch ein spezielles Auswahlkriterium bestimmt, um bestimmte Konsistenzeigenschaften durchzusetzen können zusätzlich Konsistenzbedingungen spezifiziert werden. Über das Auswahlkriterium werden zunächst das zu replizierende Datenobjekt (und dessen Größe) bestimmt. Mit der Replikation auf einen oder mehrere Clients wird ein Objektfragment logisch gesehen aus dem Datenbestand des Datenbankservers entfernt (Check-Out). Danach ist das Objektfragment dann auch nur noch clientseitig verfügbar. Konsistenzbedingungen legen für jedes replizierte Objektfragment fest, welchen Einschränkungen es, was seine Verarbeitung auf dem Client anbelangt, unterworfen ist. Konsistenzbedingungen sind beispielsweise erlaubte Operationen oder spezielle Anforderungen an Struktur und Wertebereich einzelner Eingabeparameter. Objekt

138

■ ■ ■

Fragment 2

5 Mobile Transaktionen

Fragment 3

SPLIT

Fragment 1

MERGE

Abb. 5.7: Fragmentierung eines Objektes

■

MERGE-Methode. Die MERGE-Methode ist für die Integration von Objektfragmente in den Datenbestand des Datenbankservers zuständig. Bei dieser Prozedur können Konflikte auftreten, die serverseitig durch adäquate Auflösungsmethoden behandelt werden müssen. Bezüglich der genauen Vorgehensweise zur Konfliktauflösung macht das Transaktionsmodell der semantischen Transaktionen jedoch keine Vorgaben. Durch logische Fragmentierung entstandene Objektfragmente werden durch ebenfalls logische Operationen wieder integriert. Durch physische Fragmentierung entstandene Objektfragmente werden durch ebenfalls physische Operationen wieder auf dem Datenbankserver eingebracht.

Wie der Name des Transaktionsmodells schon andeutet, werden im Vergleich zu den vorherigen Transaktionskonzepten durchaus Anforderungen an die durch Transaktionen zugegriffenen Daten gestellt. Diese Anforderungen müssen genügen, um zusätzliche semantische Metadaten generieren zu können, die die Konzepte der Fragmentierbarkeit und der Umsortierbarkeit unterstützen. Semantische Metadaten beschreiben dabei vor allem die Bedeutung und die Zusammenhänge von bzw. zwischen den tatsächlichen Anwendungsdaten. Beispiele solcher semantischer Metainformationen sind: ■

Aufbau eines Objektes. Welche Unterschiede sind zwischen der abstrakten, logischen Organisation eines Objektes und seiner physischen Ablage im Speicher zu erkennen?

■

Objektnutzung. Auf welche Weise werden Objekte genutzt und wie können diese Informationen verwendet werden?

■

Semantik von Operationen. Welche Auswirkungen hat die Ausführung einer Operation auf den Zustand eines Objektfragmentes? Welche Seiteneffekte sind erkennbar?

■

Eingabe-/Ausgabewerte von Operationen. Welche Rolle spielt der Informationsfluss zu und von einem Objektfragment und was kann in Bezug auf die Interpretation dieser Ein- und Ausgabewerte gesagt werden?

Kommt es zu Konflikten, können wie zuvor bei den provisorischen Transaktionen automatische oder manuelle Auflösungsmethoden definiert werden. Gelingt es nicht, einen Konflikt adäquat zu beheben, verbleibt als letzte Möglichkeit die Zurücksetzung clientseitig ausgeführter Transaktionen. Zwar kann durch den Einsatz von herkömmlichen Sperrverfahren das Auftreten von Konflikten komplett ver-

5.4 Transaktionsmodelle der Klasse 2

Semantische Metadaten

Konfliktauflösung

■ ■ ■

139

hindert werden, allerdings leidet in einem solchen Fall die Performanz eines Systems erheblich. 5.4.2.2 Analyse der Transaktionseigenschaften Abschließend wird noch untersucht, welche Aussagen das Transaktionsmodell der semantischen Transaktionen bezüglich der Durchsetzung des ACID-Prinzips erlaubt:

140

■ ■ ■

■

Atomizität (Atomicity). Im Disconnected Mode wird die Atomizität von Transaktionen durch das lokale Transaktionsmanagement stets garantiert. Bei der Einbringung von Objektfragmenten auf dem Datenbankserver nach Phasen der Verbindungslosigkeit kann es aber zu Synchronisationskonflikten kommen (wenn auf Sperrverfahren verzichtet wird). Zur Auflösung von Konflikten kann eine serverseitige Änderung von Teilen clientseitig bereits durchgeführter Transaktionen notwendig sein, weshalb globale Atomizität nicht immer garantiert ist.

■

Konsistenz (Consistency). Auf den mobilen Clients wird im Disconnected Mode Konsistenz durch das lokale Transaktionsmanagement garantiert. Da bei der Reintegration von durchgeführten Änderungen auf dem Datenbankserver Synchronisationskonflikte (im Extremfall manuell) aufgelöst werden, oder eine eingebrachte Transaktion zurückgesetzt wird, kann Konsistenz auch global garantiert werden. Allerdings können durch die Möglichkeit zur Formulierung von Konsistenzbedingungen für einzelne Objektfragmente durchaus auch Konsistenzgrade eingeführt werden, die keine strikte Konsistenz durchsetzen. Prinzipiell ist dies jedoch ohne weiteres möglich.

■

Isolation. Im Disconnected Mode kann die Eigenschaft der Isolation nicht garantiert werden, da auf den mobilen Clients durchgeführte Transaktionen in Offline-Phasen für nachfolgende Transaktionen sofort sichtbar sind, obwohl diese im Zuge einer späteren Konfliktauflösung teilweise oder sogar ganz zurückgesetzt werden können.

■

Dauerhaftigkeit (Durability). Nach der Beendigung clientseitiger Transaktionen im Disconnected Mode kann Dauerhaftigkeit nicht garantiert werden, da eine Transaktion im Rahmen einer Konfliktlösung teilweise oder vollständig zurückgesetzt oder verändert werden kann.

5 Mobile Transaktionen

5.4.2.3 Bewertung Das Konzept der semantischen Transaktionen bieten einige neue Konzepte. Durch den umfassenden Einsatz der beiden Konzepte Fragmentierbarkeit und Umsortierbarkeit kann versucht werden, mögliche Konflikte von vornherein zu vermeiden. Beide Konzepte machen sich spezielle semantische Informationen über die Anwendungsdaten und die auf ihnen ausgeführten Operationen zu Nutze. Fraglich ist jedoch, in welchem Rahmen diese beiden Konzepte praktisch umzusetzen sind. Eingeschränkt wird dieses Modell durch die verlorene Flexibilität, wenn nur kommutative Datenbankoperationen eingesetzt werden müssen. In vielen Fällen wird der Einsatz semantischer Transaktionen somit erschwert bzw. muss zumindest um zusätzliche Verfahren ergänzt werden.

5.4.3 Schwache/Strikte Transaktionen Beim Modell der schwachen/strikten12 Transaktionen [Pit95, Pit99c, Ser02] wird nicht von einer Client/Server-Architektur ausgegangen, sondern von einer verteilten Datenbank. Daten sind entweder auf mobilen Knoten oder auf stationären Knoten im Festnetz verteilt. Das Ziel dieses Transaktionsmodells ist eine effiziente Konsistenzsicherung der Daten innerhalb einer Replikationsumgebung. 5.4.3.1 Konzepte der Ausführung Bei schwachen/strikten Transaktionen werden die Daten einer verteilten Datenbank zu Clustern zusammengefasst. Ein Cluster ist die Basiseinheit der Konsistenz und er besteht aus verschiedenen Knoten (einer verteilten Datenbank) und damit aus den auf diesen Knoten verfügbaren Daten. Alle Kopien eines Replikats innerhalb eines Clusters müssen strikt konsistent sein, während Kopien eines Replikats, die verschiedenen Clustern angehören, Inkonsistenzen aufweisen dürfen. Strikt konsistent bedeutet, dass alle Integritätsbedingungen, die auf den Datenobjekten eines einzelnen Clusters definiert sind (Intra-Cluster-Constraints), in jedem Fall durchgesetzt und damit gelten müssen. Integritätsbedingungen, die sich auf Datenobjekte unterschiedlicher Cluster beziehen (Inter-Cluster-Constraints), müssen dagegen nicht strikt eingehalten werden. 12

Der / wird als „oder“ oder als „bzw.“ gelesen. Die Transaktionen sind entweder schwach oder stark (= strikt).

5.4 Transaktionsmodelle der Klasse 2

■ ■ ■

141

Die Entscheidung, welche Knoten einem Cluster angehören, kann unter verschiedenen Gesichtspunkten erfolgen. In mobilen Umgebungen kann beispielsweise die Anbindung mobiler Clients an das Festnetz als Kriterium verwendet werden. So kann ein Cluster definiert werden, der aus allen permanent miteinander verbundenen Knoten besteht (mobile und stationäre Knoten). Wird ein mobiler Knoten durch einen Wechsel in den Disconnected Mode vom Cluster getrennt, bildet er ab diesem Zeitpunkt einen eigenen Cluster. Da zwischen verschiedenen Clustern Inkonsistenzen zugelassen sind, können dann auf dem mobilen Knoten Transaktionen ausgeführt werden. Wenn der mobile Knoten wieder online ist, wird der mobile Knoten erneut in den ursprünglichen Cluster integriert. Dabei müssen die während der Offline-Phase durchgeführten Änderungen eingebracht werden, um innerhalb des Clusters wieder strikte Konsistenz herzustellen. Der Vorgang der Clusterbildung und der Clusterauflösung ist flexibel. Die in mobilen Umgebungen auftretenden Verbindungsarten implizieren unterschiedliche Typen von Transaktionen, die an die jeweilige Clustersituation angepasste Konsistenzgrade aufweisen. Schwache Transaktionen (Weak Transactions) garantieren nur schwache, strikte Transaktionen (Strict Transactions) dagegen starke Konsistenz innerhalb der gesamten Replikationsumgebung. Im Disconnected Mode werden auf mobilen Knoten, die dann einen eigenständigen Cluster darstellen, schwache Transaktionen ausgeführt. Ist ein mobiler Knoten dagegen mit dem Festnetz und einem Festnetzcluster verbunden, werden starke Transaktionen ausgeführt. Die zu Clustern zusammengefassten Daten müssen keinen spezifischen Anforderungen genügen. Eine jede Transaktion wird auf m-konsistenten Daten innerhalb eines Clusters Cli ausgeführt. Der Zustand einer Datenbank wird als m-konsistent definiert, wenn in allen Clustern strikte Konsistenz gilt und alle Integritätsbedingungen, die verschiedene Cluster betreffen (Inter-Cluster-Constraints) mgradig konsistent sind. Die m-gradige Konsistenz einer Replikationsbedingung R auf einer Menge von Replikaten {x1, ... , xn} eines Datenelementes xi definiert, dass der maximal erlaubte Inkonsistenzgrad, d.h. die maximal tolerierte Werteabweichung von verschiedenen Kopien eines Replikats (die verschiedenen Clustern zugeordnet sind) m ist. Eine Wert-Abweichung kann dabei durch verschiedene Kriterien bestimmt werden (beispielsweise durch die Anzahl der voneinander abweichenden Datenelemente). Dies gilt nur zwischen den Clustern, denn befinden sich mehrere Kopien eines Replikats im gleichen Cluster, besitzen alle diese Kopien stets den gleichen Wert und sind konsistent (wegen strikter Konsistenz innerhalb eines Clusters).

142

■ ■ ■

5 Mobile Transaktionen

Damit eine mobile Anwendung im Disconnected Mode Transaktionen ausführen kann, werden die zwei Operationen schwaches Lesen (Weak Read) und schwaches Schreiben (Weak Write) eingeführt. Bei schwachen Leseoperationen wird immer die lokal verfügbare Kopie eines Datenelementes gelesen, unabhängig davon, ob der gelesene Wert einer schwachen oder eine strikten Transaktion geschrieben wurde. Schwache Schreiboperationen schreiben ihre Änderungen immer lokal, ohne dabei die Dauerhaftigkeit der Änderungen zu garantieren. Schwache Transaktionen implementieren darüber hinaus zwei verschiedene COMMIT. Ein lokales COMMIT, das nach Beendigung jeder schwachen Transaktion durchgeführt wird, und ein globales COMMIT, das nach der Zusammenführung eines mobilen Knotens mit dem Festnetz und der abgeschlossenen Wiedereinbringung durchgeführter Änderung erfolgt. Von schwachen Transaktionen ausgeführte Änderungen sind nur für andere schwache Transaktionen sichtbar. Erst mit dem globalen COMMIT werden durchgeführte Änderungen endgültig dauerhaft und auch für andere Transaktionen sichtbar. Offensichtlich kann es beim Zusammenführen von Clustern zu Konflikten kommen. Im Worst Case müssen Konflikte – falls eine automatische oder manuelle Auflösung nicht möglich war – durch die Kompensation einer schwachen Transaktion behoben werden. Können keine solchen Kompensationstransaktionen bereitgestellt werden (z.B. durch die Unterstützung entsprechender LoggingMechanismen), dürfen schwache Transaktionen nicht zugelassen werden. Wenn aber davon ausgegangen werden kann, dass das Konfliktpotential aufgrund der Anwendungscharakteristik oder der Struktur der Anwendungsdaten gering ist, kann diese Vorgabe aufgeweicht werden. Ist ein mobiler Knoten mit dem Festnetz verbunden (und somit zusammen mit anderen stationären Knoten Teil eines gemeinsamen Clusters), werden die in ihren Konsistenzanforderungen anspruchsvolleren Operationen starkes Lesen (Strict Read) und starkes Schreiben (Strict Write) verwendet. Eine Transaktion, die nur diese Operationen verwendet, wird auch als strikte Transaktion bezeichnet. Bei strikten Leseoperationen wird immer der Wert gelesen, der zuletzt von einer strikten Schreibtransaktion geändert wurde. Eine strikte Schreiboperation schreibt auf einer Kopie des Clusters, wird aber erst mit COMMIT beendet, wenn die geschriebenen Änderungen auf allen Kopien innerhalb des gleichen Clusters ebenfalls durchgeführt werden kann bzw. bereits durchgeführt wurden.

5.4 Transaktionsmodelle der Klasse 2

■ ■ ■

143

5.4.3.2 Analyse der Transaktionseigenschaften In diesem Abschnitt wird untersucht, welche Aussagen das Transaktionsmodell der schwachen/strikten Transaktionen bezüglich der Durchsetzung des ACID-Prinzips erlaubt: ■

Atomizität (Atomicity). Auf einem Cluster ausgeführte schwache Transaktionen werden mit einem lokalen COMMIT abgeschlossen. Lokale Atomizität wird in diesem Fall durch das lokale Transaktionsmanagement realisiert. Strikte Transaktionen, garantieren auch die globale Durchsetzung von Atomizität.

■

Konsistenz (Consistency). Das Transaktionsmodell definiert zwei verschiedene Formen von Konsistenz. Strikte Konsistenz, die keinerlei Inkonsistenzen zulässt und schwache Konsistenz, die gewisse Inkonsistenzen erlaubt, deren Grad m beliebig festgelegt werden kann.

■

Isolation. Die Änderungen schwacher Transaktionen sind für nachfolgende schwache Transaktionen sofort sichtbar. Für strikte Transaktionen kann dagegen Isolation stets garantiert werden.

■

Dauerhaftigkeit (Durability). Kommt es bei der Zusammenführung von Clustern zu Konflikten, müssen schwache Transaktionen unter Umständen zurückgesetzt werden. Dadurch kann die Dauerhaftigkeit schwacher Transaktionen nicht garantiert werden. Erst nach dem globalen COMMIT ist Dauerhaftigkeit sicher garantiert.

5.4.3.3 Bewertung Der mit diesem Transaktionsmodell vorgestellte Ansatz zur Konsistenzsicherung implementiert sowohl Methoden pessimistischer (für strikte Transaktionen), als auch optimistischer (für schwache Transaktionen) Replikationsverfahren. Gerade in dieser Kombination verschiedener Zielsetzungen liegt die besondere Stärke dieses Transaktionsmodells, das einen einfachen und eleganten Weg aufzeigt, die Konsistenz innerhalb mobiler Umgebungen zu garantieren.

5.4.4 Isolation-Only-Transaktionen Das Ziel des Modells der Isolation-Only-Transaktionen [Sat94] ist eine hohe Effizienz und einfache Operationen, was – und von dieser Tatsache leitet sich auch der Name des Transaktionsmodells ab –

144

■ ■ ■

5 Mobile Transaktionen

durch die alleinige Garantie der Isolation-Eigenschaft und durch einen Verzicht auf alle anderen Eigenschaften des ACID-Prinzips erreicht wird. Ähnlich wie die provisorischen Transaktionen, basiert auch dieses Transaktionsmodell auf einer zweistufigen Transaktionsverarbeitung. Firstclass-Transaktionen, die nicht auf lokal replizierte Daten zugreifen, stehen Secondclass-Transaktionen gegenüber, die im Disconnected Mode mobiler Clients auf lokal replizierten Daten ausgeführt werden. Isolation-Only-Transaktionen setzen dabei keine bestimmte Architektur des zugrunde liegenden Datenbanksystems voraus. Konsistenz von Daten kann durch dieses Modell nicht in jedem Fall garantiert werden. 5.4.4.1 Konzepte der Ausführung Firstclass-Transaktionen implizieren, dass für jeden Zugriff auf ein Datenobjekt eine Verbindung zum Datenbankserver aufgebaut wird. Alle Operationen werden dann direkt auf dem Datenbestand des Servers ausgeführt und auf diesem mit COMMIT beendet. Eingebrachte Änderungen sind sofort für andere Transaktionen sichtbar. Secondclass-Transaktionen greifen bei ihrer Ausführung auf lokal gehaltene, replizierte Daten zu. Eine Verbindung zum Datenbankserver ist nicht notwendig. Sie werden im Disconnected Mode mobiler Clients verwendet. Auswirkungen solcher Transaktionen sind für nachfolgende Transaktionen auf dem mobilen Client sofort sichtbar. Jede Secondclass-Transaktion wird lokal zunächst durch COMMIT abgeschlossen und geht danach in einen schwebenden Zustand über, in dem sie auf ihre Validierung wartet. Validiert wird gegen auf dem Datenbankserver definierte Konsistenzkriterien. Dadurch wird eine Reduzierung bzw. sogar eine Vermeidung von Synchronisationskonflikte erreicht. Ist die Validierung erfolgreich, wird die Transaktion auf dem Datenbankserver nachgeführt und dort endgültig durch COMMIT beendet. Schlägt die Validierung dagegen fehl, wechselt die Transaktion in den Zustand der Auflösung, in dem eine automatische Konfliktbehandlung versucht wird. Ist eine automatische Konfliktauflösung nicht möglich, kann als letzte Möglichkeit eine manuelle Auflösung versucht werden. Wenn Konflikte weder automatisch noch manuell aufgelöst werden können, müssen die entsprechenden Secondclass-Transaktionen zurückgesetzt werden. Das Zusammenspiel beider Transaktionstypen kann anhand eines Zustandsübergangsdiagramms (vgl. Abbildung 5.8) verdeutlicht werden. Zur Durchsetzung von Konsistenz werden insgesamt vier verschiedene Konsistenzkriterien vorgeschlagen, von denen im Folgenden die drei wichtigsten vorgestellt werden:

5.4 Transaktionsmodelle der Klasse 2

■ ■ ■

145

■

Serialisierbarkeit. Das Konsistenzkriterium der Serialisierbarkeit verlangt die strikte Serialisierbarkeit von FirstclassTransaktionen, die dann klassischen Transaktionen entsprechen.

■

Lokale Serialisierbarkeit (LSR). Das Konsistenzkriterium der lokalen Serialisierbarkeit verlangt die Serialisierbarkeit von Secondclass-Transaktionen auf mobilen Clients. Dazu werden auf den mobilen Clients konventionelle Transaktionsmodelle implementiert.

Abb. 5.8: Zustandsübergangsdiagramm [Lie01]

Ausführung

Mit Zugriff auf replizierte Daten

schwebend

Validierung fehlgeschlagen

Auflösung

Validierung erfolgreich Ohne Zugriff auf replizierte Daten ■

abgeschlossen

Automatische oder manuelle Auflösung

Globale Serialisierbarkeit (GSR). Das Konsistenzkriterium der globalen Serialisierbarkeit verlangt, dass eine schwebende Transaktion nur dann erfolgreich validiert werden kann, wenn sie in Bezug auf alle mit COMMIT beendeten Transaktionen serialisierbar ist. Der Unterschied zu den vorherigen Konsistenzkriterien ist, dass die globale Serialisierbarkeit zum Zeitpunkt der Transaktionsausführung nicht erzwungen, sondern nur durch Validierung getestet werden kann. Schlägt der Validierungsvorgang fehl, können verschiedene Konfliktlösungsmechanismen eingesetzt werden (Ausführung eines anwendungsspezifischen Auflösungsskripts, Abbruch einer Transaktion, manuelle Auflösung eines Konflikts).

5.4.4.2 Bewertung Auch dieses Transaktionsmodell implementiert genau wie die provisorischen Transaktionen und die schwachen/starken Transaktionen eine zweistufige Transaktionsverarbeitung. Vorteilhaft sind insbesondere die hohe Flexibilität und Effizienz, was allerdings durch einen Verzicht der Durchsetzung der drei ACID-Eigenschaften Atomizität, Dauerhaftigkeit und Konsistenz erkauft wird. Nur die Isolation-Eigenschaft wird strikt durchgesetzt. Zwar können auch die anderen ACID-Eigenschaften oft durchgesetzt werden, eine Garantie dafür gibt das Modell jedoch nicht. Der Nachteil dieses Transakti-

146

■ ■ ■

5 Mobile Transaktionen

onsmodells liegt in den hohen Anforderungen an die mobilen Clients für das Zurücksetzen von Transaktionen.

5.4.5 Promotion-Transaktionen Promotion-Transaktionen [Wal97, Wal99, Ser02] sind eine Variante geschachtelter Transaktionen, die den Disconnected Mode mobiler Clients unterstützen. Die Kernidee dieses Verfahrens ist die Ausführung einer mobilen Anwendung als einzelne, langlebende Transaktion. Das vorrangige Ziel dieses Transaktionsmodell ist dabei die garantierte Durchsetzung der Serialisierbarkeit ausgeführter Transaktionen, wobei aber auch schwächere Serialisierbarkeitskriterien akzeptiert werden. Das Modell der Promotion-Transaktionen ist für Client/Server-Architekturen konzipiert. 5.4.5.1 Konzepte der Ausführung Wie immer, wenn der Disconnected Mode mobiler Clients unterstützt werden soll, muss auch bei diesem Transaktionsmodell auf Replikation zurückgegriffen werden. Zu replizierende Daten werden dazu auf dem Datenbankserver zu Compacts zusammengefasst, die die Basiseinheit des Transaktionsmodells darstellen. Auf den mobilen Clients sind spezielle Compact Agents (CA) für die Ausführung lokaler Transaktionen in Offline-Phasen zuständig. Spätere Synchronisationsvorgänge sind als Abgleich verschiedener CompactVersionen zu verstehen. Diesbezüglich ähnelt dieses Transaktionsmodell dem bereits in Kapitel 4 vorgestellten Snapshot-Replikationsverfahren. Welche Compacts auf einen Client repliziert werden und wie die Auflösung von serverseitigen Synchronisationskonflikten erfolgt, wird durch einen Compact Manager (CM) auf dem Datenbankserver entschieden. Die Koordination des Replikationsvorganges an sich liegt in der Verantwortung zusätzlicher Mobility Manager (MM) auf den Basisstationen. Compacts bestehen aus verschiedenen Komponenten (vgl. Abbildung 5.12). Darunter fallen konkrete Anwendungsdaten, aber auch entsprechende Datenzugriffsmethoden, Zustandsinformationen, Konsistenzbedingungen, Verwaltungsmethoden und Zusicherungen bezüglich der maximalen Verweilzeit von Daten auf einem mobilen Client sowie die Sichtbarkeit von Änderungen. Letztlich ist ein Compact eine Vereinbarung zwischen Datenbankserver und mobilem Client. Die Vereinbarung definiert genau, welche Operationen im Disconnected Mode auf dem Datenbestand des Clients ausge-

5.4 Transaktionsmodelle der Klasse 2

■ ■ ■

147

führt werden dürfen. Der Server delegiert die Kontrolle vollständig an den Client, der gleichzeitig die Verpflichtung eingeht, die vorgegebenen Bedingungen auch einzuhalten. Abb. 5.9: Struktureller Aufbau eines Compacts

Statusinformationen Zusicherungen Korrektheitskriterien Gemeinsame Methoden Typspezifische Methoden

DATEN Mit der erneuten Verbindungsaufnahme zum Datenbankserver werden durch den Compact Agent des mobilen Clients alle diejenigen Compacts bestimmt, die während der vorausgehenden Offline-Phase verändert wurden. Gleichzeitig muss die Gültigkeit dieser Compacts überprüft werden, das heisst, nur wenn deren definierte Verweilzeit noch nicht überschritten ist, werden sie beim Synchronisationsvorgang berücksichtigt. Daraufhin werden die relevanten Änderungstransaktionen isoliert und an den Compact Manager des Datenbankservers weitergeleitet, der die Änderungstransaktionen auf seinem Datenbestand ausführt und so die Änderungen endgültig manifestiert. Das Ziel dieses Transaktionsmodell ist die Serialisierbarkeit aller Transaktionen. Trotzdem können schwächere Korrektheitskriterien eingesetzt werden. Dazu kann für jeden Compact ein spezifisches Korrektheitskriterium angegeben werden. Insgesamt zehn verschiedene Korrektheitskriterien implementieren einen jeweils anderen Grad der Durchsetzung der Isolation-Eigenschaft. Durch das strengste Korrektheitskriterium (Level 9) wird volle Serialisierbarkeit garantiert, während durch das niedrigste Korrektheitskriterium (Level 0) keinerlei Garantien gegeben werden. 5.4.5.2 Bewertung Bei den Promotion-Transaktionen handelt es sich um ein komplexes Transaktionsmodell für den Einsatz in mobilen Umgebungen. So müssen im Vergleich zu anderen Transaktionsmodellen diverse, spezialisierte Komponenten zur Ausführung und Administration von Transaktionen implementiert werden.

148

■ ■ ■

5 Mobile Transaktionen

5.5 Zusammenfassung In diesem Kapitel wurden neun verschiedene mobile Transaktionsmodelle in ihren Ideen und Konzepten beschrieben. Dabei wurde zwischen zwei großen Klassen von Transaktionsmodellen unterschieden. Die erste Klasse bestand aus denjenigen Transaktionsmodellen, die lediglich in Online-Szenarien eingesetzt werden können. Dazu gehören: ■

Kangaroo-Transaktionen

■

Preserialization Transaction Management Technique

■

Offen-geschachtelte Transaktionen

■

Prewrite-Transaktionen

Kangaroo-Transaktionen können in verschiedenen Architekturen eingesetzt werden. Als bislang einziges Transaktionsmodell berücksichtigen die Kangaroo-Transaktionen die Bewegung einer mobilen Transaktion (daher auch der Name des Modells). Eine Bewegung einer Transaktion tritt immer dann auf, wenn ein mobiler Client, der eine Transaktion initialisiert hat, während der Transaktionsausführung zwischen verschiedenen Funkzellen migriert, die durch verschiedene Basisstationen versorgt werden. Die Idee dabei ist, die Ausführung der Transaktion zwischen den verschiedenen Basisstationen aufzuteilen. Neue Teiltransaktionen werden dabei immer durch die aktuelle Basisstation ausgeführt, während bereits begonnene Teiltransaktionen im Verantwortungsbereich der vorherigen alten Basisstationen liegen. Die Preserialization Transaction Management Technique behandelt vor allem den Abbruch bestehender Netzwerkverbindungen in Online-Szenarien. Zwar ist es in diesem Fall möglich, die Ausführung einer Transaktion temporär zu unterbrechen, dies bedeutet jedoch nicht, dass das Modell die Transaktionsausführung im Disconnected Mode erlaubt. Transaktionen werden nur solange in ihrer Ausführung unterbrochen, als wie andere Transaktionen durch die blockierten Ressourcen (der unterbrochenen Transaktion) nicht behindert werden. Offen-geschachtelte Transaktionen setzen sich ein ähnliches Ziel wie die PSTMT-Transaktionen. So versuchen sie, durch Transaktionen belegte Systemressourcen frühzeitig wieder freizugeben.

5.5 Zusammenfassung

Transaktionsmodelle der Klasse 1

KangarooTransaktionen

Preserialization Transaction Management Technique

Offengeschachtelte Transaktionen

■ ■ ■

149

PrewriteTransaktionen

Prewrite-Transaktionen realisieren eine zweistufige Transaktionsausführung. Dabei werden Transaktionen zunächst immer auf dem lokalen Datenbestand des mobilen Clients ausgeführt. Alle durchgeführten Operationen besitzen jedoch einen rein provisorischen Charakter. Mit der Beendigung einer jeden Transaktion durch PRECOMMIT übergibt jedoch ein Transaktionsmanager die Transaktion direkt an ein zentrales Datenbanksystem, auf dem die Transaktion dann erst endgültig beendet wird. Auch in diesem Fall wird somit stets eine Netzwerkverbindung vorausgesetzt (Online-Szenario).

Transaktionsmodelle der Klasse 2

Demgegenüber steht die zweite grosse Klasse an Transaktionsmodellen. Im Gegensatz zu den zuvor vorgestellten Modellen unterstützen die Verfahren dieser Klasse den Disconnected Mode mobiler Clients. Dazu ist es insbesondere wichtig, in Phasen der Unverbundenheit eine fortgesetzte Transaktionsausführung auf lokalen Daten zu ermöglichen. Da in einem solchen Fall aber verschiedene Versionen gleicher Datenmodelle entstehen können, kann es bei der Synchronisation zu Konflikten kommen. Aus diesem Grund müssen die Transaktionsmodelle dieser Klasse allesamt Konfliktauflösungsmethoden bereitstellen. Transaktionsmodelle dieser Klasse sind:

Provisorische Transaktionen

Semantische Transaktionen

150

■ ■ ■

■

Provisorische Transaktionen

■

Semantische Transaktionen

■

Schwachen/strikten Transaktionen

■

Isolation-Only-Transaktionen

■

Promotion-Transaktionen

Provisorische Transaktionen sind ein einfaches Transaktionskonzept. Dabei werden grundsätzliche alle Transaktionen während einer Offline-Phase auf lokalen Daten des mobilen Clients ausgeführt. Während einer späteren Synchronisation wird nun versucht, die auf dem mobilen Client durchgeführten Transaktionen auch auf dem zentralen Datenbankserver nachzuvollziehen. Dabei kann es zu Konflikten kommen, die aufgelöst werden müssen. Semantische Transaktionen versuchen durch den Einsatz neuartiger Konzepte die Auftrittswahrscheinlichkeit von Synchronisationskonflikten zu reduzieren (bzw. im optimalen Fall sogar ganz zu verhindern). Grundlage des Verfahrens sind eine besonders intelligente Fragmentierbarkeit von Daten für die Replikation und die Ausnutzung semantischer Informationen.

5 Mobile Transaktionen

Das Transaktionsmodell der schwachen/strikten Transaktionen fokussiert den Einsatz in verteilten Datenbanken. Als Basiseinheit der Konsistenz innerhalb einer Replikationsumgebung werden Cluster definiert. Innerhalb eines Clusters muss stets strikte Konsistenz gelten. Daten in unterschiedlichen Clustern können dagegen auch schwach konsistent sein. Während Phasen der Unverbundenheit bildet ein mobiler Client für gewöhnlich einen eigenen Cluster. Auf diesem kann unabhängig gearbeitet werden, da zwischen ihm und den Knoten des Festnetzes, das einen weiteren Cluster repräsentiert, ja nur schwache Konsistenz gelten muss. Bei der späteren Einbindung des mobilen Clusters kann es dann allerdings zu Konflikten kommen, die aufgelöst werden müssen. Das Konzept der Isolation-Only-Transaktionen setzt sich das Ziel einer möglichst effizienten Transaktionsverarbeitung, was vor allem durch den Verzicht auf wesentliche Eigenschaften des ACIDPrinzips erreicht wird. So wird – wie der Name des Modells ja bereits andeutet – nur die Isolation-Eigenschaft des ACID-Prinzips unterstützt. Dazu wird zwischen Secondclass- und FirstclassTransaktionen unterschieden. Während Transaktionen, die in Offline-Phasen ausgeführt werden, den Status einer SecondclassTransaktion besitzen, decken Firstclass-Transaktionen den Trivialfall eines Online-Szenarios ab. Promotion-Transaktionen schließlich definieren als Basiseinheit in einer Replikationsumgebung Compacts. Clientseitig koordinieren Compact Agents die Ausführung von Transaktionen in Phasen der Unverbundenheit. Serverseitig kommt ein Compact Manager zum Einsatz, der für die Konfliktauflösung bei der Wiedereinbringung von auf Compacts durchgeführten Änderungen zuständig ist. Um Synchronisationskonflikte zu vermeiden, definiert der Compact Manager vor der Replikation eines Compacts auf einen mobilen Client eine Menge von Integritätsbedingungen. Auf dem mobilen Client dürfen dann nur solche Operationen ausgeführt werden, die mit diesen Integritätsbedingungen verträglich sind. Eine vollständige Vermeidung von Konflikten kann allerdings nicht garantiert werden.

Schwache/ Strikte Transaktionen

Es verbleibt anzumerken, dass fast alle der vorgestellten Transaktionsmodelle über eine Implementierung in Forschungsprototypen nicht hinausgekommen sind. Lediglich die provisorischen Transaktionen können für sich in Anspruch nehmen, tatsächlichen in kommerziellen Produkten umgesetzt worden zu sein. Der Grund dafür ist klar. Transaktionen der Klasse 1 spielen keine Rolle, da OnlineSzenarien in der mobilen Datenverarbeitung einfach noch nicht zuverlässig genug funktionieren. Denn die mobilen Clients bieten, be-

Implementierung

5.5 Zusammenfassung

Isolation-OnlyTransaktionen

PromotionTransaktionen

■ ■ ■

151

sonders was ihre Energiekapazitäten anbelangt, zusammen mit den noch immer fehleranfälligen drahtlosen Netzwerkinfrastrukturen keine hinreichenden Möglichkeiten wirkliche Online-Szenarien zu realisieren. Kommunikationsverbindungen sind zudem zu teuer. Dementsprechend sind es vor allem die Offline-Szenarien, also beispielsweise der mobile Zugriff auf Unternehmensnetzwerke, die enormes Einsatzpotential versprechen. Konsequenterweise unterstützen die meisten kommerziellen mobilen Datenbanksysteme auch nur Offline-Szenarien. Lediglich Oracle mit seinem Produkt Oracle Lite und die Software AG mit Tamino Mobile Suite unterstützen explizit auch browserbasierte Online-Szenarien. Innerhalb der Transaktionsmodelle von Klasse 2 sind es dabei gerade die provisorischen, die am intuitivsten nachvollziehbar sind. Die anderen Transaktionskonzepte erweisen sich jedoch als schwierig zu implementieren.

152

■ ■ ■

5 Mobile Transaktionen

6 Anfrageverarbeitung

Durch die Leistungsschwäche vieler mobiler Clients ist eine einfache Portierung des Anfragemoduls (Query-Engine) eines normalen Datenbanksystems meistens nicht möglich. Doch auch mobile Datenbanksysteme müssen in der Lage sein, komplexe Anfragen effizient und zuverlässig zu bearbeiten. Für den weiteren Verlauf dieses Kapitels gehen wir von auf relationalen Datenstrukturen ausgeführten Anfragen aus. Das Kapitel gliedert sich wie folgt: in Kapitel 6.1 werden zunächst Grundlagen der Anfrageverarbeitung in Datenbanksystemen beschrieben. In Kapitel 6.2 werden danach spezielle Anforderungen an die Anfragemodule mobiler Datenbanksysteme zusammengefasst. Kapitel 6.3 befasst sich mit einer besonderen Klasse von Anfragen in mobilen Umgebungen, den standortabhängigen Anfragen.

Motivation

6.1 Klassische Anfrageauswertung Um eine mittels einer deskriptiven Anfragesprache (beispielsweise SQL) formulierte Anfrage auszuführen, muss ein so genannter Ausführungsplan (Query Execution Plan) erstellt werden. Davon gibt es zu einer Query oft mehrere Resultatsäquivalente. Unter allen möglichen Ausführungsplänen soll eine möglichst optimale Variante ausgewählt werden. Eine solche Variante ist ein Ausführungsplan, der eine bestimmte, zumeist vorgegebene Kostenfunktion im Vergleich zu anderen Ausführungsplänen möglichst stark minimiert. Bei der Berechnung einer Kostenfunktion werden die an der Anfrageauswertung beteiligten Ressourcen miteinbezogen. Variabel bleiben die Gewichtungen einzelner Faktoren. Beispiele von Kostenfunktionen können eine minimale Prozessorbelastung, aber auch ein schnelles Antwortzeitverhalten sein. Der Aufwand für die Bestimmung des optimalen Ausführungsplans ist prohibitiv hoch, das heisst im Normalfall nicht zu akzeptieren. Um trotzdem einen möglichst optimalen Ausführungsplan zu

6.1 Klassische Anfrageauswertung

Ausführungspläne

■ ■ ■

153

ermitteln, ist es erforderlich, den Suchraum für Ausführungspläne einzugrenzen. Dazu werden Heuristiken verwendet. Die Anfragebearbeitung untergliedert sich für gewöhnlich in drei aufeinander folgende Phasen. Zunächst wird in der ersten Phase die Anfrage (beispielsweise ein SQL-Statement) in eine interne Darstellung übersetzt (das heisst in die relationale Algebra), die der Ausgangspunkt der weiteren Verarbeitung ist. Ganz am Anfang der Phase wird ein Test auf die syntaktische Korrektheit der Anfrage und eine Überprüfung der Zugriffsrechte desjenigen Nutzers, der die Anfrage initiiert hat, durchgeführt. Das Ergebnis dieser Phase ist eine algebraische Repräsentation in der Form eines gerichteten azyklischen Graphens (DAG) oder einer Baumstruktur. In der sich anschließenden Phase 2 wird der Operatorgraph durch die Anwendung algebraischer oder kostenbasierter Transformationsregeln optimiert. Jede Umformung führt zu einem anderen möglichen Ausführungsplan, wobei die kostenbasierte Optimierung besser, aber wesentlich aufwendiger und rechenintensiver als die algebraisch regelbasierte Optimierung ist.

Abb. 6.1: Klassische Anfrageausführung

Anfrage

Übersetzung

Syntaktische Analyse, Zugriffsrechte, Standardisierung und Übersetzung

Operatorgraph

Optimierung

Optimierungen auf Operatorgraphebene, abschließende CodeGenerierung

Übersetzungszeit

Phasenmodell der Anfrageausführung

Ausführung

Anfrageergebnis

154

■ ■ ■

6 Anfrageverarbeitung

Laufzeit

Ausführungsplan

Der nach dieser Phase ausgewählte, optimale Ausführungsplan wird schließlich dem Code-Generator übergeben. Die Query-Engine führt schließlich zur Laufzeit den erzeugten Code aus. Manche Systeme arbeiten auch interpretierend, dann entfällt die Code-Generierung und die Query Engine wertet direkt den Operatorgraphen (Ausführungsplan) aus.

6.2 Anforderungen mobiler Anfragesysteme Bei der Realisierung leichtgewichtiger Query-Engines für mobile Datenbanksysteme sind vor allem zwei charakteristische Merkmale von Anfragen von besonderer Bedeutung [Lei01]: ■

■

Charakteristik von Anfragen

Anfragekomplexität. Anfragen hoher Komplexität13 zeichnen sich durch eine grosse Anzahl komplexer relationaler AlgebraOperationen aus, wie es beispielsweise Sortieroperationen und Aggregationen sind. Gleichzeitig wachsen mit der Komplexität einer Anfrage aber auch deren Optimierungspotential und damit die für die Optimierung benötigte Rechenleistung. Da mobile Clients aber nur eine sehr beschränkte Rechenleistung und einen beschränkten Hauptspeicher für Zwischenergebnisse haben, müssen bei der Implementierung von Optimierungsstrategien Kompromisse eingegangen werden. Eine häufige Variante im mobilen Umfeld ist beispielsweise, Optimierer zu implementieren, die lediglich eine heuristische oder eine heuristische und eine algebraische, nicht aber eine wesentlich aufwendigere kostenbasierte Optimierung durchführen. Auf diese Weise wird der eingeschränkten Leistungsfähigkeit vieler mobiler Clients Rechnung getragen. Gleichzeitig bedeutet dies aber unter Umständen längere Antwortzeiten bei der Anfrageauswertung. Änderungsdynamik zugegriffener Daten. Anfragen, die auf einem (relativ) statischen Datenbestand ausgeführt werden, können zur Performanzsteigerung auf vorkompilierte Anfragen und materialisierte Views zurückgreifen. Dies ist allerdings nur dann möglich, wenn die zugegriffenen Daten keine oder zumindest nur eine geringe Änderungsdynamik aufweisen. Der Vorteil durch diese Vorgehensweise besteht darin, dass Anfrageoptimierungen so bereits weitgehend vor der eigentlichen Anfrageausführung durchgeführt werden. Auf mobilen Clients ergibt

13

Komplexität ist hier nicht im streng mathematischen Sinn gemeint, sondern zunächst mehr intuitiv, obwohl zwischen beiden eine Korrelation besteht.

6.2 Anforderungen mobiler Anfragesysteme

■ ■ ■

155

sich zusätzlich die Schwierigkeit, dass der latente Speicherplatzmangel die Speicherung vorkompilierter Anfragen und materialisierter Views, selbst bei einer nur geringen Änderungsdynamik, unmöglich macht. Auch in diesem Fall muss ein Kompromiss bei der Implementierung des Anfragesystems gefunden werden. So können nur kleinere Mengen vorkompilierter Anfragen vorgehalten werden. Zusätzliche Anforderungen

Neben den bereits genannten Defiziten (geringe Rechenleistung und Speicherplatzmangel) müssen auch die geringen Energiekapazitäten und die ständig auftretenden Verbindungsunterbrechungen bei der Implementierung der Query-Engine entsprechend berücksichtigt werden. Diese beiden Forderungen lassen sich wie folgt zusammenfassen: ■

Minimierung des Energieverbrauchs

■

Minimierung der Kommunikationskosten

Für die Anfrageverarbeitung in mobilen Umgebungen rückt die Zielsetzung einer möglichst kurzen Ausführungsdauer in den Hintergrund. Dagegen spielt der Durchsatz der ausgeführten Anfragen eine wesentlich wichtigere Rolle.

6.3 Klassifikation standortabhängiger Queries In mobilen Umgebungen ist es naheliegend, dass Anfragen standortabhängige Elemente enthalten. Man denke an die Location Based Services (vgl. Kapitel 2.5), die Standortinformationen sogar voraussetzen, um sinnvoll genutzt werden zu können. Von entscheidender Bedeutung sind somit vor allem eine möglichst exakte Positionsermittlung mobiler Clients für die Bereitstellung lokationsabhängiger Anwendungen und Dienstleistungen. Nachfolgend werden besondere Eigenschaften standortabhängiger Anfragen beschrieben [Gup03]. Gleichzeitig wird eine mögliche Klassifikation aufgezeigt. Dabei gehen wir von einem relationalen Datenbankschema aus.

6.3.1 Begriffe Tabellenattribute, die lokationsabhängige Informationen beschreiben bzw. enthalten, werden als Location Related Attributes bezeichnet.

156

■ ■ ■

6 Anfrageverarbeitung

Typische lokationsorientierte Informationen sind beispielsweise Postleitzahlen oder Städtenamen, allgemein Informationen, die einen konkreten geographischen Bezug beinhalten. Attribute bei denen dies nicht der Fall ist, werden korrespondierend dazu als NonLocation Related Attributes bezeichnet. Der Wertebereich eines Location Related Attributes wird als Location Related Domain bezeichnet. Darüber hinaus wird ein Location Related Operator als Operator definiert, der Location Related Attributes untereinander oder mit Non Location Related Attributes verbindet. Beispiele von Location Related Operators sind Ausdrücke der Form „nahe bei“ oder „innerhalb“. Diese Phrasen implizieren konkrete räumliche Anforderungen an ein beschriebenes Objekt. Bei Location Related Predicates handelt es sich um Prädikate, die aus einem Location Related Operator und Ausprägungen zweier oder mehrerer Location Related Attributes gebildet werden.

6.3.2 Klassifikation Die räumliche Bewegungsdynamik mobiler Clients kann variieren. So kann ein eher statisches Szenario, aber auch ein stark mobiles, dynamisches Bewegungsverhalten vorliegen. Korrespondierend zu dieser Charakterisierung können standortabhängige Anfragen klassifiziert werden (vgl. Abbildung 6.2): ■

Static Location Related Queries. Static Location Related Queries (SLRQ) sind Anfragen, die lokationsabhängige Informationen wie Positionsdaten verwenden und die gleichzeitig von mobilen Clients initiiert werden, die keine oder eine nur schwach ausgeprägte Bewegungsdynamik aufweisen. Einmal ermittelte Positionsdaten behalten in diesem Fall zumeist für einen längeren Zeitraum ihre Gültigkeit. Static Location Related Queries werden weiter in Location Aware Queries (LAQ) und Location Dependant Queries (LDQ) untergliedert. Das Unterscheidungskriterium für diese beiden Subklassen ist die Ergebnischarakteristik abgesetzter Anfragen. Sind die ermittelten Anfrageergebnisse maßgeblich vom aktuellen Standort des mobilen Clients abhängig, handelt es sich um eine Location Dependant Query. Wird dagegen unabhängig vom aktuellen Standort immer das gleiche Ergebnis geliefert, handelt es sich um eine Location Aware Query. Location Aware Queries enthalten mindestens ein einfaches Location Related Predicate oder ein einzelnes Location Related Attribute.

6.3 Klassifikation standortabhängiger Queries

■ ■ ■

157

Die Lokationsabhängigkeit von Location Dependant Queries kann auch anhand des impliziten geographischen Lokationsfaktors „hier“ beschrieben werden. Dieser Faktor, der den aktuellen Standort beschreibt, wird dem Anfragesystem als Parameter stets übergeben. Nach erfolgter Positionsbestimmung einer Location Dependant Query verwandelt sich diese automatisch in eine Location Aware Query. Dazu wird der implizite Lokationsfaktor „hier“ durch konkrete, lokationsabhängige Positionsdaten ersetzt. Der Vorgang der Standortermittlung wird als Location Binding bezeichnet. Abb. 6.2: Klassifikation von Anfragen

Anfragen

Static Location Related Queries (SLRQ)

Location Dependant Queries (LDQ)

■

158

■ ■ ■

Mobile Object Database Queries(MODB)

Location Aware Queries (LAQ)

Mobile Object Database Queries. Mobile Object Database Queries (MODQ) sind ebenfalls lokationsabhängig, werden im Vergleich zu SLRQ aber von mobilen Clients initiiert, die einer stark ausgeprägten Bewegungsdynamik unterliegen. Die mobilen Clients bewegen sich in diesem Fall relativ schnell. Waren bei den Static Location Related Queries vor allem statische Standortinformationen von Bedeutung, muss bei den Mobile Object Database Queries zusätzlich der Zeitaspekt und die Bewegungsrichtung der Clients berücksichtigt werden. Mobile Object Database Queries besitzen deswegen eine höhere Komplexität. Anfragen dieser Art werden auch als Prediction Queries bezeichnet. Mobile Object Database Queries können als spezielle Weiterentwicklung von Location Aware Queries oder Location Dependant Queries betrachtet werden.

6 Anfrageverarbeitung

6.3.3 Architektur zur Ausführung lokationsabhängiger Anfragen Location Aware Queries und Location Dependant Queries können auf der gleichen Architektur aufsetzen. Die wichtigste Komponente jeder Architektur, die die Ausführung lokationsabhängiger Anfragen gestattet, ist der Location Dependent Service Manager (vgl. Abbildung 6.3). Nach der Initiierung einer Anfrage muss diese zunächst in jedem Fall an dieses spezielle Modul weitergeleitet werden. Der Location Dependant Service Manager kontaktiert dann das Location ServiceModul, das für eine möglichst exakte Positionsbestimmung des mobilen Clients, der die Anfrage initiiert hat, verantwortlich ist. Verschiedenen Basisstationen werden darüber hinaus verschiedene Lokationsserver (Location Server) zugewiesen. Zumeist versorgt ein Lokationsserver mehrere Basisstationen. Ein Lokationsserver ist dafür zuständig ist, Informationen über die dem Lokationsserver zu einem Zeitpunkt zugeordneten Nutzer zu dokumentieren. Dadurch werden die Bewegungen eines Nutzers in einer mobilen Umgebung nachvollzogen, was vor allem erste grobe Standortermittlungen mobiler Nutzer ermöglicht. So kann anhand der Basisstation, über die ein mobiler Nutzer aktuell an das Festnetz angebunden ist, zumindest die Funkzelle bestimmt werden, in der er sich aufhält. Zusätzlich ist aber jeder mobile Nutzer auch einem Home Location Server zugewiesen. Dieser speichert alle relevanten Informationen über die Bewegungen eines mobilen Nutzers zentral ab (nachdem andere Basisstationen relevante Informationen übermittelt haben). EXKURS: Standortermittlung Kernidee vieler Verfahren zur Standortermittlung ist das Konzept der Partitionen. Unter einer Partition werden mehrere räumlich nahe beieinander liegende Funkzellen verstanden, die zu einer größeren, logischen Einheit zusammengefasst sind. Die Standortermittlung mobiler Nutzer über Partitionen ist allerdings nicht sehr genau. So kann lediglich die ungefähre Position eines Objektes bestimmt werden. Trotzdem existieren einige unterschiedliche Verfahren, um den Standort eines Nutzers (mehr oder weniger exakt) über Partitionen zu bestimmen: ■

Possible Location. Über die Strategie Possible Location wird eine nur ungenaue Standortermittlung anhand der aktuell im

6.3 Klassifikation standortabhängiger Queries

■ ■ ■

159

Home Location Register über einen Nutzer gespeicherten Informationen erreicht. Als möglicher Aufenthaltsort eines Nutzers wird die letzte bekannte, im Home Location Register verfügbare Position gesehen. Als Ergebnis dieses Verfahrens wird eine einzelne Basisstation zurückgeliefert. Ist allerdings zwischenzeitlich ein Wechsel zu einer anderen Basisstation erfolgt, werden falsche Informationen zurückgegeben. Damit ist dieses Verfahren also mit großen Unsicherheiten behaftet. ■

Partition. Als Ergebnis dieses Verfahrens wird eine Menge an Funkzellen zurückgeliefert. Alle Funkzellen bilden zusammen diejenige Partition, in der sich ein Nutzer vermutlich gerade aufhält. Auch in diesem Fall ist eine exakte Standortbestimmung nur schwer möglich.

■

Actual Location. Zwar wird auch bei dieser Strategie eine Menge an Funkzellen zurückgeliefert, die als Aufenthaltsort des gesuchten Nutzers in Frage kommen. Trotzdem ist diese Strategie wesentlich genauer, da die Funkzellen mit weiteren Positionsermittlungsverfahren (zum Beispiel Triangulation) nach dem Signal des mobilen Nutzers durchsucht werden.

Während die beiden zuerst genannten Strategien einen nur geringen Kommunikationsverkehr hervorrufen, stellt die letzte Strategie eine sehr kommunikationsintensive Vorgehensweise dar. Je nach den Anforderungen an die Kommunikationsinfrastruktur kann so eine mehr oder weniger kommunikationsintensive Strategie gewählt werden. Soll der Standort eines Nutzers so exakt wie möglich festgestellt werden, muss auf die dritte Strategie zurückgegriffen werden. Spielt die Präzision der Standortinformationen aber eine nur untergeordnete Rolle, können auch die beiden ersten Strategien genutzt werden. Mit der erfolgreichen Bestimmung der Positionsdaten bindet das Location Service-Modul die Standortinformationen an die Anfrage. Anschließend wird die Anfrage durch das Location Dependant Service Management-Modul in Subtransaktionen unterteilt. Jede Subtransaktion wird dann auf der für sie relevanten Datenquelle ausgeführt. Können alle Anfragebestandteile auf einer einzigen Datenquelle ausgeführt werden, ist die Fragmentierung in Subtransaktionen hinfällig. Nach der Bearbeitung der Subtransaktionen ist erneut das Location Dependant Service Management-Modul für die weitere Anfrageausführung verantwortlich. Dabei müssen jedoch lediglich die erhaltenen Teilergebnisse zusammengesetzt und an den mobilen Client übermittelt werden.

160

■ ■ ■

6 Anfrageverarbeitung

Abb. 6.3 Architektur zur Ausführung lokationsabhängiger Abfragen Location Services (Standortermittlung) Lokationsserver

Basisstationen

Location Dependant Service Manager

Fixed Network

6.4 Zusammenfassung In diesem Kapitel wurden wichtige Problemstellungen beschrieben, wie sie im Zusammenhang mit der Anfrageausführung in mobilen Umgebungen auftreten. Nach einer allgemeinen Beschreibung der Anfrageverarbeitung in Datenbanksystemen wurden dann zunächst spezifische Anforderungen an die Anfrageausführung in mobilen Umgebungen beschrieben. Dabei wurden vor allem die Anfragekomplexität und die Änderungsdynamik der zugegriffenen Daten als Schlüsselelemente identifiziert und genauer erläutert. Ausgehend von diesen noch eher allgemeinen Betrachtungen wurde anschließend auf die Besonderheiten lokationsabhängiger Anfragen eingegangen. Dabei wurde festgestellt, dass gerade in mobilen Umgebungen die Verfügbarkeit von Standortinformationen eine alles entscheidende Rolle spielt. Nur wenn die Position eines mobilen Nutzers oder eines mobilen Clients möglichst exakt bestimmt werden kann, ist es möglich, Anwendungen und Dienstleistungen bereitzustellen.

6.4 Zusammenfassung

■ ■ ■

161

Die eigentliche Anfrageverarbeitung, wie sie konkret in den Anfragesystemen der mobilen Datenbanksysteme abläuft, stellt dagegen keine besondere Herausforderung dar. Zwar müssen aufgrund der eingeschränkten physischen Leistungsmerkmale mobiler Clients Kompromisse zur Anfrageverarbeitung eingegangen werden. Im Wesentlichen werden aber lediglich die Konzepte klassischer Datenbanksysteme übernommen.

162

■ ■ ■

6 Anfrageverarbeitung

7 Informationsdarstellung auf mobilen Geräten

Viele mobile Endgeräte sind vergleichsweise starken Restriktionen unterworfen, was die Mächtigkeit physischer Ressourcen anbelangt. Prozessortakt, Speicherplatz, vor allem auch die Displaygröße und -auflösung bieten oftmals (sieht man von Notebooks ab) nicht die gleichen Leistungsmerkmale wie stationäre Rechnersysteme. So führt die geringe Displaygröße dazu, dass die adäquate Gestaltung von Benutzerschnittstellen und die Anpassung darzustellender Informationen eine besondere Anforderung sind. Im Folgenden steht die Informationsdarstellung auf mobilen Geräten im Vordergrund. Dabei wird zwischen der Anpassung von Systemen und der Anpassung von Informationen unterschieden [Sat96, Koe03]. Beide Varianten werden in den Abschnitten 7.1 und 7.2 diskutiert. Anschließend wird in Abschnitt 7.3 der W3C-Standard Composite Capability/Preference Profile beschrieben, der verschiedene Profile definiert, die an die Fähigkeiten verschiedener ClientKlassen angepasst sind. Anhand der Profile kann ein Webserver entscheiden, welche Informationen er dem zugreifenden Client übermitteln kann, um eine optimale Darstellung zu erreichen.

Motivation

7.1 Adaption von Systemen Die auf einem mobilen Client anzuzeigenden Informationen müssen an die auf dem Client geltenden Einschränkungen angepasst werden. Die Hauptschwierigkeit liegt in der Format- und Auflösungsvielfalt verfügbarer Displays. Ohne eine Adaption clientspezifischer Merkmale kann es sehr schnell zu Schwierigkeiten bei der Informationsdarstellung kommen. Eine Adaptionsmöglichkeit besteht darin, die mobilen Clients selbst an die Anforderungen der anzuzeigenden Informationen anzupassen. Die Hardware des Clients bildet zusammen mit der Client-Software in diesem Fall ein adaptives System. Die In-

7.1 Adaption von Systemen

Schwierigkeiten der Informationsdarstellung

■ ■ ■

163

formationen selbst bleiben dagegen in Form und Struktur unverändert. Somit ist klar, wieso hier von einer Adaption von Systemen, und nicht, wie im nächsten Abschnitt beschrieben, von einer Anpassung der Informationen die Rede ist. Bei der Adaption von Systemen können drei verschiedene Verfahrensweisen unterschieden werden: ApplicationTransparent Adaption

Bei der Application-Transparent Adaption erfolgt die Adaption für eine adäquate Informationsdarstellung ausschließlich durch die Hardware, das heisst durch die technischen Fähigkeiten des mobilen Clients. Beispiele einer solchen Vorgehensweise sind der Rückgriff auf ein flexibel verwendbares Display mit einer hohen Auflösung oder die Bandbreitenanpassung genutzter Netzwerkverbindungen. Eine Anpassung von Software wird in diesem Fall nicht durchgeführt. Allerdings kann es zu Funktionsstörungen bei Anwendungen kommen, die auf dynamische Hardwareanpassungen äußerst sensibel reagieren. Ein konkretes Beispiel, bei dem eine Application-Transparent Adaption von der Hardware durchgeführt wird, ist ein Videostream, der auf dem Display eines mobilen Clients angezeigt wird. Bricht mit der Migration in eine andere Funkzelle die Empfangsstärke plötzlich ein, kann er für die Videoübertragung eine verringerte Bandbreite anfordern. Eine Verringerung der Bandbreite bedeutet gleichzeitig aber auch eine verminderte Qualität bei der Anzeige des Videos. Der mobile Client reagiert selbständig auf die veränderten Umgebungsbedingungen. Gegenüber der den Videostream anzeigenden Anwendung (Videoplayer) bleibt die vorgenommene Adaption (die verringerte Bandbreite) jedoch weitgehend transparent. Zwar stellt die Anwendung durchaus fest, dass sie weniger Daten bekommt, aufgrund ihrer Spezifikation kann sie mit dieser Situation aber umgehen.

Laissez-Faire Adaption

Dem gegenüber steht die Laissez-Faire Adaption, bei der keinerlei Anpassungen, weder von Hard-, noch von Anwendungen durchgeführt werden. Es wird davon ausgegangen, dass die Darstellung von Informationen für gewöhnlich keine Probleme verursacht.

ApplicationAwareness Adaption

Einen Mittelweg beschreibt die Application-Awareness Adaption, bei der sowohl Hardware als auch Anwendungssoftware Anpassungen vornehmen. Dabei kann jedoch nicht in jedem Fall garantiert werden, dass durch die Anpassungen auch alle Anforderungen der darzustellenden Informationen umgesetzt werden können, das heisst bei der Informationsanzeige kann es zu Fehlern kommen.

164

■ ■ ■

7 Informationsdarstellung auf mobilen Geräten

Beispiel sei erneut ein Videostream. Kommt es dazu, dass die verfügbare Bandbreite unter eine bestimmte Schwelle fällt, erfolgt eine kombinierte Adaption dieser Situation. Einerseits reagiert die das Grundsystem, zum Beispiel durch eine Reduktion der Empfangsleistung, andererseits reagiert aber auch die den Videostream verarbeitende Anwendung, zum Beispiel über eine Reduktion der Farbtiefe bei der Videoanzeige. Adaption an den mobilen Kontext

Anpassung der Systeme

ApplicationTransparent -Adaption

Abb. 7.1: Adaption an den mobilen Kontext

Anpassung der Informationen

LaissezFaireAdaption

ApplicationAwarenessAdaption

7.2 Adaption von Informationen Wir gehen im Folgenden auf die Adaption von Informationen ein. Dazu muss zunächst der Begriff Treuegrad (Fidelity) eingeführt werden. Unter dem Treuegrad versteht man die Ähnlichkeit einer lokalen Kopie eines mobilen Clients im Vergleich zu seinem im Backend gespeicherten Original. Je geringer die Abweichung zwischen beiden Elementen ist, desto größer ist der Treuegrad. Mögliche Abweichungen können sein: ■

Qualitätsverlust bei Audio-/Videoströmen

■

Informationsselektion (beispielsweise Verzicht auf Multimediaelemente einer angezeigten Webseite)

■

Verzicht auf Aktualität (beispielsweise die Anzeige nur zeitverzögerter Börsenkurse)

■

Anpassung durch Transformation (beispielsweise die Transformation eines problematischen Datenformats in ein leichter anzuzeigendes Datenformat)

7.2 Adaption von Informationen

■ ■ ■

165

Fallunterscheidung

Bei der Anpassung von Informationen wird zwischen zwei Szenarien unterschieden. Im ersten, trivialen Fall erfolgt die Übertragung, Speicherung und Darstellung von Informationen unter zu Hilfenahme von speziellen Protokollen. Weit verbreitetes Beispiel einer solchen Protokollfamilie ist die Kombination Wireless Application Protocol/Wireless Markup Language (WAP/WML). WAP ist ein Transportprotokoll für den Einsatz in mobilen Umgebungen. Die Beschreibung der durch das Protokoll übertragenen Daten erfolgt meistens mit WML. Bei WML handelt es sich um eine HTML-ähnliche, XML-basierte Seitenbeschreibungssprache, die speziell an die geringen Displaygrößen mobiler Clients angepasst ist. Die Kommunikation zwischen Festnetz respektive Internet und den mobilen Systemen erfolgt über WAP-Gateways. Dabei muss beachtet werden, dass die Anwendungssoftware, die zur Darstellung von WMLSeiten benutzt wird (man spricht von einem WAP/WML-Browser), oftmals nicht zur Anzeige von HTML-Seiten benutzt werden kann. Trotz der Ähnlichkeiten zwischen HTML und WML existiert keine Kompatibilität. Beide benötigen demzufolge eigene Browser. Im zweiten Fall wird nicht auf spezifische Protokolle zurückgegriffen, sondern stattdessen wird ein automatischer Adaptionsmechanismus implementiert, der die Daten in eine passende Form transformiert. Wo genau eine solche Transformation stattfindet (Client, Server, Middleware), spielt dabei keine Rolle. Aufgrund der Leistungsrestriktionen vieler mobiler Clients bietet es sich jedoch an, die Transformation zumindest nicht clientseitig durchzuführen. Problematisch ist in diesem Fall jedoch, dass viele Informationssysteme auf gestellte Anfragen oft eine ganze Menge von Resultaten liefern, deren gleichzeitige Anzeige auf oftmals sehr kleinen Displays nicht möglich ist. Mögliche Lösungen dieses Problems sind der Einsatz eines Webkarussells oder die Verwendung eines Personalisierungskonzepts. Beide Verfahrensweisen werden im Folgenden beschrieben.

7.2.1 Webkarussell Ursprung

166

■ ■ ■

Das Konzept eines Webkarussells [Nad01a, Nad01b] basiert auf der automatischen Generierung semantischer Beziehungen zwischen Informationen verschiedener Webseiten. Die in Japan entwickelte Technik impliziert ein Anwendungsszenario, wie es vor allem durch die technischen Fähigkeiten der Mobilfunknetze der dritten Generation vorgesehen ist: Nutzer greifen über ihre mobilen Clients (Han-

7 Informationsdarstellung auf mobilen Geräten

dys, Smartphones, …) auf zumeist datenintensive, multimedial aufbereitete Informationen zu. Die Idee ist nun, bei der Darstellung von Informationen die in vielen Fällen ungünstige Textdarstellung von Informationen (bedingt durch zu kleine Displays) durch für mobile Clients besser geeignete Darstellungsformen zu ersetzen – in diesem Fall Videos, Audiodaten oder Bilder. Um gewünschte Informationen zu bekommen, formuliert ein Nutzer eine Suchanfrage. Dazu gibt er eine Menge von Suchbegriffen an, unter denen er thematisch relevante Informationen vermutet (nicht anders als man es von klassischen WWW-Suchmaschinen gewohnt ist). Anhand der eingegebenen Suchbegriffe wird dann eine multimediale Zusammenstellung von relevanten Webinhalten generiert, die dem Nutzer nacheinander angezeigt werden. Das generierte Suchergebnis wird auch als Webkarussell bezeichnet. Die häppchenweise Präsentation von Inhalten ist die Rotation des Karussells und die aufeinander folgenden Informationshappen sind die Karussellkomponenten (einzelne Suchergebnisse). Karussellkomponenten bestehen dann aus den Audio- und Videoelementen, aber auch aus Grafiken bzw. Bildern. Um ein bereits vorhandenes Suchergebnis weiter zu verfeinern, werden semantische Informationen verwendet. Anhand dieser wird anschließend ein neues Webkarussell generiert, das das spezialisierte Suchergebnis darstellt. Semantische Informationen sind beispielsweise Ähnlichkeitsgrade oder typisierte Links. Über bereits zuvor ermittelte Suchergebnisse können so verschiedene Netze von semantischen Beziehungen gelegt werden. Jedes einzelne semantische Netz ist eine eigene verfeinerte Suchvariation des ursprünglichen Suchergebnisses. Einfach gesprochen sind Suchvariationen entweder Lockerungen oder Straffungen des semantischen Netzes.

Idee

Funktionsweise

Verfeinerte Suche

Um den Ausdruck des Web-Karussells zu präzisieren, wird folgende formale Definition eingeführt: Als Ergebnis einer Suchanfrage wird ein Karussell K generiert. Dieses Karussell besteht aus einer Menge von Karussellkomponenten KKi. Jede Karussellkomponente, extrahiert aus einer einzelnen Webseite S, ist weiterhin wie folgt definiert:

Definition 7.1

KKi = (Kheader Kvoice Kvisual) wobei Kheader = Titel der Webseite Kvoice = Textausschnitt von S in Audiosignalen Kvisual = Repräsentativer Ausschnitt (Bild, Video) aus S

7.2 Adaption von Informationen

■ ■ ■

167

Die Bestimmung der einzelnen Karussellkomponenten erfolgt durch die Ausführung eines speziellen Algorithmus’. Dieser erwartet als Eingabe die durch den Nutzer festzulegenden Suchbegriffe, eine Menge von Webseiten (also den Suchraum) und die maximale Länge der über die Sprachwiedergabe auszugebenden Texte. Der Algorithmus lautet wie folgt: Algorithmus

Schritt 1: Generiere Kheader aus dem Titel einer Webseite (die dazu notwendigen Informationen sind durch die HTML-/WML-Tags eingeschlossen). Schritt 2: Generiere Kvoice als Ergebnis der Suche nach dem kleinsten zusammenhängenden Textsegment, welches alle vorgegebenen Suchbegriffe enthält. Kvoice kann beispielsweise eine generierte gesprochene Wiedergabe eines Textelements sein. Schritt 3: Generiere Kvisual als Ergebnis der Suche nach demjenigen Bild/Video, das sich in der kleinsten zusammenhängenden Einheit einer Seite befindet, und die alle Suchbegriffe zusammen mit einem Bild/Video enthält. Die kleinste zusammenhängende Einheit ist definiert als derjenige Abschnitt einer Webseite, der durch zwei Tags <x> und eingeschlossen ist und minimal ist (x beliebig). Existiert kein Bild/Video, wird ausschließlich Text angezeigt. Jede durch eine Suchmaschine erfasste Webseite wird durch eine Liste von Schlüsselwörtern beschrieben (auch Keyword Feature Vector genannt). Um die Charakteristik einer Webseite möglichst adäquat zu erfassen, werden alle in einer Liste enthaltenen Schlüsselwörter bewertet und verschieden gewichtet. Höher gewichtete Schlüsselwörter sagen dabei mehr über den Informationsgehalt einer Webseite aus als niedrig gewichtete.

7.2.2 Personalisierung Idee

168

■ ■ ■

Das Konzept der Personalisierung hat im World Wide Web bereits eine grosse Verbreitung gefunden. Neben persönlich erstellten Profilen kommen vor allem automatisch erstellte Nutzerprofile zum Einsatz, die durch Analyse der Verhaltensmuster der Nutzer beim Webseitenbesuch generiert werden. Beide dienen vor allem der Informationsauswahl (zum Beispiel Werbung) und -Filterung. Nutzern kann

7 Informationsdarstellung auf mobilen Geräten

so eine auf ihre persönlichen Vorlieben zugeschnittene Anwendungsschnittstelle präsentiert werden. Webseiten, die jedem Nutzer eine personalisierte, dynamische Webpräsenz bereitstellen, spielen gerade für mobile Anwendungen eine entscheidende Rolle. So ist der Besucher einer Webseite oft nur an einzelnen, im Verhältnis zur Gesamtinformationsmenge sehr kleinen Informationseinheiten interessiert. Methoden der Personalisierung versuchen genau hier anzusetzen und dem Nutzer anhand individueller Profile nur relevante Informationseinheiten zu präsentieren. Als sehr problematisch bei der Personalisierung kann sich allerdings der Datenschutz erweisen. So fallen bei der Ermittlung von Verhaltensmuster und der Speicherung individueller Nutzerprofile hochsensible, personenbezogene Daten an, die nicht nur zum Zwecke einer vom Nutzer gewünschten Personalisierung, sondern auch zu missbräuchlichen Zwecken verwendet werden können. Gerade bei Informationsportalen, die eine nahezu unüberschaubare Informationsmenge anbieten (beispielsweise Börseninformationsportale), kann Personalisierung ein enormer Vorteil sein, was die Bedienungsfreundlichkeit und die Nutzbarkeit einer Webseite anbelangt. Die Methoden der Personalisierung befassen sich allerdings nicht nur mit der Erstellung von Nutzerprofilen. Personalisierung ist auch eine Möglichkeit, analysierte Verhaltensmuster in den strukturellen Aufbau des Layouts und der Usability einer Webseite einfließen zu lassen. Wichtig diesbezüglich sind: ■

Inhaltliche Aufteilung von Informationen

■

Verwendung / Erzeugung zusätzlicher Links

■

Fettdruck häufig verwendeter Links / Funktionen

■

Ausblendung weniger häufig verwendeter Funktionen

DatenschutzProblematik

Strukturelles Layout

Das Ziel bei der Adaption von Informationen – und nichts anderes stellt eine Personalisierung dar – ist dabei aber vor allem eine sinnvolle Anpassung von Inhalt und Layout. So ist es nicht unbedingt vorteilhaft, sehr grosse Informationsmengen auf einem mobilen Client anzuzeigen, wenn die Informationsdarstellung und die Navigation auf den Inhalten zu unübersichtlich wird und deswegen eine sinnvolle Nutzung dieser Informationen nicht mehr möglich ist.

7.2 Adaption von Informationen

■ ■ ■

169

7.3 Adaption durch Abstraktion Ein völlig neues Konzept im Rahmen der Adaption von Informationen ist die Idee der Adaption durch Abstraktion. Dabei wird davon ausgegangen, dass eine mobile Umgebung durch eine 3-SchichtenArchitektur beschrieben wird. Die mobilen Clients realisieren dabei lediglich die Präsentationsschicht (Representation Layer), während die stationären Hosts des Festnetzes sowohl die Anwendungslogik (Application Logic) als auch separat die Datenhaltung (Storage Layer) übernehmen. Die Laufzeitumgebung für Anwendungen wird in diesem Szenario durch Applikationsserver bereitgestellt. Ein solches Szenario bedeutet aber implizit auch, dass der Disconnected Mode mobiler Clients nicht direkt unterstützt wird. Wenn man wieder das Anwendungsszenario eines Zugriffs auf Webseiten mit mobilen Endgeräten betrachtet, ist dies aber auch vernachlässigbar. Für den Zugriff auf die Applikationsserver und die dort laufenden Anwendungen verfügen die mobilen Clients lediglich über eine einfache, browserbasiertes Anwendung. Für die Darstellung von Inhalten wird auf XML und verwandte Sprachen zurückgegriffen. Ein Applikationsserver verfügt deshalb auch über einen XSLT-Prozessor, der zur Aufbereitung von XML-Inhalten benutzt wird. Damit mobile Clients angeforderte Informationen in einer für sie korrekt interpretierbaren und anzeigbaren Form bekommen, müssen sie dem Applikationsserver zunächst eine XML-Beschreibung der gerätespezifischen Charakteristika des mobilen Clients übermitteln. Anschließend wird anhand dieser Charakteristika ein XSL-Stylesheet erstellt und auf den Client geladen. Das Stylesheet legt die genaue Vorgehensweise bei der Aufbereitung von Inhalten für eine Geräteklasse fest. Für jedes beliebige Gerät bzw. jede mögliche Geräteklasse kann eine eigene XSL-Definition erstellt werden. Dadurch wird es möglich, auf mobilen Geräten einer bestimmten Klasse stets korrekt aufbereitete Informationen anzuzeigen. Der Vorteil dieser Methodik liegt darin, dass neue Geräteklassen auf sehr einfache Weise in bereits existierende Infrastrukturen integriert werden können. Für jede neue Geräteklasse muss nur anfangs ein neues, angepasstes XSL-Stylesheet erstellt werden.

7.3.1 Composite Capability / Preference Profile Das W3C hat Mitte Januar 2004 die Version 1.0 der Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies

170

■ ■ ■

7 Informationsdarstellung auf mobilen Geräten

freigegeben. Bei CC/PP handelt es sich um eine RDF-Anwendung14, die die Eigenschaften von mobilen Geräten beschreibt. Die resultierenden Profile sollen unterschiedlichen Endgeräten (wie beispielsweise Handys, PDAs, …) beliebige Webinhalte erschließen, wobei beim Online-Zugriff durch einen Webserver ausschließlich die Informationen übermittelt werden, die die jeweiligen Geräte auch tatsächlich darstellen können. CC/PP entstand in einer Kooperation mit der Open Mobile Alliance15, der Nachfolge-Organisation des WAPForums. Ein einzelnes CC/PP-Profil besteht aus zwei verschiedenen Abstraktionsebenen. Ein Profil besteht aus mindestens einer, ansonsten aus beliebig vielen Komponenten. Komponenten sind die Hardwareoder die Software-Plattform, die der Ausführung der installierten Anwendungen dienen, oder einzelne Applikationen, wie ein Browser. Eine Komponente selbst besteht wiederum aus mindestens einem, ansonsten aus beliebig vielen Attributen. Ein CC/PP-Profil beschreibt die technischen Charakteristika verschiedener Clients durch die Bestimmung verschiedener CC/PPAttribute einzelner Komponenten. Es bleibt abzuwarten, in wie weit sich dieser Standard durchsetzen kann. Da viele vom W3C ausgesprochenen Empfehlungen in den letzten Jahren aber schnell zu Industriestandards wurden, ist anzunehmen, dass sich auch dieser Vorschlag langfristig durchsetzen wird.

7.4 Zusammenfassung Allgemein kann bezüglich der Informationsdarstellung auf mobilen Clients zwischen drei Problemklassen unterschieden werden. Bei der ersten Klasse handelt es sich um Hardware-Probleme. Beispiele hierfür sind die Rechnerleistung (Prozessortakt), die Speichergröße, die Displaygröße bzw. -auflösung oder auch die verfügbare Netz14

RDF ist ein Datenformat für Metadaten und gleichzeitig der Metadaten-Standard des W3C. Mit ihm lassen sich unter anderem der Titel und das letzte Änderungsdatum einer Webseite maschinenlesbar kodieren. RDF wird durch zwei Dokumente definiert. In der Resource Description Framework (RDF) Model and Syntax Specification werden das Datenmodell und die Syntax beschrieben, durch die beliebige Daten in RDF repräsentiert werden. Dieses Dokument hat aktuell den Status einer Recommendation, das heisst, es ist bereits als normative Referenz zu betrachten. Das Resource Description Framework (RDF) Schema beschreibt dagegen die Definition von Schemas, über die die Semantik von Daten erfasst werden kann. Dieses Dokument hat allerdings noch den Status einer Proposed Recommendation. 15

http://www.openmobilealliance.org/

7.4 Zusammenfassung

■ ■ ■

171

werkbandbreite. Die zweite Problemklasse kann unter dem Begriff der intrinsischen Probleme beschrieben werden. Intrinsisch deswegen, da es sich um Probleme handelt, die durch einen technologischen Fortschritt nicht zu kompensieren sind, also letztlich durch die Charakteristik mobiler Clients inhärent gegeben und bestimmt sind. Ein Beispiel eines solchen intrinsischen Problems sind bei der Mobilkommunikation auftretende Funklöcher, die zu einem abrupten Abbruch bestehender Kommunikationsverbindungen führen. Die intrinsischen Probleme entstehen explizit durch den Faktor Mobilität. Die dritte Klasse von Problemen betrifft ergonomische Aspekte. Damit sind verschiedene Eigenschaften mobiler Einheiten gemeint, die im Zusammenhang mit der Nutzbarkeit und der Verwendung mobiler Clients zu sehen sind. Soll Mobilität durch entsprechende Gerätetypen unterstützt werden, sind die Techniken und Verfahren herkömmlicher Hard- und Software zumeist nicht direkt anwendbar. Vielmehr besteht der Bedarf der Entwicklung zielgerichteter, spezieller Lösungen, vor allem zur Ein- und Ausgabe von Informationen für mobile Geräte. Die in diesem Kapitel vorgestellten Verfahrensweisen Adaption von Systemen, Adaption von Informationen und Adaption durch Abstraktion zeigen konkrete Möglichkeiten auf, wie die Informationsdarstellung auf mobilen Clients durchgeführt werden kann.

172

■ ■ ■

7 Informationsdarstellung auf mobilen Geräten

8 Pico-Datenbanksysteme

Pico-Datenbanksysteme sind Datenbanksysteme auf Smartcards. Smartcards gehören aufgrund ihrer technischen Charakteristika und ihres physischen Aufbaus zu den kleinsten mobilen Computersystemen, die heute verfügbar sind. Sie besitzen zwar keine eigene Stromversorgung und keine eigene Ein- und Ausgabe, haben dafür aber alle Kernkomponenten eines Kleinstrechners: eine eigene CPU, einen Arbeitsspeicher und persistenten Speicher; und das alles auf einem Chip. Smartcards sind klein, kostengünstig herzustellen und mittlerweile in vielen Anwendungsfeldern im praktischen Einsatz. Smartcards haben bisher als Randbedingung vor allem eine niedrige Speicherkapazität und eine sehr geringe Rechenleistung. Dazu kommt, dass die auf ihnen gespeicherten Daten nur bearbeitet werden können, wenn spezielle Hardware in Form eines Kartenlesebzw. -schreibgerätes (Kartenterminal) verfügbar ist. Wie bei anderen mobilen Endgeräten kann aber auch bei Smartcards in der letzten Zeit ein enormer technischer Reifeprozess beobachtet werden. Dieser führt zu einer wesentlich leistungsfähigeren Smartcard-Technologie, die die Erschließung neuer, bislang noch ungenutzter Anwendungsgebiete ermöglicht. Mittlerweile verfügbare Entwicklungs- und Laufzeitumgebungen für Smartcards, wie JavaCard von Sun Microsystems16 oder SmartCard for Windows von Microsoft, untermauern diesen Trend zusätzlich.

Motivation

Technischer Reifeprozess

8.1 Anwendungsszenarien Der Einsatz von Smartcards ist im Zusammenhang mit folgenden Szenarien möglich [Bob00, Kur02]:

Anwendungsszenarien

16

Die Portierung der Java-Technologie auf Smartcards wird durch Sun Microsystems stark vorangetrieben. Mittlerweile sind bereits mehr als 400 Millionen JavaCards im praktischen Einsatz, die meisten davon im Mobilumfeld.

8.1 Anwendungsszenarien

■ ■ ■

173

174

■ ■ ■

■

Datentransport. Smartcards können dazu dienen, vertrauliche Informationen sicher und einfach zu transportieren. Dazu müssen die Daten zunächst unter Verwendung eines Kartenschreibgerätes auf eine Smartcard geladen werden. Von der Smartcard können die Daten mit einem Kartenlesegerät danach wieder ausgelesen werden. Im Normalfall bilden Kartenschreib- und Kartenlesegerät technisch gesehen eine Einheit, das heisst sie sind zu einem einzigen Terminal zusammengefasst. Hohe Verfügbarkeit und Sicherheit bei gleichzeitig relativ großem Speicherbedarf sind die Kennzeichen dieses Szenarios. Aufgrund der sicherheitskritischen Charakteristik vieler Daten muss eine geeignete Zugriffskontrolle (Authentifizierung und Passwortschutz) implementiert werden, um die Daten angemessen vor einem unbefugten Zugriff zu schützen. Der Einsatz von Verschlüsselungstechnologien kann die Daten zusätzlich absichern.

■

Nutzerprofile. Smartcards können aufgrund ihrer Größe leicht mitgeführt werden (beispielsweise im Geldbeutel). Sie können deshalb dazu dienen, ein detailliertes Benutzerprofil einer Person zu speichern, das diese immer mit sich führen kann. Dadurch wird es bei Beginn einer Arbeitssitzung möglich, an jedem beliebigen Computersystem innerhalb einer Arbeitsdomäne eine dem Nutzer bekannte und vertraute Arbeitsumgebung zu laden (Oberfläche, Bookmarks, usw.). Es kann somit ein an die eigenen Bedürfnisse angepasstes Rechnersystem bereitgestellt werden. Voraussetzung dafür ist jedoch, dass jeder Arbeitsplatz über ein zum Laden eines Benutzerprofils notwendiges Smartcard-Lesegerät verfügt. Auch bei diesem Szenario ist aufgrund der Charakteristik der Daten die Implementierung einer geeigneten Zugriffskontrolle sinnvoll.

■

Identifikation. Das dritte Szenario, bei dem Smartcards für eine eindeutige Identifikation eines Nutzers dienen, ist vor allem in der Telekommunikationsindustrie bzw. Mobiltelefonie zu finden. Anwendungen, bei denen vor Inanspruchnahme einer Dienstleistung eine korrekte Identifikation erforderlich ist, reichen von Subscriber Identification Modules (SIM) in Handys, bis hin zu Geldkarten oder der Speicherung biometrischer Daten. Als besonderes Merkmal dieses Anwendungsszenarios ist das geringe Volumen der gespeicherten Daten zu nennen. Meistens handelt es sich um einige wenige, sehr spezielle Informationen, wie eine Nutzeridentifikation (User-ID) oder Statusinformationen. Aufgrund der besonderen Sensibilität der Daten ist eine sichere Zugriffsverwaltung zwingend erforderlich.

8 Pico-Datenbanksysteme

■

Digitale Akte. Das für die Zukunft wohl wichtigste Anwendungsszenario ist die digitale Akte. Dabei werden alle relevanten Informationen, die zu einer Person oder einem Objekt (beispielsweise einem Frachtcontainer) im Zusammenhang mit einer bestimmten Anwendungsdomäne existieren, auf einer Smartcard gespeichert. Oft handelt es sich dabei um vertrauliche, personenbezogene Daten. Beispiel ist ein Patient, der in einer digitalen Akte alle verfügbaren medizinischen Informationen zu seiner Krankengeschichte (durchgeführte Operationen, erhaltene Medikationen, Blutgruppe, Allergiereaktionen, usw.) stets mitführt, so dass diese Informationen in jedem Krankenhaus und von jedem Arzt bei Bedarf innerhalb kürzester Zeit abgerufen werden können. Da verhältnismäßig viele Daten gespeichert und sowohl einfache, als auch komplexe Anfragen an die gespeicherten Daten gestellt werden, bietet sich der Einsatz eines Datenbanksystems zur Verwaltung der Daten an. Die Tatsache, dass gerade in diesem Fall ausgefeilte und ausgereifte Sicherheitsmechanismen notwendig sind, die einen Datenmissbrauch verhindern, und der Umstand, dass in Datenbanksystemen solche Sicherheitsfunktionen bereits oft von Haus aus integriert sind, ist ein weiteres starkes Argument für den Rückgriff auf Datenbanksysteme. Allgemein verdeutlichen die Anforderungen dieses Szenarios, dass gerade die Unterstützung von Datenbankfunktionalität Sicherheit bei gleichzeitig hoher Verfügbarkeit der Daten und eine akzeptable Performanz bei der Datenverarbeitung garantieren kann.

Datenbanken auf Smartcards werden, da sie einen sehr kleinen Speicher-Footprint haben müssen, Pico-Datenbanken genannt. Grundsätzlich gilt, dass in Pico-Datenbanksystemen Techniken, Methoden und Algorithmen von Hochleistungs-Datenbanksystemen keine Anwendbarkeit besitzen. Die eingeschränkten physikalischen Ressourcen einer Smartcard verlangen stattdessen die Anpassung existierender Implementierungskonzepte. Dieses Kapitel zeigt aktuelle Entwicklungen und vorgeschlagene Implementierungskonzepte für Pico-Datenbanksysteme auf. Die vorgestellten Techniken spielen dabei nicht nur für Pico-Datenbanksysteme eine Rolle, sondern besitzen auch für andere leistungsschwache eingebettete Datenbanksysteme Gültigkeit. Abschnitt 8.2 geht zunächst auf technische Merkmale von Smartcards und in diesem Umfeld angesiedelte industrielle Standards ein. Abschnitt 8.3 formuliert in der Form eines Zielkatalogs grundlegende Anforderungen an Pico-Datenbanksysteme. Die sich anschließenden Abschnitte fokussieren spezielle Problemfelder, die die Implementierung von Pico-Datenbanksystemen besonders

8.1 Anwendungsszenarien

■ ■ ■

175

erschweren. Darunter fallen vor allem Konzepte zur Speicherverwaltung (Abschnitt 8.4) und zur Anfragebearbeitung (Abschnitt 8.5). Eine Zusammenfassung und Bewertung runden die Ausführungen zu Pico-Datenbanksystemen ab.

8.2 Smartcards Geschichte

Klassifikation

Die Idee, Daten in maschinenlesbarer Form mobil verfügbar zu machen, reicht zurück ins Jahr 1915, als in den USA erstmals gestanzte Metallkarten eingesetzt wurden, um ein bargeldloses Ratenzahlungssystem zu etablieren. Gegen 1950 kamen, ebenfalls in den USA, geprägte Plastikkarten auf, die erste Ansätze zur Einführung eines bargeldlosen Zahlungsmittelverkehrs darstellten. In den folgenden Jahrzehnten kamen erst Magnetspeicherkarten, später optische Speicher- und Chipkarten auf. Diese hatten zunächst weder Prozessor noch Arbeitsspeicher integriert, sondern besaßen lediglich einen Festwertspeicher17, der nur einige wenige Daten speichern konnte. Im Laufe der Zeit wurden die Chipkarten jedoch immer leistungsfähiger, was schließlich ihren flächendeckenden Einsatz in unterschiedlichsten Anwendungsfeldern ermöglichte. Einer der ersten großen Einsätze von Chipkarten in Deutschland begann 1995 mit der Einführung von Krankenversicherungskarten im Scheckkartenformat zur Speicherung von Versicherungsdaten. Heute gibt es vielfältige Anwendungen, von der Geldkarte bis hin zur berührungslos nutzbaren Zugangskarte für Skilifte. Aus der technischen Historie heraus betrachtet, muss bei Chipkarten zwischen verschiedenen Klassen mit unterschiedlichen technischen Merkmalen unterschieden werden: ■

Speicherkarten. Bei klassischen Chipkarten handelt es sich um reine Speicherkarten, die ausschließlich einen Festwertspeicher geringer Größe integriert haben.

■

Smartcards. Aktuelle, äußerst leistungsfähige Chipkarten werden als Smartcards bezeichnet, die komplett miniaturisierte Rechnersysteme, das heisst Kleinstcomputer mit integrierter CPU, Arbeitsspeicher und persistentem Speicher sind. Da Smartcards über keine eigene Energiezufuhr verfügen, wird die notwendige Energie über das Kartenterminal bezogen.

17

Ein Festwertspeicher beziehungsweise ROM (Read Only Memory) ist ein Speicher, der während des normalen Speicherbetriebs nur gelesen werden kann. Man unterscheidet einige Varianten danach, ob der beliebig oft lesbare Inhalt irreversibel oder reversibel eingeschrieben wird und auf welche Weise dies geschieht.

176

■ ■ ■

8 Pico-Datenbanksysteme

■

Kontaktlose Smartcards. Kontaktlose Chipkarten sind eine relativ neue Variante der Smartcards, die keine physische I/OSchnittstelle in Form von Kontakten auf der Kartenoberfläche mehr haben. Die Leistungsaufnahme und die I/O-Schnittstellenkommunikation werden stattdessen über Mikrowellen realisiert.

8.2.1 Technischer Aufbau Das eine Smartcard mit Funktionalität ausstattende Mikroprozessorsystem ist immer in Plastikkarten verschiedener Größe eingebettet. Am gängigsten ist das Scheckkartenformat (85,7 mm x 54 mm). Das integrierte Mikroprozessorsystem weist typischerweise die folgenden technischen Merkmale auf (vgl. Abbildung 8.1): ■

32Bit-RISC-Prozessor,

■

I/O-Schnittstelle,

■

Read Only Memory (ROM),

■

Random Access Memory (RAM), sowie

■

Electronical Erasable Programmable Read Only Memory (EEPROM). Abb. 8.1: Aufbau einer Smartcard

Mikrochip RAM (Arbeitsspeicher)

CPU (Prozessor)

EEPROM (Applikationsspeicher)

I/O-System

ROM (Betriebssystem)

Physikalischer Aufbau

Kontaktierfläche

Der Read Only Memory, der 2004 typischerweise eine Größe von 96 kB aufweist, dient zur Speicherung des Betriebssystems und weiterer optionaler, dann aber fest installierter Komponenten, wie beispielsweise einer JavaCard Virtual Machine (falls die JavaCardTechnologie genutzt wird). Der Random Access Memory fungiert als klassischer Arbeitsspeicher und dient der Speicherung von Zwi-

8.2 Smartcards

Speichercharakteristika

■ ■ ■

177

schenergebnissen ausgeführter Anwendungen. Der Applikationsspeicher wird für die persistente Datenablage genutzt. Das EEPROM unterstützt vor allem schnelle Leseoperationen (60-100 ns/Wort). Schreiboperationen sind dagegen äußerst teuer (> 1 ms/Wort), das heisst langsam. Aktuelle Trends lassen eine baldige Integration weiterer nichtflüchtiger Speicher in Form von FlashSpeichermodulen erwarten, deren Einsatz eine Überwindung des latent vorhandenen Speicherengpasses verspricht.

8.2.2 Standards Standards

Wichtigster Smartcard-Standard ist der ISO 7816-Standard [JCa03]. Dieser legt physikalische Eigenschaften, wie Abmessung, Platzierung und Belegung der Kontakte oder die Biegsamkeit einer Smartcard fest. Zudem beschreibt der Standard welche Übertragungsprotokolle sowie Methoden und Konzepte der Datenrepräsentation verwendet werden können. Ein weiterer an Bedeutung gewinnender Standard ist der (noch) namenlose Standard der PC-Smartcard-Gruppe [PCS03], der unter anderem IBM angehört. Dieser Standard wird mit dem Ziel herstellerunabhängiger Interoperabilität entwickelt, was durch spezielle, herstellerunabhängige Programmierschnittstellen erreicht wird. Dritter wichtiger Standard ist der Opencard-Standard [OCS03]. Dieser vor allem von Sun Microsystems propagierte Standard macht die Java-Technologie auf Smartcards verfügbar. Grundlage des Standards ist eine in ihrem Funktionsumfang stark reduzierte Java Virtual Machine, eine einheitliche Schnittstelle zu allen Kartentypen und ein Programmierschnittstelle für die Integration von digitalen Signaturen und Dateizugriffen. Eine gesicherte Kommunikation zwischen Smartcard und Terminal erfolgt ausschließlich über ein spezielles Anwendungsprotokoll, das eine semantisch höhere Kommunikation implementiert, losgelöst von den Eigenheiten des tatsächlich verwendeten Transportprotokolls.

8.3 Eigenschaften von PicoDatenbanksystemen Technische Eigenschaften

178

■ ■ ■

Smartcards weisen technische Merkmale auf, die eines besonderen Designs der auf ihnen eingesetzten Datenbanksysteme bedürfen. Als Folge der geringen Speichergrößen müssen speziell angepasste Speichermodelle und -konzepte entwickelt werden, um Daten mög-

8 Pico-Datenbanksysteme

lichst kompakt ablegen zu können. Der Einsatz von CachingVerfahren ist nicht möglich, da die Eigenschaften der verschiedenen physischen Speicherklassen einer Smartcard dies nicht erlauben. Hinzu kommen angepasste Datenverarbeitungsmodelle, um die Größe von Ergebnissen, die temporär zwischengespeichert werden müssen, zu reduzieren. Dies spielt vor allem bei Anfragen eine Rolle, die komplexere relationale Operationen wie JOINs oder Gruppierungen (GROUP BY) enthalten. Von Bedeutung ist dabei auch, dass das Datenbanksystem selbst nur wenig Speicherplatz beansprucht. Datenbankapplikationen müssen ihre gesamte Kommunikation sowie alle Verarbeitungsoperationen durchführen und beenden, während sich die Smartcard im Terminal befindet. Dieses Kommunikationsszenario ist am ehesten mit einem Offline-Szenario vergleichbar, bei dem eine Synchronisation mit zentralen Datenbanken nur über das Kartenterminal erfolgen kann. Aktuell verfügen Smartcards noch nicht über die technischen Möglichkeiten, sich selbständig in vorhandene drahtlose Netzwerke einzuklinken, was gleichzeitig bedeutet, dass ein Online-Kommunikationsszenario noch nicht unterstützt wird. Aufgrund dieses unregelmäßigen Datenzugriffs ist eine regelmäßige periodische Reorganisation der gespeicherten Daten nicht möglich. Eine zusätzliche Anforderung an Pico-Datenbanksysteme ist die Implementierung einer weitgehend automatisch ablaufenden Administration der auf einer Smartcard ausgeführten Datenbankanwendung. Nutzern wird meist nur eine eingeschränkte Nutzerschnittstelle angeboten, die die Durchführung von Administrationsarbeiten nicht vorsieht. Die genannten Anforderungen machen deutlich, dass eine einfache Übernahme bekannter Konzepte und Techniken nur schwer möglich ist. Zwei der bedeutendsten Problemfelder sind die Entwicklung effizienter Speicherkonzepte und eine an den minimalen Hauptspeicher angepasste Anfragebearbeitung, die sowohl einfache wie auch komplexe Anfragen unterstützt (vgl. Kapitel 6). Im Mittelpunkt steht die Entwicklung von Techniken, die ohne eine Materialisierung von Zwischenergebnissen während der Anfrageausführung auskommen bzw. diese zumindest reduzieren. Als direktes Ergebnis dieser Erfordernisse und der eingeschränkten physischen Ressourcen von Smartcards kann der folgende Katalog von sechs Entwurfsregeln [Bob00] verstanden werden, der bei der Entwicklung von Pico-Datenbanksystemen berücksichtigt werden muss: ■

Kommunikationsszenario

Anforderungen an PicoDatenbanksysteme

Entwurfsregeln

Kompaktheitsregel. Die Größe des Programmcodes sowie der benötigte Speicherplatz allgemein müssen minimiert werden.

8.3 Eigenschaften von Pico-Datenbanksystemen

■ ■ ■

179

Ziel ist eine möglichst kompakte Speicherung, die mit dem sehr begrenzten Speicherplatz gut auskommt und ihn nicht verschwendet. ■

RAM-Regel. Die Belegung von Arbeitsspeicher während der Ausführung einer Datenbankanwendung muss weitgehend vermieden werden, falls der benötigte Arbeitsspeicher nicht abgeschätzt werden kann. Wird für eine Anwendung zuviel Arbeitsspeicher reserviert, wird Speicherplatz verschwendet. Wird für eine Anwendung dagegen zu wenig Arbeitsspeicher reserviert, kommt es zu einem Engpass. Im Idealfall sollte die Nutzung von Arbeitsspeicher komplett vermieden werden.

■

Schreib-Regel. Der Festwertspeicher (EEPROM) erlaubt lediglich extrem langsames Schreiben von Daten, so dass Schreiboperationen minimiert werden müssen. Im Idealfall sollte das Schreiben in den Festwertspeicher komplett vermieden werden.

■

Lese-Regel. Der Festwertspeicher (EEPROM) erlaubt sehr schnelles Lesen von Daten. Dies sollte ausgenutzt werden, da Leseoperationen im Vergleich zu Schreiboperationen äußerst billig, das heisst schnell sind.

■

Zugriffsregel. Möglichkeiten eines direkten Zugriffs und einer einfachen Adressierung des Festwertspeichers (EEPROM) müssen beim Lesen (und beim Schreiben) ausgenützt werden. Die dazu notwendigen Adressierungsmechanismen sind im Normalfall über das Betriebsystem der Smartcard verfügbar.

■

Sicherheitsregel. Auf Smartcards werden sehr oft personenbezogene, vertrauliche Daten gespeichert, die nicht nach außen hin verfügbar sein dürfen. Um höhere Sicherheit zu erreichen, müssen (abgesehen von einer wirksamen Zugriffskontrolle) vor allem sehr einfach gehaltene Algorithmen implementiert werden, da Sicherheitslücken (beispielsweise Buffer-Overflows) zumeist durch zu komplexe, nicht mehr überschaubare Algorithmen verursacht werden.

Nach der Einführung der technischen Merkmale von Smartcards in Abschnitt 8.2 und der gerade durchgeführten Untersuchung von Anforderungen an Pico-Datenbanksysteme, werden in den folgenden Abschnitten drei wichtige Problemfelder genauer untersucht, die bei der Implementierung von Pico-Datenbanksystemen eine entscheidende Rolle spielen. Die dabei präsentierten Lösungen adressieren die zuvor aufgestellten Anforderungen und zeigen, wie diese effizient umgesetzt werden können.

180

■ ■ ■

8 Pico-Datenbanksysteme

8.4 Speicherverwaltung Auf Smartcards integrierte Mikroprozessorsysteme verfügen über eine stark eingeschränkte Speicherkapazität. Bei der Implementierung einer Speicherverwaltung und entsprechender Zugriffsmechanismen für Pico-Datenbanksysteme ist es daher ein vorrangiges Ziel, die Nutzung des vorhandenen, beschränkten Speicherplatzes möglichst effizient zu gestalten. In den nächsten Abschnitten werden drei verschiedene Speicherkonzepte präsentiert [Bob00, Bob01], die diese Forderung umzusetzen versuchen.

8.4.1 Flat-Storage Flat-Storage ist die einfachste Form der drei Speicherkonzepte zur Datenorganisation. Er wurde jedoch nicht explizit für den Einsatz auf Smartcards entwickelt. Vielmehr handelt es sich um ein Speicherkonzept, das bereits in klassischen Datenbanksystemen eingesetzt wird. Beim Flat-Storage-Speicherkonzept werden die zu speichernden Relationen bzw. Tupel hintereinander sequentiell im physischen Speicher abgelegt. Dies ermöglicht ein schnelles, sequentielles Lesen von Tupeln (Relationenscan). Das kann sich als sehr vorteilhaft erweisen, da viele Zugriffe häufig eine starke Lokalität aufweisen. Gleichzeitig führt diese Speichermethode aber auch zu Nachteilen, die den Einsatz von Flat-Storage gerade auf Smartcards wenig sinnvoll erscheinen lassen: ■

Großer Speicherplatzbedarf. Zwar verhindern die Normalitätsregeln der relationalen Datenbankentwurfstheorie, dass ein Attribut semantisch redundant in einer Datenbank abgelegt wird. Besitzt ein Attribut jedoch in verschiedenen Tupeln mehrmals die gleiche Ausprägung, kommt es zu einer häufigen Wiederholung des Werts und damit zur Speicherplatzverschwendung.

■

Ineffizienz. Beim Flat-Storage-Speicherkonzept erfordern sämtliche Datenoperationen einen vorherigen, rein sequentiellen Tupelzugriff. Dies ist zwar gerade bei älteren Smartcards, die eine vergleichsweise geringe Speichergröße aufweisen, nicht wirklich ein Problem, da ohnehin nur sehr wenige Daten auf einer Smartcard abgelegt werden können. Doch muss davon ausgegangen werden, dass der auf Smartcards verfügbare Speicher-

8.4 Speicherverwaltung

Funktionsweise

Nachteile von Flat-Storage

■ ■ ■

181

platz zukünftig stark anwachsen wird, insbesondere wenn man Moore´s Law18 Glauben schenkt. Dieses Mehr an verfügbarem Speicher wird erfahrungsgemäß in den Anwendungen eine erheblich größere Zahl von Datenstrukturen, wie beispielsweise Relationen, zur Folge haben. Im Zuge dieser zunehmenden Speicherkapazität werden auch wesentlich komplexere Anfragen an die Datenstrukturen möglich. In jedem Fall ist ein effizienterer wahlfreier Zugriff (Random Access) wünschenswert, um diese neuen Eigenschaften und Anforderungen adäquat besser zu unterstützen. Kritik

Diese beiden gerade beschriebenen Nachteile zeigen deutlich, dass der Einsatz von Flat-Storage bei Smartcards möglich, in Zukunft jedoch wenig sinnvoll erscheint. Wie der nächste Abschnitt zeigt, kann aber auch Flat-Storage in Kombination mit alternativen Speicherkonzepten seine berechtigte Anwendung finden.

8.4.2 Domain-Storage

Funktionsweise

Optimierung

Im Hinblick auf die Nachteile von Flat-Storage ist es das Ziel, ein alternatives Speichermodell zu entwickeln, das eine kompakte Speicherung erlaubt, sowohl von abgelegten Nutzerdaten als auch der Indexstrukturen. Interessant ist das Konzept einer zeigerbasierten Speicherung, das die Grundlage von Domain-Storage ist. Die Idee dabei ist, in einem Tupel keine konkreten Attributausprägungen, sondern Zeiger auf Attributausprägungen abzuspeichern. Die tatsächlichen Attributausprägungen sind in einer von den Tupeln getrennten Datenstruktur abgelegt. Für jedes Attribut wird eine eigene Datenstruktur angelegt, die alle belegten Ausprägungen seines Wertebereichs enthält. Der Vorteil dieses Speicherkonzepts (vgl. Abbildung 8.2) ist offensichtlich: statt einen Attributwert mehrfach abzuspeichern (wenn dieser in mehreren Tupeln vorkommt), wird jede mögliche Attributausprägung nur ein einziges Mal an zentraler Stelle in einer Hilfsdatenstruktur abgelegt. Eine weitere Speicherplatzoptimierung kann erreicht werden, indem sich Attribute mit überschneidenden Wertebereichen eine gemeinsame Hilfsdatenstruktur teilen. Je weniger Ausprägungen ein Attribut besitzt und je häufiger gleichzeitig eine Attributausprägung in einem Tupel vorkommt, desto effizienter ist Domain-Storage. 18

182

■ ■ ■

Die Rechnerleistung von Computersystemen verdoppelt sich alle 18 Monate.

8 Pico-Datenbanksysteme

Andererseits büßt das Speicherkonzept in seiner Wirkung deutlich ein, wenn insgesamt nur wenige Attribute sehr viele Attributausprägungen besitzen. In diesem Fall benötigen die Hilfsdatenstrukturen wesentlich mehr Speicherplatz als eine einfache sequentielle Speicherung wie beim Flat-Storage.

Abb. 8.2: Domain-Storage

Tupel i

Attribut mit Wertebereich

Kritik

Wert 1

Hilfsdatenstruktur

Wert n Relation R

Relation S

In unklaren Fällen kann eine Kombination von Domain-Storage mit dem zuvor vorgestellten Flat-Storage sinnvoll sein. Dies wird dann als Dual-Speicherkonzept bezeichnet. Dabei wird zunächst (als Standardfall) Domain-Storage verwendet. Zeigt sich jedoch das für den Domain-Storage oben beschriebene Negativszenario, wird auf den in diesem Fall effizienteren Flat-Storage zurückgegriffen.

DualSpeicherkonzept

8.4.3 Ring-Storage Der Ring-Storage ist eine evolutionäre Weiterentwicklung des Domain-Storage. Dieses Speicherkonzept fokussiert dabei nicht nur auf die Kompaktheit der Anwendungsdaten, sondern stellt zusätzlich eine kompakt abgelegte (einfache) Indexstruktur zur Verfügung. Wie der Domain-Storage zuvor basiert auch der Ring-Storage auf einem zeigerbasierten Speicherkonzept. Um den Ring-Storage zu veranschaulichen, muss zunächst jedoch kurz auf klassische Auswahlindexe eingegangen werden.

8.4 Speicherverwaltung

■ ■ ■

183

Auswahlindex

Ein Auswahlindex besteht für gewöhnlich aus zwei Teilen: einer Sammlung von Werten und einer weiteren Sammlung von Zeigern, die auf alle zu einem Attributwert gehörenden Tupel verweisen (vgl. Abbildung 8.3). Dabei spielt es in unserem Fall keine Rolle, ob ein Auswahlindex für ein Schlüssel- oder ein Nicht-Schlüsselattribut definiert wird. Entscheidend ist, dass in der Werteliste jede Ausprägung genau einmal vorkommt, auch wenn dieser Wert Zeiger auf mehrere Tupel besitzt. Damit handelt es sich um einen dichten Index (Dense Index). Ein dichter Index besitzt für jeden Suchschlüsselwert des indizierten Attributs einen Indexeintrag. Die Indexstruktur besteht somit aus zwei Teilen: einer duplikatfreien Sammlung aller auftretenden Werte des Wertebereichs des indizierten Attributs (dem dichten Index) sowie einer dazugehörigen Sammlung von Zeigern, die auf die relevanten Tupel zeigen. Diese Indexstruktur bildet die Ausgangsbasis für Ring-Storage.

Abb. 8.3: Auswahlindex

Indiziertes Attribut

Tupel i

Wert 1

Indexdatenstruktur

Wert n

Relation R Funktionsweise

184

■ ■ ■

Der Unterschied zwischen Domain-Storage und Ring-Storage besteht nun in der Richtung der eingesetzten Zeiger: beim DomainStorage wurden die auftretenden Attributwerte in einer separaten Datenstruktur gespeichert, und in den Tupeln wurden lediglich die Zeiger auf die Werte in dieser Datenstruktur gespeichert. Dagegen referenziert die Indexstruktur bei Ring-Storage die in den Tupeln stehenden Attribute. Wird von den beiden Bedingungen ausgegangen,

8 Pico-Datenbanksysteme

■

dass auf einem beliebigen Attribut ein dichter Index angelegt werden soll, und

■

dass weiterhin der Einsatz des Domain-Storage-Speicherkonzepts genau für dieses zu indizierende Attribut vorteilhaft im Vergleich zum Flat-Storage ist,

dann können die Indexdatenstruktur und die Hilfsdatenstruktur des Domain-Storage miteinander kombiniert und zu einer einzigen gemeinsamen Datenstruktur verschmolzen werden. Diese neue Datenstruktur heisst Ring-Storage. Der Vorteil ist ersichtlich: die Ausprägungen eines Attributs werden als explizite Datenstruktur ausgelagert, wie es schon beim Domain-Storage der Fall war. Gleichzeitig kann die neue Datenstruktur aber auch als dichte Indexdatenstruktur implementiert werden. Somit verbleibt an dieser Stelle nur die Frage, wie die Zeiger in dieses Konzept integriert werden können. Abb. 8.4: Ring- Storage

Wert 1

Domain

Indiziertes Attribut

Tupel i

Wert n Relation R

Dichte Indexdatenstruktur

Einerseits muss von den Tupeln aus die zu einem bestimmten Attribut gehörende Datenstruktur mit den Attributausprägungen erreichbar sein. Dies kann als Tupel-To-Value-Prinzip des Domain-Storage bezeichnet werden. Andererseits muss aber auch von einem Indexeintrag der Hilfsdatenstruktur aus auf die zugehörigen Tupel verwie-

8.4 Speicherverwaltung

■ ■ ■

185

Ringstruktur

Kritik

sen werden können. Dies wird als Value-To-Tupel-Prinzip des Auswahlindex bezeichnet. Die Lösung ist eine ringförmige Verkettung eines Indexeintrags mit den von ihm indizierten Tupeln (vgl. Abbildung 8.4). So können von der Indexdatenstruktur die indizierten Tupel erreicht werden, während gleichzeitig von den Tupeln aus die konkreten Attributwerte in der Indexdatenstruktur zugegriffen werden können. Im schlechtesten Fall muss ein Ring zwar fast vollständig durchlaufen werden, im durchschnittlichen Fall reduziert sich dieser Aufwand jedoch auf einen halben Ringdurchlauf, was angesichts der erreichten Speicherplatzminimierung vertretbar ist. Der Vorteil des Ring-Storage-Speichermodells liegt darin, dass der Index (fast) keinen zusätzlichen Speicherplatz benötigt. Der RingStorage kann als Erweiterung vom Domain-Storage verstanden werden. Als Nachteil muss jedoch aufgeführt werden, dass der Zugriff auf den Wert eines im Ring gespeicherten Attributs teurer wird. So ist für den Zugriff auf ein Attribut im Durchschnitt die Durchquerung des halben Rings erforderlich. Dies ist insbesondere dann aufwendig, wenn potentiell viele Wertwiederholungen existieren und damit sehr grosse Ringe entstehen.

8.5 Anfragebearbeitung

Problematik

Wie die Speicherkonzepte zuvor muss auch die Anfrageverarbeitung bei Pico-Datenbanksystemen an die eingeschränkten Fähigkeiten von Smartcards angepasst werden. Traditionelle Algorithmen zur Anfragebearbeitung können beispielsweise in den meisten Fällen auf genügend Arbeitsspeicher zurückgreifen, um Zwischenergebnisse und andere temporär anfallende Datenstrukturen zwischenzuspeichern. Ist der Arbeitsspeicher dafür nicht groß genug, können größere Datenstrukturen und Ergebnisse zwischenzeitlich sogar auf Sekundärspeicher ausgelagert werden. Diese Vorgehensweise klassischer Algorithmen erweist sich im Zusammenhang mit Smartcards jedoch als äußerst problematisch. Die Gründe dafür können anhand der bereits definierten Entwurfsregeln (vgl. Kapitel 8.3) verdeutlicht werden: ■

186

■ ■ ■

RAM-Regel. Der zur temporären Ablage von Datenstrukturen einer Abfrage notwendige Speicherplatz steht vor der Ausführung einer Anfrage nicht fest. Die Reservierung eines zu kleinen Speicherbereichs bedeutet, Speicherüberläufe (Memory-

8 Pico-Datenbanksysteme

Overflow) zu riskieren. Wird der reservierte Speicherbereich dagegen zu groß gewählt, besteht die Gefahr, dass unnötig grosse Speicherplatzbereiche unnötig belegt werden. ■

Schreib-Regel. Die Kosten von Schreiboperationen sind sehr hoch. Schreiboperationen, wie sie zur Materialisierung von Zwischenergebnissen bei einem Speicherüberlauf im Arbeitsspeicher notwendig wären, führen somit zu drastischen Performanzeinbußen. Wird darüber hinaus berücksichtigt, dass die Speicher einer Smartcard eine (im Vergleich zu normalem Arbeits- und Sekundärspeicher) noch recht kurze Lebensdauer haben, erweist es sich als nachteilig, fortlaufend Zwischenergebnisse zu materialisieren und später wieder zu löschen. Dadurch kann sich die Lebensdauer des Speichers erheblich reduzieren.

■

Komplexität. Die heutigen Algorithmen zur Anfrageausführung in Datenbanksystemen sind effizient, gleichzeitig aber auch komplex. Smartcards setzen für Algorithmen implizit voraus, dass diese einfach und kompakt implementiert sind.

Bei der Query-Auswertung auf Smartcards wird daher versucht sicherzustellen, dass möglichst wenig auf den Arbeitsspeicher zugegriffen wird und keine Zwischenergebnisrelationen im Festwertspeicher materialisiert werden müssen [Bob00]. Dazu müssen die Query-Execution-Pläne so umgestrickt werden, dass sie ein striktes Pipelining realisieren. Wir unterscheiden im Folgenden zwischen einfachen und komplexen Anfragen unterschieden. Einfache Abfragen sind klassische SELECT-PROJECT-JOIN-Anfragen, komplexe Anfragen enthalten auch zwischenspeicherintensivere Operationen, wie Aggregatfunktionen oder Methoden zur Duplikateliminierung.

Einfache vs. Komplexe Anfragen

8.5.1 Einfache Abfragen Die Ausführung einer in SQL formulierten Anfrage erfolgt bekanntlich in zwei Schritten (vgl. Kapitel 6.1). Zunächst wird mit Hilfe eines Parsers und eines Optimierers ein möglichst optimaler Ausführungsplan zu einer gegebenen Anfrage erstellt. Ausführungspläne sind gerichtete azyklische Graphen über relationalen Algebra-Operatoren. Anschließend wird der gewählte Ausführungsplan zur Ausführung gebracht. Die Ausführungskomponente ist für gewöhnlich als Bibliothek relationaler Operatoren implementiert. Für die Ausführung einer Anfrage werden die relationalen Operatoren des Aus-

8.5 Anfragebearbeitung

■ ■ ■

187

führungsplanes durch die Implementierungen der jeweiligen Bibliothekseinträge ersetzt. Bei der Erstellung von Ausführungsplänen kann auf verschiedene Grundformen von Ausführungsgraphen zurückgegriffen werden. Klassische Grundformen sind der Left Deep Tree, der Right Deep Tree und der Bushy Tree. Dazu ein Beispiel [Bob00]: die Anfrage „Welcher Arzt verschrieb im Jahr 2003 Antibiotika?“ soll auf dem folgenden Datenbankschema ausgeführt werden. Die Basisrelationen liegen dabei bereits materialisiert im Speicher vor. Doktor (DokID, Name, Fachgebiet, ...) Rezept (RezeptID, MedikamentID, …) Arztbesuch (BesuchID, DokID, Datum, Diagnose, …) Medikament (MedID, Name, Typ, …)

In einem Left Deep Tree (vgl. Abbildung 8.5) werden alle auftretenden Operatoren Schritt für Schritt unter Verwendung der bereits materialisierten Basisrelationen ausgeführt. Die Basisrelationen entsprechen stets den Baumblättern. Alle inneren Knoten repräsentieren auszuführende Operationen. Die Ausführungsreihenfolge beginnt in den Blättern des Baumes. Anfallende Zwischenergebnisse müssen im Arbeitsspeicher materialisiert werden. Abb. 8.5: Ausführungsgraph eines Left Deep Tree [Bob00]

= Materialisation - Pipelining

Join Join

Join

Doktor

Selektion

Selektion Rezept

Arztbesuch

Medikament Im Beispiel beginnt die Ausführung bei der Basisrelation Medikament, auf der eine Selektion ausgeführt wird. Auf dem Ergebnis dieser Selektion wird anschließend eine JOIN-Operation mit der Basisrelation Rezept ausgeführt. Eine Materialisierung von Zwischenergebnissen im Arbeitsspeicher erfolgt in diesem Fall also automatisch. Right Deep Trees und Bushy Trees funktionieren ähnlich, das heisst auch bei diesen Grundformen kommt es stets zu einer Materialisierung von Zwischenergebnissen.

188

■ ■ ■

8 Pico-Datenbanksysteme

Soll die Materialisierung von Zwischenergebnissen im Arbeitsspeicher vermieden werden, stellen Left Deep Trees, Right Deep Trees oder Bushy Trees keine geeignete Alternative dar. Trotzdem müssen Methoden gefunden werden, die genau diese für die Smartcards so wichtige Forderung effektiv umsetzen. Ein Verfahren, das die Materialisierung von Zwischenergebnis verhindert, ist das PipeliningVerfahren, das deswegen genauer vorgestellt wird.

8.5.2 Pipelining Das Pipelining-Verfahren gestattet die Weitergabe von Zwischenergebnissen der Anfrageverarbeitung, ohne dass es zu temporären Materialisierungen im Arbeitsspeicher kommt. Das Verfahren basiert dabei auf dem Iterator-Modell [Bob00, Bob01]. Dieses Modell ordnet jedem relationalen Operator drei verschiedene Methoden zu, die zusammen ein neues Ausführungsmodell bzw. eine neue Vorgehensweise zur Durchführung einer Operation definieren. Als Ergebnis dieser Vorgehensweise können die Zwischenergebnisse einer Operation ohne Materialisierung, das heisst on-the-fly in der Verarbeitungskette des Ausführungsgraphens weitergereicht werden. Die drei angesprochenen Methoden sind: ■

Open. Die Methode OPEN bereitet die Produktion eines ersten Ergebniselements des relationalen Operators vor.

■

Next. Die Methode NEXT produziert ein Ergebniselement, nachdem ein berechnetes Ergebniselement on-the-fly weitergereicht wurde. Zu Beginn der Ausführung eines relationalen Operators wird mit dieser Methode das erste Ergebniselement ermittelt.

■

Close. Für einen relationalen Operator wird mit der Methode CLOSE seine Ausführung beendet, das heisst es werden keine weiteren Ergebniselemente mehr berechnet.

Um ein Pipelining zu realisieren, ist es erforderlich, Operationen gegebenenfalls entsprechend den Regeln der relationalen Algebra so umzusortieren, dass eine möglichst lange Pipeline-Kette (ohne Unterbrechung) entsteht. Dazu müssen alle Operationen, die vor Operationen stehen, deren Eingaben zwingend materialisiert sein müssen, vor der Pipeline ausgeführt werden. Nur in diesem Fall kann jegliche Materialisierungen innerhalb der Pipeline vermieden werden. Lediglich das Endergebnis einer Anfrage wird dann materialisiert, um die

8.5 Anfragebearbeitung

■ ■ ■

189

weitere Verarbeitung des Ergebnisses durch Anwendungen zu ermöglichen. Als Beispiel eines Ausführungsplanes, der eine Materialisierung von Zwischenergebnissen durch den Einsatz des PipeliningVerfahrens vollständig verhindert, ist nachfolgend ein Extreme Right Deep Tree abgebildet (vgl. Abbildung 8.6). Alle Operanden einer Operation – mit Ausnahme der Operanden, die direkt aus einer Basisrelation stammen – können dabei on-the-fly verarbeitet werden. Jede Anfrageausführung beginnt zunächst im Wurzelelement des Ausführungsplanes. Der Wurzelknoten (in unserem Beispiel also JOIN) fordert die zur Durchführung der von ihm implementierten Operation notwendigen Datenelemente bei seinen Kindknoten (Basisrelation DOKTOR und Operation SELEKTION) an. Materialisierte Basisrelationen sind dabei immer die Blätter des Ausführungsgraphens, relationale Operatoren die die inneren Baumknoten. Wenn einer der Kindknoten bereits eine materialisierte Basisrelation ist (wie im Beispiel), können dem Wurzelknoten von dieser Seite bereits Operanden zur Verfügung gestellt werden. Da dies von der anderen Seite jedoch noch nicht möglich ist, muss auf der rechten Seite weiter im Baum nach unten abgestiegen werden. Abb. 8.6: Ausführungsgraph eines Extreme Right Deep Trees [Bob00]

Join Doktor

Selektion Join Join

Arztbesuch Rezept

Selektion Medikament

Dieses Absteigen im Ausführungsgraphen setzt sich zunächst solange fort, bis ein relationaler Operator (im Beispiel der unterste JOIN) erreicht wird, dessen Kindknoten eine materialisierte Basisrelation ist. Die Basisrelationen bzw. materialisierten Relationen reichen nun Operanden an den Vaterknoten (im Beispiel die JOIN-Operation) weiter. Dieser führt unter Verwendung der übermittelten Operanden sukzessive seine Operation aus und reicht seine Ergebnisse dabei ebenfalls on-the-fly an den eigenen Vaterknoten (im Beispiel die mittlere JOIN-Operation) weiter.

190

■ ■ ■

8 Pico-Datenbanksysteme

Diese Prozedur wird für jeden relationalen Operator solange fortgesetzt, bis keine weiteren Operanden mehr nachkommen und somit keine weiteren Ergebniselemente mehr berechnet werden können. Am Ende erzeugt der Wurzelknoten das Gesamtergebnis der Anfrage. Dabei wurden unter Berücksichtigung der getroffenen Annahmen keine weiteren Zwischenergebnisse materialisiert.

8.5.3 Komplexe Abfragen Komplexe Anfragen enthalten aufwendigere relationale Operatoren, als die zuvor vorgestellten einfachen Anfragen. Typische komplexe Anfragen beinhalten Aggregatfunktionen (SUM, COUNT, MAX, MIN, AVG), Gruppierungen (GROUP BY), Duplikateliminierungen (SELECT DISTINCT) oder Sortieroperationen (SORT BY). Diese Operationen werden üblicherweise auf materialisierten Zwischenergebnissen ausgeführt, die sich während der Anfrageausführung ergeben. Da auch im Fall komplexer Anfragen eine solche Materialisierung im Allgemeinen vermieden, bzw. zumindest auf ein Minimum reduziert werden soll, wird auch hier in weiten Bereichen das Pipelining-Verfahren eingesetzt. Das grundlegende Funktionsprinzip wird dabei nicht verändert. Aufgrund der Charakteristik komplexer relationaler Operatoren nimmt aber die Schwierigkeit zu, einen geeigneten Ausführungsgraphen zu finden, der ein vollständiges Pipelining unter den getroffenen Annahmen für alle relationalen Operatoren ermöglicht. Als besonders schwierig erweist sich insbesondere das Finden eines Ausführungsgraphens für Anfragen, die Gruppierungsoperationen beinhalten. Diesbezüglich werden zusätzliche Algorithmen benötigt, deren Funktionsweise in [Bob00] genauer beschrieben wird.

8.6 Zusammenfassung Smartcards sind klein, günstig und leicht in großen Stückzahlen herzustellen, wohingegen sie in ihren Systemressourcen äußerst eingeschränkt sind. Die zunehmende Leistungsfähigkeit von den auf den Smartcards integrierten Mikroprozessorsystemen und die Verfügbarkeit einfach zu bedienender Programmierumgebungen für Smartcard-Applikationen (wie JavaCard) werden in nächster Zeit zunehmend neue Anwendungsfelder, gerade im Datenbankenumfeld, erschließen. Smartcards gehören aktuell zu den am schnellsten wachsenden Märkten für professionelle Anwendungssoftware. Smartcards wer-

8.6 Zusammenfassung

■ ■ ■

191

den in ihrer Bedeutung stetig zunehmen und deswegen auch in Forschung und Entwicklung weiterhin präsent bleiben. Die in klassischen Datenbanksystemen verwendeten Konzepte, Methoden und Algorithmen können nicht direkt auf PicoDatenbanksysteme übertragen werden. Spezielle Anpassungen sind notwendig, die sich direkt aus den Anforderungen an die Architektur und das Design von Datenbanksystemen für Smartcards sowie aus den eingeschränkten physischen Ressourcen ergeben. Angepasste Speichermodelle (Flat-Storage, Domain-Storage, Ring-Storage) und Methoden zur Anfrageausführung (Pipelining) sind notwendig und wurden in ihren wichtigsten Konzepten vorgestellt.

192

■ ■ ■

8 Pico-Datenbanksysteme

Teil 2 Systeme

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Mobile Einheiten, wie PDAs, werden in Unternehmen aufgrund ihrer ständig zunehmenden Leistungsfähigkeit nicht mehr ausschließlich für rein administrative Groupwarelösungen, wie zum Beispiel für eine unternehmensweite Terminplanung, eingesetzt. Vielmehr wurden mobile Clients zu wichtigen Komponenten für die Integration von Geschäftsprozessen und bestehender IT-Infrastrukturen.

9.1 Motivation Viele Geschäftsapplikationen bieten mittlerweile Schnittstellen für einen drahtlosen mobilen Zugriff an. Gerade mit dem Bedürfnis nach einer effizienteren mobilen Datenverarbeitung in Unternehmen entstanden in den letzten Jahren diverse kommerzielle mobile Datenbanksysteme. Diese erlauben den Aufbau umfassender Infrastrukturen mobiler Datenverarbeitung. Dabei konkurrieren in ihrer Funktionalität sehr umfangreiche Produkte großer Hersteller, wie IBM, Microsoft oder Oracle, mit schlankeren Produkten kleinerer Hersteller, wie PointBase oder Sybase. Für die Auswahl und den Einsatz eines bestimmten Produktes ist es deshalb wichtig, die den einzelnen Produkten zugrunde liegenden Konzepte und Implementierungsdetails zu kennen und einschätzen zu können. In diesem Kapitel werden deshalb die sechs wichtigsten verfügbaren kommerziellen mobilen Datenbanksysteme mit ihren Architekturprinzipien und Implementierungskonzepten vorgestellt und bewertet. Der weitere Aufbau dieses Kapitels gliedert sich wie folgt. Abschnitt 9.2 untersucht das von IBM entwickelte mobile Datenbanksystem DB2 Everyplace [DB2e04]. Abschnitt 9.3 stellt das von

9.1 Motivation

Kommerzielle mobile Datenbanksysteme

Untersuchte Systeme

■ ■ ■

195

Oracle angebotene mobile Datenbanksystem Oracle 10g Lite [ORA04] vor. Die Abschnitte 9.4 und 9.5 beschreiben die von der Sybase-Tochter iAnywhere entwickelten Produkte Adaptive Server Anywhere und UltraLite [SAS04], sowie die von der Software AG vermarktete mobile XML-Lösung Tamino Mobile Suite [TAM04]. Abschnitt 9.6 geht auf einen Newcomer bei den mobilen Datenbanksystemen ein, PointBase Micro [PBM04]. Abschnitt 9.7 präsentiert die wichtigsten Features und Konzepte des Microsoft SQL Server 2000 CE Edition [SQL04]. Abschnitt 9.8 geht abschließend kurz auf drei weitere Datenbanksysteme ein, die aufgrund ihrer Größe auch auf mobilen Geräten eingesetzt werden können: eXtremeDB, hSQLDB und InstantDB. Bei den beiden letzten handelt es sich um Opensource-Projekte. Abschnitt 9.9 vergleicht die Produkte anhand wichtiger Kriterien wie Plattformunterstützung oder Erweiterbarkeit. Klassifikation

Bei den von den untersuchten Systemen umgesetzten Anwendungsarchitekturen lassen sich zwei grundlegende Ansätze unterscheiden [Mut03]: dem klassischen, um spezielle Middleware ergänzten Client/Server-Ansatz, wie er bei DB2 Everyplace, Oracle 10g Lite, Tamino Mobile Suite und Microsoft SQL Server CE Edition realisiert wird, steht als Alternative die vollständige Integration einer mobilen Datenbank in eine Anwendung gegenüber. iAnywhere’s UltraLite und PointBase Micro sind Vertreter dieser zweiten Klasse. Während im ersten Fall die mobile Datenbank von den auf sie zugreifenden Anwendungen als eigenständige Komponente getrennt bleibt, wird beim letzteren eine in ihrer Funktionalität angepasste Datenbank vollständig in eine Anwendung integriert. Die Unabhängigkeit der Datenbank von den Anwendungen wird in diesem Fall somit aufgegeben.

9.2 IBM DB2 Everyplace Plattformunterstützung

196

■ ■ ■

Das mobile Datenbanksystem DB2 Everyplace (Version 8.1.4, April 2004) implementiert ein relationales Datenmodell. Es existieren Versionen für die Plattformen Palm-OS (Version 5.0), Symbian (Version 7), Pocket PC und die Win32-Plattformen (Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP). Aber auch QNX Neutrino, Linux- und Embedded Linux-Clients (wie beispielsweise die Sharp Zaurus Baureihe) werden unterstützt. Große Flexibilität bei der Auswahl einer Hardware-Plattform wird insbesondere durch Java-fähige Clients erreicht. An Prozessortypen wer-

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

den unter anderem Intels x86-Prozessor-Familie, IBMs PowerPCProzessoren, Motorolas Dragonball-Prozessoren sowie StrongARMProzessoren unterstützt. Mit der aktuellen Version 8.1.4 wurde zudem die Unterstützung weiterer Prozessortypen auf Neutrino- und Linux-Plattformen integriert.

9.2.1 Komponenten Eine mobile Infrastruktur, wie IBM sie versteht, besteht aus einem Datenbankserver im Backend (beispielsweise einer IBM DB2Installation), aus leichtgewichtigen Datenbanksystemen auf den mobilen Clients (DB2 Everyplace) und aus einer zusätzlichen Middleware-Komponente, dem Synchronisationsserver (DB2 Everyplace SyncServer). Diese Komponenten, die den Aufbau DB2 Everyplacebasierter Lösungen erlauben, werden nun im Detail vorgestellt (ausgehend vom mobilen Client, hin zum Backend):

Aufbau einer mobilen Infrastruktur

■

DB2 Everyplace. DB2 Everyplace ist das mobile SmallFootprint-Datenbanksystem, das auf den mobilen Clients installiert wird. Das mobile Datenbanksystem ist in der DB2 Everyplace Database Edition, in der DB2 Everyplace Enterprise Edition, in der DB2 Everyplace Express Edition und auch im DB2 Everyplace Software Development Kit enthalten. Die Installation des mobilen Datenbanksystems benötigt auf einem mobilen Client ungefähr 180-220 kB an Speicherplatz.

Mobiler Client

■

SyncServer. Der SyncServer ist ausschließlich in der DB2 Everyplace Enterprise Edition enthalten. Der SyncServer ist für die Koordination und Verwaltung von Synchronisationsvorgängen zuständig. Als Middleware-Komponente zwischen mobilen Clients und Datenbankserver kann er auf einem eigenen Host, aber auch auf demselben Rechnersystem wie der Datenbankserver installiert sein. Der SyncServer erlaubt die Synchronisation von relationalen Daten zwischen mobilen DB2-EveryplaceEinheiten und beliebigen JDBC-fähigen Datenbanken im Backend. Auf den mobilen Clients existiert mit dem SyncClient eine funktional dem SyncServer ähnliche Komponente, die für die Synchronisation des mobilen Datenbanksystems zuständig ist. Synchronisation kann sowohl bidirektional als auch unidirektional in verschiedenen Szenarien erfolgen. Während eines Synchronisationsprozesses auftretende Synchronisationskonflikte versucht der SyncServer mit Hilfe eines Versionskontrollsystems zu erkennen und zu lösen, ohne jedoch zu garantieren, dass

Middleware

9.2 IBM DB2 Everyplace

■ ■ ■

197

alle auftretenden Konflikte auch automatisch behoben werden können. Zusammen mit dem SyncServer wird ein GUI-Tool ausgeliefert, das Mobile Devices Administration Center (MDAC), das eine einfache Durchführung von SyncServerAdministrationsaufgaben, wie die Koordination von Synchronisationsprozessen oder das Management mobiler Nutzer ermöglicht. Das GUI-Werkzeug unterstützt darüber hinaus die Ausführung einfacher Skripte, die mit einer speziellen XMLbasierten Syntax formuliert werden. Mit solchen Skripten kann eine effektive Automatisierung bei der Durchführung von Verwaltungsaufgaben erreicht werden. Backend

■

Abb. 9.1: DB2 EveryplaceProdukte

Datenbankserver. Durch die vom SyncServer gegebene JDBCUnterstützung können im Backend alle diejenigen Datenbanksysteme angebunden werden, die ebenfalls die JDBCSchnittstelle unterstützen (DB2, Informix, Oracle, MS SQL Server, Sybase). Unter Verwendung einer Spezialkomponente können auch die DB2-Varianten für Workstations der zSeries und iSeries19 angesprochen werden. SyncClient

SyncServer DB2 Everyplace

Anwendungsentwicklung

■

19

198

■ ■ ■

DatenbankServer

Mobile Application Builder

Mobile Application Builder (MAB). Der MAB ist ausschließlich im DB2 Everyplace Software Development Kit enthalten. Dabei handelt es sich um eine integrierte Entwicklungsumgebung, die die schnelle Entwicklung mobiler Datenbankanwendungen mit den Programmiersprachen C und Java erlaubt. Über ein Plug-In können auch Anwendungen mit Visual Basic programmiert werden. Die Verwendung des MAB setzt allerdings die Installation einiger weiterer Werkzeuge (zum Beispiel eines C-Compilers) voraus, die auf dem Entwicklungssystem ebenfalls zwingend installiert sein müssen (vgl. Kapitel 10.2).

früher RS/6000 bzw. AS/400

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Mit den drei zuerst beschriebenen Komponenten bzw. Produkten kann eine dreistufige Architektur (Three-Tier-Architecture) erstellt werden (vgl. Abbildung 9.1). Diese besteht aus dem mobilen Datenbanksystem DB2 Everyplace auf den mobilen Clients, aus dem Synchronisationsserver SyncServer und einem Datenbankserver im Backend. Ob der Synchronisationsserver als eigenständiges HostSystem oder als Modul auf dem gleichen Host wie der Datenbankserver konfiguriert wird, bleibt dem Datenbank-Administrator überlassen und kann somit frei gewählt werden.

3-Tier Architecture

9.2.2 Architektur der clientseitigen Datenbank-Engine Die Architektur der DB2 Everyplace-Datenbank-Engine folgt einem schichtenorientierten Ansatz (vgl. Abbildung 9.2). Die Engine besteht aus zwei Hauptkomponenten: der SQL Runtime Environment und den Data Manager Services (DMS). Beide zusammen sind für die Ausführung von Anfragen zuständig. Eine von einer Anwendung abgesetzte Anfrage richtet sich dabei immer an den Datenbestand der lokalen mobilen Datenbank, niemals an entfernte Datenquellen. Letztlich folgt die Datenbankarchitektur der bekannten Referenzarchitektur [Här01]. Abb. 9.2: Architektur der DB2 EveryplaceEngine [Fan03]

CLI / ODBC / JDBC SQL Runtime Environment

DB2 Everyplace Engine

Parser Semantic Checker Optimizer

Catalog Management

Interpreter

Data Manager Services (DMS) Record Manager

Index Manager

Buffer and Recovery Management

DB2 Storage

File System Interface

DB2 Everyplace unterstützt die dynamische Ausführung von SQLStatements. Auf Datenbanktabellen kann unter Verwendung bekann-

9.2 IBM DB2 Everyplace

Datenzugriff

■ ■ ■

199

SQL Runtime Environment

Data Manager Services

ter Standard-APIs (DB2 CLI, ODBC, JDBC) zugegriffen werden. Die SQL-Syntax von DB2 Everyplace ist eine Untermenge der SQL-Syntax der DB2 Universal Database, wobei Selektionen, Projektionen, Joins, Gruppierungen, Aggregationen und Sortierungen unterstützt werden. Die SQL Runtime Environment besteht aus dem SQL-Compiler und einem Laufzeit-Interpreter, der für die Ausführung des Ausführungsplanes (Query Execution Plan) zuständig ist. Der SQL-Compiler enthält einen Parser, einen Semantikprüfer (Semantic Checker) sowie einen Optimierer (Optimizer). Der Parser ist für die syntaktische Analyse und Validierung der gestellten SQL-Anfrage zuständig. Der Semantikprüfer testet, ob die Struktur der SQL-Anfrage mit der Struktur des Datenbankschemas übereinstimmt. Dazu verwendet er Meta-Informationen, die in den Katalogtabellen (Catalog Tables) gespeichert sind. Der Optimierer wählt, wie dies in gewöhnlichen relationalen Datenbanksystemen der Fall ist, aus verschiedenen Ausführungsplänen einer SQL-Anfrage einen möglichst Optimierten aus. Dabei kommt jedoch keine kostenbasierte, sondern lediglich eine heuristische Optimierung zum Einsatz, da kostenbasierte Optimierungen für den beschränkten Hauptspeicher und Prozessortakt mobiler Geräte viel zu aufwendig wären. Nach Auswahl eines Ausführungsplans wird dieser durch den Interpreter ausgeführt. Die Data Manager Services enthalten verschiedene Komponenten: den Record Manager, den Index Manager, den Buffer Manager, den Recovery Manager und das File System Interface: ■

Record Manager. Der Record Manager ist für die Verwaltung und Speicherung einzelner Datensätze (= Tupel) zuständig, von denen jeder aus mehreren Attributen besteht. Die zu speichernden Tupel werden sequentiell und zusammenhängend im Speicher abgelegt. Falls möglich, wird jeder Attributwert intern in ein kompakteres Speicherformat transformiert.

■

Index Manager. Der Index Manager ist für die Verwaltung und Speicherung von Indexstrukturen verantwortlich, die auf einzelnen Tabellenspalten definiert werden können. Als Indexstruktur kommen Patricia Tries20 zum Einsatz. Auf den Attributen einer Tabelle können bis zu 15 Indizes definiert werden, die alle zusammen in einer einzelnen Datei, aber unabhängig von den Da-

20

Ein Patricia Trie ist ein spezieller binärer Baum, bei dem die Bitmuster der Schlüssel die Verzweigung der Knoten vorgeben. Zusätzlich wird in jedem Knoten eine Zahl gespeichert, die die zu überspringenden Bits für die Kinderknoten angibt. Auf diese Weise können leere interne Knoten vermieden werden. Das Resultat ist ein gepackter, binärer Baum. Das Wachstum des Baumes ist logarithmisch, weswegen die Gesamtgröße des Baumes anhand der Schlüsselanzahl vorberechnet werden kann.

200

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

ten gespeichert werden. Daten und Indizes werden somit getrennt abgelegt. Auf die Performanz hat diese getrennte Abspeicherung keine nennenswerten Auswirkungen, da das Öffnen und Schließen von Dateien auf aktuellen Betriebssystemen keine zeitkritischen Operationen mehr darstellen. ■

Buffer Manager. Der Buffer Manager ist für die Administration und Steuerung des lokalen DB-Caches verantwortlich. Ziel ist eine Beschleunigung des Datenzugriffs durch die Einlagerung von Speicherseiten in den Cache des mobilen Clients. Speicherseiten können in DB2 Everyplace eine Größe von 512 oder 4096 Byte haben. Welche Größe eine Speicherseite tatsächlich hat, hängt vom verwendeten Betriebsystem und dem Typ des Speichermediums ab, auf dem eine DB2 EveryplaceDatenbank eingesetzt wird.

■

Recovery Manager. Der Recovery Manager ist für das Wiederherstellen eines konsistenten Datenbankzustandes nach einem Datenbank-Crash verantwortlich. Dazu wird ein Schattenspeicherkonzept implementiert. Die Idee des Schattenspeicherkonzeptes [Här01] ist, eine konsistente Momentaufnahme eines Segments (Shadow File) auf einem Externspeicher abzulegen. Für jede von einer Transaktion betroffene Speicherseite werden zwei Kopien nachgeführt. Einerseits eine aktuelle Kopie, die der Schattenseite entspricht und den Zustand nach dem letzten COMMIT repräsentiert. Andererseits eine aktive Kopie, auf der die laufenden Änderungen einer neuen Transaktion durchgeführt werden. Wird eine Transaktion beendet, wird die aktive Kopie zur neuen aktuellen Kopie. Ist die Transaktion nicht erfolgreich, reicht es, die aktive Kopie zu verwerfen und durch die aktuelle Kopie zu ersetzen.

■

File System Interface. Die Schnittstellenkomponente definiert ein abstraktes Dateisystem-API, das eine Abbildung der DB2 Everyplace-Speicheroperationen auf plattformspezifische Speicherfunktionen ermöglicht. Bei dieser Schnittstelle handelt es sich um die einzige plattformabhängige Komponente der DB2 Everyplace-Datenbank-Engine. Die anderen, in höheren Schichten angesiedelten Komponenten sind plattformunabhängig.

Eine DB2 Everyplace-Datenbank besteht für gewöhnlich aus einer Sammlung verschiedener Dateien, die in einem bestimmten Verzeichnis eines Dateisystems abgelegt sind. DB2 Everyplace baut somit auf einem dateibasierten Speicherkonzept auf. Viele mobile Geräte (beispielsweise Palmtops) basieren aber auf einem blockori-

9.2 IBM DB2 Everyplace

Speicherkonzepte

■ ■ ■

201

Tabellentypen

Katalogmanagement

entierten Speicherkonzept. DB2 Everyplace erkennt und adaptiert ein solches Speicherkonzept automatisch. Bei der Speicherung und Bearbeitung relationaler Daten wird durchgängig das gleiche Tabellenformat verwendet. Systemtabellen (System Tables) speichern Informationen des Datenbankkatalogs, Nutzertabellen (User Tables) speichern Anwendungsdaten und Temporärtabellen (Temporary Tables) speichern Zwischenergebnisse, wie sie beispielsweise bei Gruppierungsoperationen vorkommen. Intern besteht eine Tabelle (T) aus einer Datendatei (DSY_T) und einer Indexdatei (DSY_iT). Während die Datendatei für die Speicherung der tatsächlichen Anwendungsdaten verantwortlich ist, werden in der Indexdatei die auf den Spalten einer Tabelle angelegten Indizes abgelegt. Aus Performanzgründen wird für jede Primärschlüsselspalte (oder Primärschlüssel-Spalten) automatisch ein Index generiert. Das verwendete Speicherformat ist geräte- und plattformunabhängig. Dies wird erreicht, in dem intern unter anderem ein unabhängiges Format der Bytezählung verwendet wird. Die Reihenfolge der Bits innerhalb eines Bytes und die Reihenfolge der Bytes spielen keine Rolle. Es ist also egal, ob ein Prozessor Big EndianBytezählung (wie es bei Intels x86-Prozessoren der Fall ist) oder Little Endian-Bytezählung (wie es bei PowerPC-Prozessoren der Fall ist) implementiert. Der Systemkatalog besteht aus den Systemtabellen DB2eSYSUSERS, DB2eSYSTABLES, DB2eSYSCOLUMNS und DB2eSYS-RELS. Während die erste der genannten Tabellen für die Speicherung von Benutzerinformationen zuständig ist, werden die letzten drei genannten Tabellen zur Speicherung von Informationen über existierende Tabellen, Spalten und Beziehungen genutzt (Tabelle DB2eSYSUSERS wurde erstmals mit Version 8.1 von DB2 Everyplace eingeführt). Die Tabellen des Systemkatalogs können wie üblich von jeder Applikation wie reguläre Datentabellen abgefragt, nicht jedoch geändert werden.

9.2.3 Replikation & Synchronisation

SyncServer, SyncClient

202

■ ■ ■

DB2 Everyplace versteht Replikation als Teil der bidirektionaler Synchronisation zwischen dem Datenbankserver im Backend und den mobilen Clients. Im weiteren Verlauf wird deswegen nur noch von Synchronisation, nicht mehr von Replikation gesprochen. Für die Synchronisation bei DB2 Everyplace sind zwei funktional ähnliche Komponenten wichtig (vgl. Abbildung 9.3a): der SyncServer und der SyncClient auf den mobilen Clients. Der SyncServer ist

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

eine klassische Middleware-Komponente, die für die Gesamtkoordination und Administration der Synchronisation zwischen BackendDatenquellen und mobilen Clients zuständig ist. Dazu existieren auf dem SyncServer Spiegeldatenbanken, die logisch gesehen zwischen Backend-Datenbank und mobilen Datenbanken zwischengeschaltet sind. Jede Backend-Datenbank besitzt ein zugehöriges Äquivalent auf dem SyncServer. Dabei ist der SyncServer eine eigene, vom Datenbankserver im Backend vollkommen unabhängige Komponente. Der SyncClient ist die zum SyncServer korrespondierende Komponente auf den mobilen Clients (vgl. Abbildung 9.3b). Der Gesamtprozess des Datenabgleichs zwischen Backend und Client wird, genau wie die Datenkommunikation zwischen SyncServer und SyncClient als Synchronisation bezeichnet. Aufbauend auf der bereits bekannten 3-schichtigen Architektur sind sowohl auf dem mobilen Client (= SyncEngine) als auch auf dem Mid-Tier-Server (= SyncML Synchronizer using WBXML) Synchronisations-Engines implementiert (vgl. Abbildung 9.3b). Optional ansteckbare Adapter sowohl auf den mobilen Clients (z.B. DB2e Adapter, PIM Adapter, File Adapter, usw.), als auch auf dem SyncServer (z.B. DB2 UDB Adapter, JDBC Adapter, Domino Adapter, Exchange Adapter, usw.) ermöglichen die Anbindung unterschiedlichster Synchronisationsquellen im Back- und Frontend. Synchronisation

DB2 Everyplace Datenbank

Abb. 9.3a: Synchronisationsarchitektur

Replikation

Spiegeldatenbank des SyncServers

Komponenten

ServerDatenbank

Bidirektionale Synchronisation

SyncServer

IBM SyncGUI

Mobile Devices Administration Center

DB2e Adapter PIM Adapter

HTTP Sync Engine

File Adapter Adapter API

WAP Bluetooth

SyncEngine API

Transport API

Java Servlet

Mobiler Client

DB2 UDB Adapter SyncML Synchronizer using WBXML

Abb. 9.3b: Synchronisationsengine [nach Fan03]

JDBC Adapter Domino Adapter Exchange Adapter Adapter API

Der SyncServer baut auf einer SyncML-basierten SynchronisationsEngine auf. SyncML (vgl. Kapitel 4.6) entstand als Industrieinitiative verschiedener Unternehmen wie IBM, Nokia, Palm und Motorola. Dabei handelt es sich um eine standardisierte, XML-basierte Aus-

9.2 IBM DB2 Everyplace

SyncML

■ ■ ■

203

Mobile Device Administration Center

WBXML

IBM SyncGUI

zeichnungssprache (Markup Language), die ein herstellerunabhängiges Synchronisations-Framework definiert. Primärziel bei der Entwicklung von SyncML war es, die Interoperabilität bislang zueinander inkompatibler Produkte zu erreichen. Um bei der Synchronisation anfallende Verwaltungsaufgaben zu vereinfachen, verfügt der SyncServer über ein GUI-Werkzeug, das Mobile Device Administration Center (MDAC). Das MDAC ist eine Verwaltungskonsole, ähnlich der des DB2 UDB Control Centers und erlaubt die zentrale und einfache Administration aller mobilen Clients innerhalb einer Synchronisationsumgebung. Die Kommunikation zwischen SyncClient und der Synchronisations-Engine des SyncServers erfolgt unter Verwendung eines einfachen Servlets. Über dieses erfolgt der Versand aller Synchronisationsnachrichten, für die als Übertragungsformat das Wireless Application Protocol (WAP) Binary encoded XML (WBXML) verwendet wird. WBXML ist eine kompakte binäre Repräsentation von XML, mit der die Übertragungsgröße von XML-Dokumenten und der Synchronisationsnachrichten erheblich reduziert werden kann. Weitere optional verwendbare Kommunikationsadapter (in der Abbildung 9.3 z.B. für HTTP, WAP und Bluetooth vorhanden) ermöglichen den drahtlosen Zugriff auf den Mid-Tier-Server. IBM SyncGUI ist das zum MDAC korrespondierende Werkzeug des SyncClients, das die Durchführung einfacher Verwaltungsaufgaben ermöglicht. Dazu gehören die Auswahl eines bestimmten SyncServers (wenn aus Gründen der Skalierbarkeit mehrere SyncServer aufgesetzt sind), die Administration von Benutzernamen und Passwörtern für den Zugriff auf den SyncServer sowie die Spezifikation und Administration der zu synchronisierenden Daten. 9.2.3.1 Bidirektionale Synchronisation Ein Synchronisationsprozess bei DB2 Everyplace kann sowohl unidirektional als auch bidirektional ausgeführt werden. Während bei der unidirektionalen Synchronisation der Abgleich von Daten isoliert vom Client zum Server oder umgekehrt erfolgt, besteht die bidirektionale Synchronisation aus zwei unmittelbar aufeinander folgenden Phasen (entspricht dem Synchronisationsszenario 1 der SyncML): ■

204

■ ■ ■

Client Æ Server (Phase 1). In einem ersten Schritt übergibt ein mobiler Client auf seinem Datenbestand durchgeführte Änderungen dem SyncClient. Anschließend erfolgt die Synchronisation mit den Datenquellen im Backend über den SyncServer und dessen Spiegeldatenbanken. Damit sind die auf einem mobilen

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Client durchgeführten Änderungen im Backend auf einem zentralen Datenbankserver nachvollzogen. ■

Server Æ Client (Phase 2). Im Anschluss an Phase 1 erfolgt ein zweiter Synchronisationsvorgang. Als Ergebnis empfängt ein mobiler Client über seinen SyncClient diejenigen Datenänderungen, die seit dem letzten Synchronisationsvorgang vom Server zum Client auf dem Server stattgefunden haben. Auch die Koordination dieser Phase obliegt dem SyncServer.

Beide Phasen zusammen werden auch als Synchronisationssitzung (Synchronization Session) bezeichnet. Basiseinheit der Synchronisation sind dabei keine Daten, sondern lediglich protokollierten Änderungen auf Daten. Anhand dieser Änderungsprotokolle können durchgeführte Änderungen auf anderen Datenquellen nachgezogen werden. Nachfolgend werden die einzelnen Phasen der bidirektionalen Synchronisation detailliert beschrieben.

Synchronisationssitzung

9.2.3.2 Synchronisation vom Client zum Server Ein Synchronisationsvorgang kann entweder manuell, durch die Anforderung eines Nutzers, oder automatisch, unter Verwendung des IBM SyncEngine API, aus einer Anwendung heraus gestartet werden. Nach dem Start eines Synchronisationsvorganges wird zunächst durch den SyncClient eine Synchronisationsanforderung an den SyncServer übermittelt (vgl. Abbildung 9.4). Eine Synchronisationsanforderung ist eine formale Aufforderung an den SyncServer, den zusammen mit der Synchronisationsnachricht übermittelten Synchronisationsprozess anzustoßen.

Spiegeldatenbank

Quelldatenbank

Source Table 6

Change Data Table 5

Abb. 9.4: Synchronisation vom Client zum Server [DB2e04]

Mirror Table Mobiler Client

4

Administration Control Database

1

3

2 Synchronisationsanforderung

Source System

Staging table

Input Queue

Authentifizierung

Mid-Tier-System

9.2 IBM DB2 Everyplace

■ ■ ■

205

Authentifizierung

Zwischenspeichertabelle

Spiegeltabelle

Wechselrelation

Die Synchronisationsanforderung wird anschließend authentifiziert, wobei die Authentifizierung selbst auf in der Administration Control Database gespeicherten Benutzerinformationen basiert. Authentifizierungen erfolgen anhand der Überprüfung eines vom SyncClient übermittelten Benutzernamens (inklusive eines zugehörigen Passworts). So werden nur diejenigen Daten und Dateien bei dem Synchronisationsvorgang berücksichtigt, für die der Client eine entsprechende Zugriffsberechtigung vorweisen kann. Falls die Authentifizierung erfolgreich war, wird die Synchronisationsanforderung in die Eingabewarteschlange (Input Queue) des SyncServers eingereiht. Der SyncClient des mobilen Clients erhält in jedem Fall durch den SyncServer eine Benachrichtigung über den Status der Synchronisationsanforderung. Die zu synchronisierenden Änderungen, formalisiert in Form eines Änderungsprotokolls durchgeführter Operationen, werden zunächst in einer Zwischenspeichertabelle (Staging Table) auf dem SyncServer abgelegt. Die Verwendung solcher Zwischenspeichertabellen hat den Vorteil, dass auf den Quelltabellen auf dem mobilen Client weiterhin gearbeitet werden kann, ohne dass es aufgrund von Sperrungen, der von der Synchronisation betroffenen Daten, zu Verzögerungen kommt. Anschließend werden die Änderungen von der Zwischenspeichertabelle auf den betroffenen Spiegeltabellen (Mirror Tables) der entsprechenden Spiegeldatenbank ausgeführt. Die Spiegeltabellen repräsentieren aus der Sicht des Clients einen dem Datenbankserver im Backend vorgelagerten, aber zum originalen Datenbankserver identischen Datenbankzustand. An dieser Stelle werden auch alle auftretenden Synchronisationskonflikte aufgelöst. In einem speziellen Änderungsprotokoll werden alle eingebrachten und erfolgreich durchgeführten Veränderungen auf der Spiegeldatenbank festgehalten. Dieses Änderungsprotokoll wird dann in einer Wechselrelation (Change Data Table) zwischengespeichert und dann auf den Quelltabellen nachvollzogen. 9.2.3.3 Synchronisation vom Server zum Client An einen Synchronisationsvorgang vom Client zum Server schließt sich für gewöhnlich ein Synchronisationsvorgang vom Server zum Client an. Dies wird als 2-Wege-Synchronisation bezeichnet. Ausgangspunkt ist wiederum eine genaue Protokollierung von auf den Serverdatenbanktabellen durchgeführten Änderungen. Diese Informationen werden bei einem Synchronisationsvorgang zunächst in eine Wechselrelation (Change Data Table) übertragen. Danach

206

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

werden die isolierten Änderungen auf den relevanten Spiegeltabellen (Mirror Table) der Spiegeldatenbank des SyncServers nachgezogen. Die an der Spiegeltabelle erfolgreich vorgenommenen Änderungen werden in einer Synchronisationsantwortnachricht (Synchronization Reply) gekapselt und in die Ausgabewarteschlange (Output Queue) des SyncServers eingereiht. Dabei berücksichtigt der SyncServer allerdings nur diejenigen Änderungen, für die ein mobiler Client Zugriffsrechte besitzt. Anschließend muss ein mobiler Client seine Synchronisationsantwortnachrichten nur noch aus der Ausgabewarteschlange abrufen und auf dem eigenen Datenbestand nachführen. Dabei kann es zu keinen Konflikten mehr kommen, da die Konfliktbehandlung bereits auf dem SyncServer durchgeführt wurde und nur erfolgreich durchzuführende Änderungen in der Synchronisationsantwortnachricht gekapselt sind. Abb. 9.5: Synchronisation vom Server zum Client [DB2e04]

Da bei der Protokollierung der Speicherplatzmangel mobiler Clients berücksichtigt werden muss, ist anzunehmen, dass kein speicherplatzintensives physisches Logging, sondern logisches Logging implementiert wird, das ausschließlich beobachtete Änderungen, nicht aber ganze Speicherseiten protokolliert.

Logging

9.2.3.4 Konflikte Konflikte bei der Synchronisation treten auf den Spiegeltabellen stets dann auf, wenn auf verschiedenen mobilen Clients gleichzeitig sich widersprechende Änderungen auf den gleichen Daten vorgenommen werden. Um solche Konflikte erkennen und auflösen zu können, implementiert DB2 Everyplace ein Versionskontrollsystem, das auf der Verwendung von Versionsnummern basiert. Für jeden Tabelleneintrag verwaltet der SyncServer eine Versionsnummer in einer speziell dafür vorgesehenen Datei. Auch der Client verwaltet für alle Tabelleneinträge eine solche Versionsnummer.

9.2 IBM DB2 Everyplace

■ ■ ■

207

9.2.4 Anfragesprachen SQL-Standards

Um Anfragen an die lokal gespeicherten Datenbanktabellen stellen zu können, unterstützt DB2 Everyplace eine Untermenge des SQLStandards. Klassische relationale Datenbanksysteme implementieren heute fast alle Features des SQL2-Standards21 (Full SQL). Hinzu kommen wichtige Funktionen und Konzepte, die erstmals mit dem SQL3-Standard22 eingeführt wurden und die bestehende relationale Systeme um objekt-relationale Funktionalität erweitern. Dazu kommen diverse proprietäre Erweiterungen, die vom Datenbankhersteller zusätzlich in seine eigenen Systeme integriert wurden. DB2 Everyplace muss jedoch – aufgrund des Einsatzes auf mobilen Geräten – bei der Anfrageausführung mit wesentlich weniger Systemressourcen auskommen, als dies bei hochskalierenden Datenbanksystemen der Fall ist.

SQL

Das SELECT-Statement als Basisoperation aller Anfragen unterstützt bei DB2 Everyplace das folgende Format: SELECT FROM WHERE GROUP BY ORDER BY LIMIT

... ... ... ... ... ...

Anfragen können sich auf eine einzige Tabelle oder mehrere Tabellen beziehen (der JOIN-Operator steht also zur Verfügung). Ergebnisse können auf- oder absteigend sortiert werden. Die Standardaggregatfunktionen MAX, MIN, SUM, COUNT und AVG werden ebenfalls unterstützt. Weitergehende, komplexere Konstrukte, wie Rekursion, Stored Procedures, Trigger, Views, nutzerdefinierte Funktionen und objektrelationale Konzepte stehen dagegen nicht zur Verfügung. 21 Dieser Standard wird auch als SQL-92 bezeichnet, da er 1992 als ISO-Standard 9075-1992 verabschiedet wurde. 1993 erfuhr SQL-92 mit der DIN-Norm 66315 eine Erweiterung, mit der die drei Unterstützungslevel Entry SQL, Intermediate SQL und Full SQL eingeführt wurden. 22 Dieser Standard wird auch als SQL-99 bezeichnet und ist der aktuell gültige SQLStandard. Grundlegende Neuerungen dieses Standards werden in Teilstandards gekapselt. Entscheidend ist jedoch die Einführung von Konstrukten, die ursprünglich aus dem Bereich der Objektorientierung stammen und die objektrelationale Konzepte besser unterstützen sollen.

208

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Stellen Hochleistungs-Datenbanksysteme eine Vielzahl an verschiedenen Datentypen bereit, so werden von DB2 Everyplace nur die folgenden Datentypen angeboten: ■

Numerische Datentypen: INTEGER, SMALLINT, DECIMAL

■

String-Datentypen: CHAR, VARCHAR, BLOB

■

Datums- und Zeitdatentypen: DATE, TIME, TIMESTAMP

Indexe auf einer oder mehreren Spalten einer bestehenden Tabelle können dynamisch angelegt und wieder gelöscht werden. Das gleiche gilt für neue Tabellen, die ebenfalls dynamisch angelegt und wieder gelöscht werden können. Schon bei der Definition von neuen Tabellenspalten kann man diesen beliebige Werte zuweisen. Nullwerte sind erlaubt. Primär- und Fremdschlüsselbeziehungen sowie Konsistenzbedingungen können spezifiziert werden. 9.2.4.1 Query by Example (QbE) Auf der Palm-Plattform kann statt der deskriptiven Anfragesprache SQL auch die graphische Anfragesprache Query-by-Example (QbE) verwendet werden, um auf lokal gespeicherte DB2 EveryplaceDatenbanktabellen zuzugreifen. QbE erlaubt eine besonders einfache Formulierung von Anfragen. Eine entsprechende GUI-Anwendung dazu steht bereit. Mit QbE können Tabellen angezeigt und aktualisiert, Daten gefiltert und sortiert werden. Auch auf einen Befehlszeilenprozessor kann zurückgegriffen werden. QbE arbeitet jedoch ausschließlich auf bereits existierenden Tabellen. Im Zweifelsfall müssen neue Tabellen zunächst mit Hilfe eines Befehlszeilenprozessors angelegt werden.

Datentypen

Indexe

Graphische Anfragesprache

9.2.5 Programmierung Alle wichtigen Werkzeuge für die Anwendungsentwicklung, Beispiele und Produktdokumentationen sind Bestandteil des DB2 Everyplace Software Development Kit (SDK). Wichtigste Komponente des SDKs ist der bereits mehrfach erwähnte Mobile Application Builder (MAB), eine vollständig integrierte Rapid Application Development-Entwicklungsumgebung. Mit dem MAB können einfache mobile Datenbankanwendungen in kürzester Zeit erstellt werden, im Extremfall sogar ohne eine ma-

9.2 IBM DB2 Everyplace

Software Development Kit (SDK)

■ ■ ■

209

nuelle Programmierung von Code. Möglich wird dies durch eine Bibliothek vordefinierter Anwendungskomponenten, die mit einigen wenigen Mausklicks sehr schnell in eine Applikation eingebunden und konfiguriert werden können. Das SDK beinhaltet alle notwendigen Werkzeuge, um DB2 Everyplace-basierte Anwendungen in C/C++, Java oder Visual Basic zu erstellen.

Programmierwerkzeuge

9.2.5.1 Anwendungsentwicklung mit C/C++ Die Programmiersprachen C und C++ sind die am häufigsten eingesetzten Programmiersprachen bei der Entwicklung mobiler Anwendungen – auch wenn Java mit der Java 2 Micro Edition (J2ME) stetig an Boden gewinnt. Um mit C/C++ zu programmieren, werden zusätzlich zum MAB einige weitere Tools benötigt (vgl. auch Kapitel 10.3). Speziell für die Windows Mobile 2003-Plattform werden die Microsoft Embedded Visual Tools 3.0 oder das Visual Studio .NET mit dem zugehörigen .NET Compact Framework benötigt. Für die Erstellung einer C/C++-Anwendung können die folgenden Schritte dem Entwickler als grober Leitfaden dienen:

Leitfaden zur Anwendungsentwicklung

210

■ ■ ■

■

Installation von DB2 Everyplace auf dem Entwicklungssystem.

■

Konzeption der Anwendung und Bestimmung der Anforderungen an die Datenhaltung (Data Requirements).

■

Bestimmung, welche Daten der Nutzer sehen darf und welche Möglichkeiten er haben soll, Daten einzufügen, zu aktualisieren oder zu löschen.

■

Implementierung der C/C++-Anwendung.

■

Anbindung an DB2 Everyplace mit Hilfe der DB2 Everyplace CLI/ODBC-Schnittstelle und der zugehörigen Funktionen. Diese Programmierschnittstelle stellt die Kommunikationsbrücke dar, mit der eine Anwendung an eine Datenbank angekoppelt wird. Dabei handelt es sich um eine Untermenge der DB2 CLI.

■

Kompilierung und Linken der Anwendung mit den notwendigen DB2 Everyplace Header-Dateien und den plattformspezifischen Bibliotheken. Die Header-Dateien enthalten Definitionen von Konstanten, Datentypen und C/C++-Funktionen, die zusammen mit DB2 Everyplace eingesetzt werden können.

■

Test der Anwendung auf einem Emulator/Simulator.

■

Installation der Anwendung auf dem mobilen Zielsystem.

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Für die Programmierung adäquater Synchronisationsmechanismen, kann die SyncClient API for C/C++ verwendet werden, über die direkt auf einen zwischengeschalteten Synchronisationsserver zugegriffen werden kann. 9.2.5.2 Anwendungsentwicklung mit Java Wird eine Anwendung mit der Programmiersprache Java erstellt, kann auf DB2 Everyplace-Datenbanken über die bekannte Schnittstellenspezifikation JDBC zugegriffen werden. Darüber hinaus muss eine Java Virtual Machine (JVM) installiert sein, um Anwendungen auch ausführen zu können. Die Anwendungsentwicklung erfolgt ähnlich wie oben bereits für die Programmierung mit C/C++ beschrieben. Ein Unterschied besteht jedoch darin, dass keine Header-Dateien und Plattform-Bibliotheken eingebunden, sondern Java-Packages und Klassen (java.sql.*) importiert werden müssen. Für den Aufbau einer Datenbankverbindung wird ein JDBC-Treiber benötigt (com.ibm.db2e.jdbc.app.DB2eDriver). Bei der Kommunikation zwischen Anwendung und Datenbank mit JDBC sind dann jedoch keine weiteren Besonderheiten zu beachten. Gerade durch den Rückgriff auf eine plattformunabhängige Laufzeitumgebung (wie die JVM) wird ein hohes Maß an Flexibilität bei der Anwendungsentwicklung erreicht. Mittlerweile existiert eine ganze Reihe an virtuellen Maschinen für mobile Geräte (KVM, J9, JeodeVM, KadaVM, Wabasoft, usw.), wobei vor allem der KVM und der darauf aufbauenden Java 2 Micro Edition (J2ME) eine immer wichtigere Rolle zukommt. Für die Kodierung können verschiedene Entwicklungsumgebungen, vom einfachen Texteditor bis hin zur ausgereiften Entwicklungsumgebungen wie dem Sun ONE Studio (Mobile Edition) eingesetzt werden. Speziell auf die Entwicklung mobiler Anwendungen angepasst ist die vergleichsweise teure Entwicklungsumgebung CodeWarrior von Metrowerks. Wie für die Programmierung mit C/C++ hat IBM auch für die Entwicklung in Java eine eigene Programmierschnittstelle für die Implementierung von Synchronisationsmechanismen definiert. Mit Hilfe des SyncClient API for Java können beliebige Synchronisationsmechanismen realisiert werden. Diese Programmierschnittstelle gliedert sich dazu in zwei unterschiedliche Sub-APIs. Einerseits kann über Java Native Interfaces eine so genannte DB2 Everyplace Native Synchronization implementiert werden, auf der anderen Seite kann über die alternative DB2 Everyplace MIDP Synchronization eine Synchronisation in Java realisiert werden.

9.2 IBM DB2 Everyplace

Synchronisation mit C/C++

Java

Programmierwerkzeuge

Synchronisation mit Java

■ ■ ■

211

9.2.5.3 Anwendungsentwicklung mit Visual Basic Um DB2 Everyplace-basierte Anwendungen mit Visual Basic zu erstellen, muss das AppForge MobileVB-Plug-In verwendet werden. Dieses Plug-In erlaubt den Einsatz von Visual Basic bei der Programmierung für die Palm-, die Windows Mobile 2003- und die Symbian-Plattform. Ähnlich wie bei der Entwicklung mit C/C++ wird über ein Call Level Interface auf eine Datenbank zugegriffen.

9.2.6 Zusammenfassung IBM hat mit der DB2 Everyplace-Produktpalette eine vollständige Lösung für die Integration mobiler Datenbankanwendungen in existierende IT-Infrastrukturen im Programm. Basis ist das relationale Small-Footprint-Datenbanksystem DB2 Everyplace, welches auf den mobilen Clients installiert wird. Eine Middleware-Komponente, der SyncServer, ist für die Koordination der Synchronisation zwischen mobilen Clients und Backend-Datenquellen zuständig. Auf den mobilen Clients übernimmt der SyncClient die Koordination der Synchronisationssitzungen. Eine DB2 Everyplace-basierte Lösung kann dabei äußert flexibel eingesetzt werden. So erlaubt der SyncServer die einfache Anbindung relationaler und objektrelationaler Datenbanksysteme über die JDBC-Schnittstelle. Beliebige andere Datenquellen können mit Hilfe spezieller, frei programmierbarer Adapter ebenfalls angebunden werden. Wie üblich bei relationalen Datenbanken kann auf vorhandenen Daten mit der deskriptiven Anfragesprache SQL gearbeitet werden. Fast alle wichtigen Syntaxelemente von SQL werden unterstützt. Als Besonderheit ist die Abfragesprache Query By Example (QbE) zu nennen, die eine graphische Anfrageformulierung erlaubt. Die einzelnen Produktkomponenten sind sehr gut aufeinander abgestimmt und ergänzen sich zu einer effizient einsetzbaren mobilen Datenbanklösung. So werden für die einfache Administration des Systems übersichtliche und intuitiv bedienbare GUI-Tools angeboten, und mit der leistungsstarken Entwicklungsumgebung MAB wird eine schnelle Erstellung mobiler Datenbankanwendungen möglich. Verhältnismäßig kompliziert und umständlich ist jedoch die Konfiguration des MAB (insbesondere die Integration der erforderlichen Zusatztools). Das mobile Datenbanksystem DB2 Everyplace und der zugehörige Mobile Application Builder werden auch für die Implementierung einer mobilen Datenbankapplikation in Kapitel 10 verwendet.

212

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

9.3 Oracle Database 10g Lite Das Unternehmen Oracle, dessen Datenbankprodukte (in der aktuellen Version 10g) zu den weltweit meistverkauften objektrelationalen Datenbanksystemen gehören, bietet ebenfalls Datenbanktechnologie für den Aufbau mobiler Infrastrukturen an. Wie DB2 Everyplace basiert auch die aktuelle Version Oracle Database 10g Lite auf einer ganzen Reihe von sich ergänzenden Komponenten. Kern der Oracle 10g Lite-Produktsuite ist das mobile leichtgewichtige Datenbanksystem Oracle Lite (Version 5.0, April 2004), das verschiedene Zielplattformen unterstützt, darunter die Win32Plattformen (Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP), Pocket PC, Palm-OS und Symbian. Je nach Installationsumfang werden zwischen 50 kB und 1 MB Speicherplatz benötigt. Um mobilen Clients einen universellen drahtlosen Zugriff auf Datenbankserver im Backend zu ermöglichen, kann der Oracle 10g Application Server (Wireless) eingesetzt werden. Dieser bildet bezogen auf die in Kapitel 1 beschriebene Referenzarchitektur eine universelle, von beliebigen Clients mit beliebigen Drahtlostechniken ansprechbare Basisstation. Da auch in diesem Fall die Unterstützung des Disconnected Mode eine entscheidende Forderung ist, bietet auch Oracle Synchronisationsmechanismen an, um Daten zwischen einer mobilen Datenbank und einem Datenbankserver abzugleichen. Für die Entwicklung mobiler Datenbankanwendungen können verschiedene Entwicklungsumgebungen (zum Beispiel der Oracle JDeveloper) verwendet werden. Eine spezielle Entwicklungsumgebung, wie sie DB2 Everyplace mit dem Mobile Application Builder vorweisen kann, existiert nur für die Entwicklung webbasierter Anwendungen. Solche webbasierte Anwendungen werden in OnlineSzenarien (vgl. Kapitel 1.3) eingesetzt und werden auf dem Oracle 10g Application Server (Wireless) gehostet. Sollen tatsächlich webbasierter Anwendungen eingesetzt werden, muss auf den mobilen Clients ein Micro Web Application Server installiert sein.

Plattformunterstützung

Anwendungsentwicklung

9.3.1 Komponenten Alle Komponenten der Infrastruktur einer mobilen Datenverarbeitung werden bei Oracle zusammen als Mobile Server Environment bezeichnet. Definiert wird eine 3-schichtige Architektur (3-TierArchitecture), die aus den mobilen Clients, einer MiddlewareKomponente und einem (oder mehreren) klassischen Datenbankser-

9.3 Oracle Database 10g Lite

Mobile Server Environment

■ ■ ■

213

ver(n) im Backend bestehen (vgl. Abbildung 9.6). Im Backend können als Datenbankserver ausschließlich Oracle-Installationen eingesetzt werden. Die einzelnen Komponenten sind: Mobiler Client

■

Oracle Lite Database. Wichtigste Komponente des mobilen Client ist das leichtgewichtige, relationale Datenbanksystem Oracle Lite. Dieses wird auf mobilen Clients installiert.

Abb. 9.6: Mobile Server Environment Oracle Lite Datenbank

Variante 1: Stand-Alone Server

Middleware

214

■ ■ ■

■

Mobile Server

Oracle 10g DB-Server

Variante 2: Modul eines Servers

Mobile-Server. Der Mobile Server ist eine MiddlewareKomponente, die in ihrer Funktion weitgehend dem SyncServer von DB2 Everyplace entspricht. Sie implementiert also einen Synchronisationsserver. Als Modul konzipiert, das als unabhängige Stand-Alone-Komponente oder als Teilmodul verschiedener Web-/Applikationsserver eingesetzt werden kann, bearbeitet und koordiniert der Mobile Server alle eingehenden Synchronisationsanforderungen mobiler Clients. Beispiele von Web- bzw. Applikationsservern, die den Mobile Server als eigenes Modul integrieren können, sind der Oracle 10g Application Server (Wireless), der Oracle HTTP Server oder der Opensource Webserver Apache. Zur Verwaltung sämtlicher Aufgaben im Zusammenhang mit der Synchronisation und zur Administration aller betreuten mobilen Clients samt Anwendungen wird ein browserbasiertes GUI-Werkzeug, das Mobile Server Control Center (MSCC), zur Verfügung gestellt. Für die Automatisierung von Administrationsaufgaben können auf Windows-Systemen einfache Skripte über INI-Dateien definiert werden, die über den Windows Scripting Host (WSH) ausgeführt werden.

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

■

Datenbankserver. Der Datenbankserver im Backend speichert sowohl die gewöhnlichen Anwendungsdaten als auch das Mobile Server Repository (MSR). Dieses enthält die Daten und Oracle-Anwendungen aller mobilen Clients. Nur Daten und Anwendungen, die im Mobile Server Repository gespeichert sind, können auf mobile Clients repliziert werden.

Backend

Nachdem die wichtigsten Komponenten der mobilen Infrastruktur vorgestellt sind, soll nun genauer auf die Architektur und die Konzepte der mobilen Datenbank-Engine eingegangen werden.

9.3.2 Architektur der clientseitigen Datenbank-Engine Oracle Lite ist ein objektrelationales Small-Footprint-Datenbanksystem, dessen Installation minimal 50 kB und maximal 1 MB Speicherplatz benötigt. Der modulare Aufbau der Datenbank-Engine erlaubt es, nur die Bestandteile zu installieren und auszuführen, die von einem Nutzer bzw. einer Anwendung auch tatsächlich benötigt werden. Insbesondere die Integration komplexer Indexstrukturen (einzig B-Bäume werden unterstützt) und der Anwendungsschnittstellen ODBC und JDBC benötigt zusätzlichen Speicherplatz. Durch die individuelle Auswahl und Konfiguration der zu installierenden Komponenten lässt sich der tatsächlich benötigte Speicherplatz leicht an unterschiedliche Anwendungsszenarien bzw. in ihrer Leistung divergierende mobile Geräte anpassen. Die Datenbank-Engine kann Datenmengen von bis zu 2 GB verwalten. Oracle Lite ist als Objektkernel realisiert, auf dem eine zusätzliche SQL-Schicht zur Ausführung von SQL-Anfragen aufgesetzt ist (vgl. Abbildung 9.7). Der Objektkernel implementiert die tatsächliche Datenverwaltungsfunktionalität. Auf der SQL-Schicht setzen zusätzlich die klassischen Anwendungsschnittstellen für den Datenzugriff aus Anwendungen heraus auf: ODBC und JDBC. Um direkt auf die Funktionen des Kernels zuzugreifen, wird ein proprietäres Object Kernel API (OKAPI) bereitgestellt, das als Call Level Interface (CLI) ausschließlich von C/C++-Anwendungen genutzt werden kann. Die Verwendung dieser Programmierschnittstelle gestattet den performantesten Zugriff, der möglich ist, in dem direkt auf die Strukturen und Operationen des Datenbanksystems zugegriffen wird. C/C++-Anwendungen können alternativ auch über ODBC auf den Objektkernel zugreifen. Aus Java-Anwendungen heraus wird JDBC für den Zugriff auf den Objektkernel benutzt.

9.3 Oracle Database 10g Lite

Speicherplatz

Objekt-Kernel

■ ■ ■

215

Transaktionen

Abb. 9.7: Anwendungsschnittstellen

Das Transaktionsmanagement obliegt einem Transaktionsmanager, der für alle auf einer mobilen Einheit durchgeführten Transaktionen eine Force-Strategie durchsetzt. Bei einer solchen Strategie müssen alle von einer Transaktion geänderten Blöcke (Seiten) zusammen mit dem COMMIT der Transaktion physisch in die Datenbank geschrieben werden. Ein Redo-Log ist nicht notwendig, da mit dem COMMIT die Auswirkungen einer Transaktion sofort dauerhaft in der Datenbank geschrieben sind. Dagegen muss der Transaktionsmanager für jede noch nicht mit COMMIT beendete, also noch aktive Transaktion ein Undo-Logging realisieren. Um Transaktionen im Falle ihres vorzeitigen Abbruchs zurückzusetzen, müssen alle durchgeführten Operationen genau protokolliert werden. Alle von Oracle Lite ausgeführten Transaktionen besitzen dabei stets alle ACID-Eigenschaften. Java

C/C++

JDBC ODBC SQL-Schicht Oracle Lite Objektkernel

Backup

Oracle Lite speichert jede Datenbank vollständig in einer einzigen Datei. Dies erlaubt ein schnelles Backup und Wiederherstellen einer Datenbank. Durch das Sichern der Datenbank-Datei kann eine Datenbank gesichert und durch das Wiedereinspielen derselben Datei auch wiederhergestellt werden. Da aber eine auf diese Weise eingespielte Datenbank-Datei einen inkonsistenten Datenbankzustand repräsentieren kann, muss nach dem Wiederherstellungsprozess immer noch ein ROLLBACK der zum Zeitpunkt der Sicherung noch offenen Transaktionen erfolgen.

9.3.3 Replikation & Synchronisation Replikation

216

■ ■ ■

Replikation und Synchronisation basieren bei Oracle Lite auf der Verwendung von Snapshots. Snapshots sind materialisierte Sichten nicht-lokaler Datenbestände, also von Daten des Datenbankservers, auf den Clients (vgl. Kapitel 4.5.2).

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Snapshots bei Oracle können verschiedene Granularitäten haben, von einzelnen Tabellenzeilen (also Tupeln), bis hin zu kompletten Tabellen. Replikationsquelle kann ausschließlich eine OracleInstallation im Backend sein. Mobile Clients sind stets Replikationssenken (und können somit keine Replikationsquellen darstellen), können aber auf ihnen durchgeführte Änderungen durchaus mit dem Backend synchronisieren. Replikationsserver werden als MasterSites, die mobilen Clients als Snapshot-Sites bezeichnet. Die Kommunikation zwischen einer Re-plikationsquelle und einer Replikationssenke kann verbindungsbasierter (synchron) oder dateibasiert (asynchron) erfolgen. Die Synchronisation bezeichnet bei Oracle den Abgleich von Snapshots. Dateibasierte Replikation beruht auf der Verwendung von Dateien, die in einem gemeinsam genutzten Speicherbereich abgelegt sind. Der Dateitransfer kann auf drei verschiedene Arten erfolgen: ■

Manuell beispielsweise unter Verwendung des File Transfer Protocols (FTP),

■

über ein spezielles Modul des Mobile Servers, dem Oracle Mobile Agent (OMA), oder

■

über eine herkömmliche HTTP-Verbindung zusammen mit einem zwischengeschalteten Oracle Web Application Server.

In der dritten Variante ist der Applikationsserver für die automatische, asynchrone Weitergabe aller Replikate an die Clients zuständig (dies entspricht dem Standardszenario). Die Replikation selbst basiert auf einem Publish&SubscribeModell. Dabei werden auf dem Synchronisationsserver Publikationen erzeugt, die selbst wiederum aus einer Menge von Publikationsartikeln bestehen. Einzelne Publikationsartikel werden durch SQLAnweisungen definiert und dann zu Publikationen zusammengefasst. Die Zuordnung von Publikationen zu bestimmten mobilen Clients erfolgt anhand von Subskriptionen. Bei Snapshots unterscheidet Oracle zwischen einfachen und komplexen Snapshots (vgl. Kapitel 4.5.2). Zwischen der Originaltabelle der Replikationsquelle und jedem generierten und auf einen mobilen Client replizierten Snapshot muss eine bijektive Abbildung existieren (einfache Sichten). Nur so können die auf einem Snapshot durchgeführten Änderungen bei der späteren Synchronisation wieder korrekt auf den Originaldaten nachgezogen werden. Für komplexe Snapshots ist keine spätere Reintegration auf der Replikationsquelle möglich, weswegen auf sie auf den mobilen Clients auch nur lesend zugegriffen werden darf.

9.3 Oracle Database 10g Lite

SnapshotGrundlagen

Publish & Subscribe

Einfache vs. Komplexe Snapshots

■ ■ ■

217

Abgleich von Snapshots

9.3.3.1 Synchronisation Oracle definiert die Synchronisation zwischen Datenbankserver und Clients als den Abgleich von Snapshots. Synchronisationsvorgänge können automatisch, durch einen serverseitigen Datenbankprozess, aber auch durch eine individuelle Initialisierung mit Hilfe spezieller Java Replication Classes bzw. Replication OLE Controls initialisiert werden. Clientseitig ist dies ebenfalls möglich. Der Abgleich von Snapshots kann allerdings nur mit einfachen Snapshots erfolgen, denn auf komplexe Snapshots darf ja nur lesend zugegriffen werden (vgl. Kapitel 4.5.2). Dies bedeutet implizit auch, dass für diese keine Synchronisation notwendig ist, da es auch zu keinen Änderungsoperationen kommt. Im Folgenden werden drei Synchronisationsverfahren für einfache Snapshots vorgestellt: ■

Full Refresh. Im Zuge eines Full Refresh werden alle Tupel, die im Ergebnis einer Snapshot-Anfrage auftauchen, von der Replikationsquelle auf die dafür vorgesehenen Replikationssenken übertragen. Zur Erinnerung: die Replikationssenken können über die angelegten Subscriptions eindeutig ermittelt werden. Alle bereits existierenden Tupel auf den Clients werden dabei gelöscht, so dass beim Full Refresh immer in eine völlig leere Tabelle geschrieben wird.

■

Fast Refresh. Beim Fast Refresh werden dagegen ausschließlich die protokollierten Änderungen auf den Originaltabellen für eine effizientere Aktualisierung der Snapshots verwendet. Jeder Tabelle der Replikationsquelle ist eine eigene Protokoll-Tabelle zugeordnet, die auch als Snapshot Transaction Log bezeichnet wird. Jede Protokoll-Tabelle speichert Informationen zu genau denjenigen Transaktionen, die auf die jeweils überwachte Tabelle ändernd zugreift. Dabei wird für jede Änderungstransaktion ein Zeitstempel festgehalten. Für Snapshots, die anhand ihres Primärschlüssels eine Partitionierung einer Tabelle vornehmen, wird zusätzlich der Primärschlüssel des geänderten Tupels festgehalten. Der Begriff Fast Refresh kann jedoch zu Missverständnissen führen. Zwar wird der Eindruck erweckt, die schnelle Aktualisierung sei die in jedem Fall effizientere Synchronisationsmethode, jedoch ist dies nicht immer richtig. Gerade bei kleinen Tabellen, auf denen viele Änderungstransaktionen ausgeführt werden, kann die Übertragung aller protokollierten Änderungen wesentlich aufwendiger sein, als ein alternatives Full Refresh.

218

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

■

Force Refresh. Die Methode Force Refresh implementiert eine Mischung der beiden zuerst genannten Techniken Full Refresh und Fast Refresh. Dabei wird zunächst ein Fast Refresh versucht. Ist dies nicht möglich, beispielsweise aufgrund fehlerhafter Protokolldateien, wird ein Full Refresh durchgeführt.

Die vorgestellten Techniken zur Aktualisierung von Snapshots stellen für sich alleine genommen noch keinen Synchronisationsprozess dar. Sie sind lediglich Methoden, um auf Originaldaten durchgeführte Änderungen auf Snapshots der mobilen Clients zu übertragen. Im Zuge einer Synchronisation müssen aber auch auf den Snapshots der Clients durchgeführte Änderungen auf den Originaldaten nachgezogen werden. Erst wenn auch der umgekehrte Weg beschritten wurde, kann wirklich vom Abgleich von Snapshots bzw. Synchronisation gesprochen werden. Im Folgenden wird deswegen der komplette Ablauf eines Synchronisationsprozesses beschrieben. Mit der Initialisierung eines Synchronisationsvorgangs wird eine Refresh Group erstellt. Diese fasst alle Snapshots zusammen, die an dem geplanten Synchronisationsprozess teilnehmen sollen. Einer solchen Refresh Group können Snapshots beliebig hinzugefügt oder entnommen werden. Nach der Definition und Erzeugung einer Refresh Group beginnt der eigentliche Synchronisationsvorgang. Dieser gliedert sich in zwei Phasen, die auch als Reintegration und Rückübertragung (vgl. Kapitel 4) bezeichnet werden: ■

In einem ersten Schritt werden alle Änderungen einfacher Snapshots, die seit dem letzten Synchronisationsvorgang stattgefunden haben, an den Datenbankserver übertragen (Reintegration). Der Datenbankserver ist in diesem Fall die Replikationsquelle. Dort wird versucht, die Änderungstransaktionen der mobilen Clients in der identischen Reihenfolge auf den Originaldaten auszuführen. Dabei auftretende Konflikte werden durch den Mobile Server erkannt und behoben werden.

■

Wurde der erste Schritt erfolgreich beendet, werden in einem zweiten, sich anschließenden Schritt alle zwischenzeitlich auf den Originaltabellen durchgeführten Änderungstransaktionen auf die mobilen Clients übertragen (Rückübertragung).

Synchronisationsprozesse

Refresh Groups

9.3.3.2 Konfliktbehandlung Bei der Einbringung von auf Snapshots durchgeführten Änderungstransaktionen kann es zu Konflikten kommen. Ein Konflikt tritt beispielsweise dann auf, wenn eine Änderungstransaktion ein Tupel

9.3 Oracle Database 10g Lite

■ ■ ■

219

Spaltengruppen

Löschoperationen

220

■ ■ ■

geändert hat, das auch gleichzeitig auf der Replikationsquelle geändert wurde. Konflikte werden stets auf dem Mobile Server erkannt und aufgelöst. Die Wahrscheinlichkeit für auftretende Konflikte wird in erheblichem Maße durch die Konzeption der gesamten Replikationsumgebung, insbesondere durch die Wahl der Methode der Snapshot-Erzeugung bestimmt. Dabei kann zwischen UPDATE-, DELETE- und Eindeutigkeitskonflikten unterschieden werden. Zusätzliche Konflikte auf Backend-Server und mobilen Clients entstehen durch parallele Änderungen auf einer Menge an Clients. Jeder Client kann dabei seine eigenen Views (= Snapshots) auf die Gesamtsicht haben. In Situationen, in denen kaum oder gar keine Überschneidungen zwischen verschiedenen Snapshots existieren, können zumindest diese Konflikte vermieden werden. Besonders vorteilhaft ist es deshalb, stets darauf zu achten, möglichst disjunkte Snapshots auf mobile Clients zu replizieren. Mit dem Anstieg von SnapshotÜberschneidungen steigt aber auch die Wahrscheinlichkeit von Konflikten stark an. Insgesamt werden in Oracle zwei Möglichkeiten angeboten, erkannte Konflikte aufzulösen. Einerseits kann eine manuelle Auflösung eines Konflikts versucht werden, andererseits – und dies entspricht der üblichen Vorgehensweise – unterstützt Oracle eine automatische Konfliktauflösung mit vorgegebenen Auflösungsroutinen. UPDATE-Konflikte können beispielsweise aufgelöst werden, indem Informationen über spezielle Spaltengruppen verwendet werden. Die dazu notwendigen Informationen werden automatisch angelegt und gepflegt. Das Prinzip dahinter ist folgendes: Tabellen werden in (disjunkte) Spaltengruppen (Column Groups) zerlegt. Diesen Vorgang bezeichnet man auch als Partitionierung. Eine Spaltengruppe fasst semantisch zusammengehörige Attribute zusammen. Jeder einzelnen Spaltengruppe kann dann eine angepasste Konfliktauflösungsroutine zugewiesen werden. Im Falle eines UPDATE-Konflikts bestehen beispielsweise die Möglichkeiten, das Tupel der Originaltabelle in jedem Fall beizubehalten (Discard Value), das Original-Tupel durch das geänderte Snapshot-Tupel zu ersetzen (Overwrite Value) oder eine Entscheidung aufgrund des Änderungszeitpunktes zu treffen (Earliest Timestamp/Latest Timestamp). Im letzten Fall werden Zeitstempel für die Konfliktauflösung verwendet. Andere Verfahren nutzen die Definition minimaler und maximaler Attributwerte oder führen komplexere Prioritätssysteme ein. Für DELETE-Operationen werden dagegen keine automatischen Konfliktbehandlungsmethoden angeboten, das heisst alle Konfliktbehandlungsmethoden müssen in diesem Fall manuell definiert wer-

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

den. Dazu müssen nutzerdefinierte Funktionen, formuliert mit der Oracle-Skriptsprache PL/SQL, implementiert werden. Um mögliche Konflikte bereits im Vorfeld eines Synchronisationsvorgangs auszuschließen, besteht neben einer sinnvollen Konzeption der gesamten Replikationsumgebung die Möglichkeit, auf den Originaldaten definierte Integritätsregeln mit den Snapshots auf die mobilen Clients zu übertragen. Auf der mobilen Datenbank kann dann eine Überprüfung dieser Regeln erfolgen, bevor ein Synchronisationsvorgang durch einen mobilen Client initialisiert wird. Gewisse konzeptionelle Ähnlichkeiten zu den bereits vorgestellten Promotion-Transaktionen (vgl. Abschnitt 5.4.5) sind offensichtlich, das heisst Änderungsoperationen, die eine vorhandene Integritätsregel verletzten, werden sofort zurückgewiesen. Integritätsregeln können auf verschiedene Weise definiert werden. Neben Spaltenund Tabellenbedingungen können auch Trigger deklariert werden, die entsprechende Regeln implementieren. Während die Spaltenund Tabellenbedingungen eher einer passiven Kontrollinstanz entsprechen, setzen Trigger eine aktive Integritätssicherung um. Spaltenbedingungen werden bei der Replikation eines Snapshots von der Replikationsquelle auf einen mobilen Client nur teilweise mit übertragen. Während die NOT NULL-Klauseln und die PRIMARY KEY-Klauseln immer übernommen werden, ist dies bei Fremdschlüsselbeziehungen und bei über CHECK-Klauseln spezifizierten Tabellenbedingungen nicht der Fall. Jeder Snapshot kann jedoch mit der ALTER TABLE-Anweisung um neue, eigene CHECK-Klauseln ergänzt werden. Auch auf der Replikationsquelle implementierte Trigger werden nicht übernommen. Allerdings können Trigger, ebenso wie die CHECK-Klauseln, direkt auf der Replikationssenke mit der Anweisung CREATE TRIGGER deklariert und definiert werden. Konzeption und die Implementierung der angelegten Trigger obliegen dem Verantwortungsbereich des Datenbank-Administrators. Neben den Triggern kennt Oracle Lite weitere aktive Datenbankelemente. Dies sind die klassischen Stored Procedures und Userdefined Functions. Auf der Replikationsquelle definierte gespeicherte Prozeduren und nutzerdefinierte Funktionen werden nicht mit auf die Replikationssenken übertragen.

Konfliktvermeidung

Integritätssicherung

9.3.4 Oracle 10g Application Server (Wireless) Der Oracle 10g Application Server (Wireless) stellt eine mögliche Ausführungsplattform des Mobile Servers dar. Der Applikationsser-

9.3 Oracle Database 10g Lite

■ ■ ■

221

ver ermöglicht mobilen Clients einen universellen Zugriff auf Daten über unterschiedliche Drahtlostechniken (vgl. Abbildung 9.8). Die Implementierung des Servers basiert auf einem multimodalen Kern (Multi Modal Core), der die Entwicklung mobiler Anwendungen unabhängig von der technischen Charakteristik mobiler Clients und auch unabhängig von Netzwerken, Protokollen, Markup-Sprachen oder Gateways ermöglicht. Der Applikationsserver übernimmt die Rolle eines Proxy-Servers, der die von einer Applikation genutzte Netzwerktechnologie und -topologie normalisiert und schließlich auf ein einziges Protokoll und eine einzige Sprache abbildet: HTTP als Transportprotokoll und J2EE/XML als Programmiersprache bzw. Nachrichtenformat. Handy

PDA

Notebook

Mobile Geräte Markup Languages Protokolle

Normalisierung

Abb. 9.8: Universeller drahtloser Zugriff

Netzwerk

DB

Oracle 10g Applikationsser ver (Wireless)

Oracle Datenbank-Server

9.3.5 Programmierung Mobile Development Kit (MDK)

222

■ ■ ■

Alle erforderlichen Tools für die Entwicklung Oracle Lite-basierter Datenbankanwendungen sind im Mobile Development Kit (MDK) zusammengefasst. Dies ist eine Zusammenstellung verschiedener Werkzeuge, APIs, Dokumentation und Beispielanwendungen, die die Anwendungsentwicklung erheblich beschleunigen können. Zwar enthält das Mobile Development Kit keine spezielle Entwicklungsumgebung für Oracle Lite wie sie beispielsweise bei DB2 Everyplace mit dem Mobile Application Builder existiert, allerdings können

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

beliebige Entwicklungsumgebungen, wie z.B. Oracles JDeveloper, für die Anwendungsentwicklung verwendet werden. Für die Programmierung der Anwendungen selbst kann auf verschiedene Programmiersprachen wie C/C++, Visual Basic oder Java zurückgegriffen werden. Eine Besonderheit im Vergleich zu DB2 Everyplace stellt die Möglichkeit dar, browserbasierte Anwendungen zu entwickeln, die die Benutzeroberfläche und den Zugriff auf die Datenbank über HTML-Seiten realisieren. Vor allem der Wechsel zwischen Online- und Offline-Szenarien bleibt in diesem Fall völlig transparent. Bei einer Netzwerkverbindung wird direkt auf den Daten des Datenbankservers gearbeitet, ansonsten wird auf den lokalen Daten des mobilen Datenbanksystems gearbeitet. Die Benutzeroberfläche bleibt in beiden Szenarien gleich und im Idealfall kann ein Nutzer nicht erkennen, welches Szenario gerade vorliegt.

Browserbasierte Anwendungen

9.3.6 Zusammenfassung Mit Oracle 10g Lite bietet Oracle genauso wie IBM eine ausgereifte Lösung für die Integration mobiler Datenbankanwendungen in bestehende IT-Infrastrukturen an. Alle notwendigen Features mobiler Datenbanksysteme werden bereitgestellt. Kern der Produkte ist das leichtgewichtige, mobile Datenbanksystem Oracle Lite, das auf den mobilen Clients die benötigte Datenbankfunktionalität verfügbar macht. Die Unterstützung von Replikation und Synchronisationsverfahren garantiert eine Unterstützung des Disconnected Mode mobiler Clients und die Entwicklung von Offline-Anwendungen. Die Datenbank-Engine von Oracle Lite unterstützt die meisten bekannten Datenbankfunktionen, darunter Stored Procedures und Trigger. Um Synchronisationskonflikte aufzulösen, stehen leistungsfähige Routinen und Mechanismen bereit. Nach einem DatenbankCrash kann eine Datenbank leicht wiederhergestellt werden, und mit Hilfe entsprechender Logging-Dateien kann jede Transaktion im Falle eines Fehlers rückgängig gemacht werden. Für alle Transaktionen können stets alle ACID-Eigenschaften durchgesetzt werden. Als Nachteil muss jedoch die schwierige und komplexe Installation sowie die Konfiguration der Mobile Server Environment genannt werden. Im Vergleich erwies sich die Installation und Konfiguration von DB2 Everyplace als einfacher. In Funktionalität und Ausstattung entspricht Oracle 10g Lite dem Konkurrenzprodukt von IBM und geht an einigen Stellen sogar darüber hinaus, beispielsweise bei der Unterstützung browserbasierter Anwendungen.

9.3 Oracle Database 10g Lite

■ ■ ■

223

9.4 SQL Anywhere Studio

Plattformunterstützung

Der Datenbank-Hersteller Sybase tritt im Marktsegment mobiler Datenbanksysteme nicht selbst, sondern über sein Tochterunternehmen iAnywhere auf. Alle relevanten Produkte werden von iAnywhere im SQL Anywhere Studio (aktuelle Version 9, April 2004) zusammengefasst. Die wichtigsten Kernprodukte des SQL Anywhere Studios sind das relationale Datenbanksystem Adaptive Server Anywhere (ASA) und das eingebettete Datenbanksystem UltraLite. Die aktuelle Version von Adaptive Server Anywhere unterstützt verschiedene Plattformen, darunter diverse Linux- und UnixDerivate, alle Win32-Betriebssysteme (Windows 98, Windows Me, Windows 2000, Windows XP), Pocket PC und Palm-OS. Das Datenbanksystem UltraLite kann aktuell auf Pocket PC und Windows Mobile 2003-Systemen, aber auch auf Palmtops und Java-fähigen Geräten eingesetzt werden. Bei UltraLite handelt es sich jedoch um kein eigenständiges, von Anwendungen völlig unabhängiges Datenbanksystem, sondern um in ihrer Funktionalität an die Bedürfnisse von Anwendungen genau angepasste Datenverwaltungskomponenten, die in Anwendungen einkompiliert werden. UltraLite ist damit eher als Bibliothek spezifischer Datenbankfunktionen zu verstehen, die ganz nach Bedarf in Anwendungen integriert werden können. Die Unabhängigkeit des Datenbanksystems geht dabei verloren.

9.4.1 Komponenten Mobile Infrastruktur

Leistungsstarke mobile Clients

224

■ ■ ■

Das SQL Anywhere Studio besteht aus den beiden mobilen Datenbanksystemen Adaptive Server Anywhere und UltraLite sowie zusätzlich aus den beiden Synchronisationsmodulen SQL Remote und MobiLink. Alle vier Produkte werden nachfolgend vorgestellt: ■

Adaptive Server Anywhere (ASA). Bei dem mobilen Datenbanksystem Adaptive Server Anywhere handelt es sich um ein relativ schlankes relationales Datenbanksystem, das sowohl Einals auch Mehrbenutzerbetrieb unterstützt und speziell auf leistungsstarken mobilen Clients (oder alternativ auch auf stationären Rechnersystemen) eingesetzt werden kann. Was seinen Funktionsumfang anbelangt ist es ein vollständiges SQLDatenbanksystem. GUI-Tools erlauben das einfache Verwalten von Daten. Die beste Performanz zeigt ASA auf Rechnersyste-

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

men, die über hinreichend viel Speicher und CPU-Leistung verfügen. Aber auch in Umgebungen mit relativ begrenzten physischen Ressourcen (mindestens 8 MB RAM müssen es jedoch sein), also beispielsweise auf leistungsstarken PDAs, wird immer noch eine gute Performanz erzielt. Für einen Einsatz zusammen mit leistungsschwachen mobilen Clients, wie älteren Handhelds oder eingebetteten mobilen Systeme ist der Adaptive Server Anywhere dagegen nicht geeignet. ■

UltraLite. UltraLite ist kein eigenständiges Datenbanksystem, vielmehr ermöglicht es, eine Datenbank zusammen mit beliebiger Datenzugriffslogik in eine Host-Anwendung zu integrieren. Anwendung und Datenbank bilden zusammen eine UltraLiteAnwendung. UltraLite wird im Gegensatz zum ASA vor allem auf leistungsschwächeren mobilen Einheiten wie PDAs, Mobiltelefonen oder älteren Organizern eingesetzt. UltraLiteAnwendungen können einen sehr kleinen Speicher-Footprint besitzen, der mit der Aufgabe des bei Datenbanksystemen normalerweise üblichen Prinzips der Datenunabhängigkeit erkauft wird. UltraLite bietet die Funktionalität und Zuverlässigkeit einer vollständigen SQL-Datenbank mit Transaktionsverwaltung, und dazu die Möglichkeit, Daten mit einer zentralen Instanz zu synchronisieren sowie Entwicklungstools für Java oder C++. Von einer Anwendung nicht benötigte Funktionsmodule von UltraLite müssen jedoch nicht immer verfügbar sein und können deswegen von der Einkompilierung in eine Anwendung ausgeschlossen werden. Dadurch kann eine erhebliche Einsparung des benötigten Speicherplatzes erreicht werden. Gleichzeitig ist aber auch eine sehr starke Modularität der Datenbankfunktionalität vorauszusetzen. Dabei ist eine in eine Anwendung integrierte Datenbank nur für eine einzige Host-Anwendung zugänglich, nämlich für die Anwendung, in die die Datenbank einkompiliert wurde.

Leistungsschwache mobile Clients

■

SQL Remote. Bei SQL Remote handelt es sich um eine Synchronisationskomponente bzw. eine Technologie zur Datenreplikation in mobilen Umgebungen, die ausschließlich mit dem Adaptive Server Anywhere, nicht jedoch mit UltraLite eingesetzt werden kann. Durch SQL Remote wird ein nachrichtenbasiertes, asynchrones Synchronisationsverfahren implementiert, das sich verschiedener Protokolle und Techniken zur Übertragung von Synchronisationsnachrichten bedienen kann (FTP, SMTP, MAPI). Auftretende Konflikte werden zuverlässig erkannt und können durch frei definierbare Programmroutinen behandelt werden. Voraussetzung ist allerdings, dass sowohl auf

Synchronisation

9.4 SQL Anywhere Studio

■ ■ ■

225

den mobilen Clients als auch auf dem Datenbankserver im Backend der Adaptive Server Anywhere installiert ist. SQL Remote ist insbesondere auf lange Latenzzeiten und die Übertragung lediglich geringer Datenvolumina spezialisiert. Dies ist eine direkte Konsequenz der asynchronen Kommunikation. Abb. 9.9: Komponenten des SQL Anywhere Studios

SQL Remote / MobiLink

PDAs, Notebooks Adaptive Server Anywhere PDAs, Pager, Smartphones, Handy

Adaptiver Server Anywhere

MobiLink UltraLite

Synchronisation

■

MobiLink. Bei MobiLink handelt es sich um eine neueres Synchronisationsverfahren, das auch zusammen mit UltraLite eingesetzt werden kann. Auf längere Sicht wird MobiLink die SQL Remote-Technik durch seine flexibleren Einsatzmöglichkeiten ersetzen. So unterstützt MobiLink im Gegensatz zu SQL Remote die Anbindung beliebiger ODBC-Datenbanken im Backend. MobiLink implementiert ein sitzungsbasiertes, synchrones bidirektionales Synchronisationsverfahren, bei dem die Replikation in Echtzeit über eine bestehende Kommunikationsverbindung durchgeführt wird. Zum Zeitpunkt eines Synchronisationsvorganges muss eine Verbindung zwischen einer mobiler Einheit und einem zentralen Datenbankserver aufgebaut sein. Als Kommunikationsprotokolle können TCP/IP, HTTP, Palms HotSync oder Microsofts ActiveSync verwendet werden. Die Steuerung der Synchronisation erfolgt durch Synchronisationsskripte, die durch den Datenbank-Administrator beliebig definiert werden können.

Bei den vorgestellten Komponenten (vgl. Abbildung 9.9) handelt es sich um die vier Kernkomponenten von SQL Anywhere Studio. Dazu kommen diverse kleinere Tools, die zusätzliche Features und Funktionen. In den folgenden Abschnitten wird die Funktionsweise dieser vier Kernkomponenten genauer erläutert.

226

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

9.4.2 Adaptive Server Anywhere und UltraLite Beim Adaptive Server Anywhere (ASA) handelt es sich um ein relationales Datenbanksystem, das sowohl Ein- als auch Mehrbenutzerbetrieb sowie Stored Procedures und Trigger unterstützt. Um nach einem Fehlerzustand ein automatisches Wiederherstellen eines konsistenten Zustands der Datenbank zu garantieren, werden entsprechende Recovery-Mechanismen bereitgestellt. Die referentielle Integrität wird überwacht, zusätzlich können Integritätsbedingungen definiert werden. Als deskriptive Anfragesprache wird SQL unterstützt. Eine Besonderheit von ASA ist, dass Java-Objekte direkt in den relationalen Tabellen des Datenbanksystems gespeichert werden können. Java

Open Client

JDBC

C/C++, Delphi, Visual Basic ODBC

OLE DB ActiveX Data Objects (ADO)

C/C++

C/C++

Anwendung

eSQL

API

SQL

Laufzeitkomponenten

Adaptive Server Anywhere

Abb.. 9.10: Programmierschnittstellen des ASA

JDBC-ODBC Bridge

Open Server

jConnect

Tabular Data Streams

ODBCTreiber

OLE DB Provider Command Sequence

Adaptive Server Anywhere

DBMS

Um auf die Funktionen der Datenbank-Engine zugreifen zu können, setzen direkt auf dem ASA zwei Zugriffs-Protokolle auf (vgl. Abbildung 9.10): die Tabular Data Streams (TDS) und der Command Sequence (CS). Jede Anwendung muss auf einem dieser beiden Protokolle aufsetzen. Auf den Tabular Data Streams basiert die Open ServerSchnittstelle, die die Entwicklung von C/C++-Anwendungen unter Verwendung eines proprietären APIs erlaubt. Auch die jConnectSchnittstelle für den Zugriff über JDBC setzt auf den TDS auf. Auf der Command Sequence setzen weitere Schnittstellen wie ODBC oder Embedded SQL (eSQL) auf. eSQL wird durch einen Präcompiler unterstützt. Da sowohl JDBC- als auch eine ODBC-Schnittstelle bereitgestellt wird, ist der Einsatz vieler Programmiersprachen (Java,

9.4 SQL Anywhere Studio

Anwendungsschnittstellen

■ ■ ■

227

C/C++, Visual Basic, Delphi) im Rahmen der Anwendungsentwicklung möglich. Der ASA kann entweder auf mobilen Clients oder als zentraler Datenbankserver eingesetzt werden. Für den Einsatz als Datenbankserver steht er jedoch in Konkurrenz zum Adaptive Server Enterprise23, einem ebenfalls von iAnywhere angebotenen, hoch skalierenden SQL-Server, der explizit dem Hochleistungssegment zuzuordnen ist. Da der ASA verhältnismäßig viel Speicherplatz allokiert und relativ hohe Anforderungen an die Hardware stellt, eignet sich dieses Datenbanksystem nicht für einen Einsatz auf leistungsschwächeren PDAs und mobilen Kleinst-Computern. Für diese kann stattdessen auf UltraLite zurückgegriffen werden. UltraLite

Die UltraLite-Datenbank-Engine ist als Bibliothek von DatenbankFunktionen implementiert, die von einer Host-Anwendung benutzt werden können. Dadurch wird die notwendige Modularität erreicht, um Datenbanken an die spezifischen Bedürfnisse von Anwendungen anzupassen. Zielplattformen von UltraLite sind kleine, mobile und eingebettete Rechnersysteme, wie beispielsweise Mobiltelefone oder leistungsschwache PDAs. Da anwendungsspezifische Datenbanken vollständig in Anwendungen „einkompiliert“ werden, stellt UltraLite kein autonomes Datenbanksystem mehr dar. Anwendungen können über einen vollständigen Satz an Datenbankfunktionen verfügen und damit Daten einer Anwendung speichern, abfragen und bearbeiten. Die möglichen Datentypen, Laufzeitfunktionen und Datenmanipulationsfunktionen entsprechen denjenigen Konstrukten, die auch auf dem Adaptive Server Anywhere verfügbar sind. Als Synchronisationskomponente kommt MobiLink zum Einsatz. MobiLink erlaubt die Synchronisation von Datenbeständen einer UltraLite-Anwendung mit beliebigen Adaptiver Server AnywhereInstallationen. Darüber hinaus werden alle ODBC-kompatiblen Datenbanksysteme (zum Beispiel DB2 Universal Database, Oracle 10g) unterstützt. Jede UltraLite-Anwendung besitzt eine proprietäre Anwendungsdatenbank, die von anderen Anwendungen nicht genutzt werden kann. Die jeweilige Datenbank-Engine wird anhand einer Referenzdatenbank erzeugt, die zuvor auf einer Adaptive Server Anywhere23 Der Adaptive Server Enterprise (ASE) ist ein relationales HochleistungsDatenbanksystem, das speziell an die umfangreichen Bedürfnisse einer unternehmensweiten Datenverarbeitung angepasst ist. Obwohl der Name auf eine grosse Ähnlichkeit zum Adaptive Server Anywhere (ASA) schließen lässt, bestehen trotzdem erhebliche Unterschiede zwischen beiden Produkten.

228

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Installation definiert wurde. Abhängig von der jeweiligen Zielplattform (Palm-OS, Pocket PC, usw.) können die auf diese Weise erzeugten Datenbank-Engines eine Größe von weniger als 50 kB aufweisen. Weitere Einflussgrößen auf den Speicher-Footprint sind die Anzahl der von in einer UltraLite-Anwendung unterstützten SQLAnweisungen und die Komplexität verwendeter SQL-Funktionen.

9.4.3 Replikation und Synchronisation Im Folgenden werden die zwei von SQL Anywhere Studio bereitgestellten Synchronisationsverfahren vorgestellt. Replikation wird bei beiden Systemen als unidirektionale Synchronisation vom Datenbankserver zum mobilen Client verstanden. Die Synchronisation dagegen dient dem Abgleich der verschiedenen Replikate und impliziert stets die Vorstellung eines bidirektionalen Synchronisationsprozesses. 9.4.3.1 SQL Remote Bei SQL Remote handelt es sich um das ältere der beiden vorgestellten Synchronisationsverfahren. SQL Remote unterstützt die bidirektionale Synchronisation zwischen einem zentralen Datenbankserver und einer beliebigen Anzahl entfernter Instanzen. Im Normalfall sind entfernte Instanzen auf mobilen Clients. SQL Remote wird vor allem dann eingesetzt, wenn sowohl der zentrale Datenbankserver als auch die entfernten Instanzen Adaptive Server AnywhereInstallationen sind. Die Synchronisation mit UltraLite wird von SQL Remote nicht unterstützt. SQL Remote basiert auf dem Austausch von Nachrichten. Nachrichten werden dazu typischerweise über gemeinsam genutzte Dateien (Shared Files) ausgetauscht, die in einem gemeinsamen Verzeichnis abgelegt sind. Für die Übertragung von Synchronisationsnachrichten ist eine spezielle Komponente zuständig, die auch als Message System Client bezeichnet wird (vgl. Abbildung 9.11). Zur Übertragung der Synchronisationsnachrichten können verschiedene Kommunikationsprotokolle (FTP, SMTP) verwendet werden. Aufgrund des nachrichtenorientierten Charakters der Kommunikation nennt man SQL Remote ein asynchrones Synchronisationsverfahren. Datenbanken, die an Synchronisationsprozessen teilnehmen möchten, müssen Message Agents implementieren, die die Koordination der Synchronisation übernehmen. Der Message Agent ist so-

9.4 SQL Anywhere Studio

Nachrichtenbasierte Synchronisation Message System Clients

Message Agents

■ ■ ■

229

wohl für die Erstellung als auch für die Interpretation empfangener Synchronisationsnachrichten zuständig. Aufgrund der asynchronen Kommunikation ist eine direkte Verbindung zwischen zwei Synchronisationspartnern im Rahmen einer Sitzung nicht notwendig. Abb. 9.11: Synchronisation mit SQL Remote [nach SAS04]

Server

Client

Adaptive Server Anywhere Message Agent

Mobile Datenbank

Shared File

Message System Client

Message Agent Message System Client

SMTP POP MAPI

Sitzungsbasierte Synchronisation

MobiLink-Server

230

■ ■ ■

9.4.3.2 MobiLink Im Gegensatz zum nachrichtenbasierten Synchronisationsverfahren SQL Remote handelt es sich bei MobiLink um ein sitzungsbasiertes Synchronisationsverfahren. Die dazu notwendige Kommunikation erfolgt direkt, das heisst während eines Synchronisationsvorganges muss eine Kommunikationsverbindung zwischen den an der Synchronisation beteiligten Prozessen bzw. Datenquellen existieren. Ein solches Szenario ist mit einem Telefongespräch vergleichbar, bei dem beide Seiten während des Gesprächs alle offenen Fragen klären. Auch MobiLink realisiert genau wie SQL Remote eine bidirektionale Synchronisation zwischen einem zentralen Datenbankserver und einer (unter Umständen) großen Anzahl entfernter Clients. Als Datenbankserver muss nicht unbedingt Adaptive Server Anywhere eingesetzt werden, andere ODBC-Datenbanksysteme sind ebenfalls möglich. Bei den entfernten Instanzen muss es sich allerdings um mobile Clients mit Adaptive Server Anywhere-Installationen oder UltraLite-Anwendungen handeln. Kern der von MobiLink implementierten Synchronisationsarchitektur (vgl. Abbildung 9.12) ist der MobiLink-Server, der verschiedene Aufgaben übernimmt. Er kontrolliert sowohl die Ausführung als auch den Status der Synchronisation für alle entfernten Instanzen. Die für diese Aufgabe erforderlichen Daten, Skripte (zur Ablaufsteuerung eines Synchronisationsvorganges) und Kontrollinformationen, werden auf dem Datenbankserver gespeichert. Auf diesen wird über die ODBC-Schnittstelle zugegriffen. Die Hauptaufgabe von MobiLink liegt in der Kontrolle des Datenflusses zwischen Ser-

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

ver und den Clients. Die korrespondierende Komponente auf den Clients wird als MobiLink-Client bezeichnet. Weitere Aufgaben des MobiLink-Servers sind: ■

Datenkoordination. MobiLink ist für die Koordination der Datenübertragung zuständig. Dazu müssen die für die Synchronisation relevanten Daten ausgewählt und auftretende Synchronisationskonflikte gelöst werden. Während die Auswahl der zu synchronisierenden Daten bei UltraLite-Anwendungen automatisch in die Host-Anwendung integriert wird, ist bei Adaptive Server Anywhere-Installationen eine durch den Nutzer durchzuführende Definition entsprechender Daten notwendig.

■

Automatisierung. Synchronisationsvorgänge können automatisiert werden. Während für UltraLite-Anwendungen die Automatisierung bereits bei der Entwicklung berücksichtigt werden muss, kann bei Adaptive Server Anywhere-Installationen die Automatisierung flexibel auch zur Laufzeit angepasst werden.

■

Kommunikation. Die im Rahmen einer Synchronisation auftretende Datenkommunikation kann über verschiedene Protokolle (TCP/IP, serielle Kommunikation) durchgeführt werden. Im Falle einer seriellen Kommunikation können die HotSyncTechnologie (bestehen aus HotSync-Client, HotSync-Manager und HotSync-Conduit) von Palm oder die korrespondierende Technik ActiveSync von Microsoft eingesetzt werden. Server

Mobile Einheit

RDBMS

UltraLite

Aufgaben

Abb. 9.12.: Datenbankanbindung einer UltraLiteAnwendung mittels MobiLink [nach SAS04]

ODBC MobiLink Server HotSync Manager / HotSync Conduit

■

TCP/IP

MobiLink Client HotSync Client

HotSync

Überwachung und Berichterstellung. MobiLink kann durchgeführte Synchronisationsvorgänge überwachen. Zu den erfassten Vorgängen können automatisch Berichte generiert werden, die dem Administrator des Systems helfen können, fehlerhafte Synchronisationsvorgänge zu erkennen und zu beheben.

9.4 SQL Anywhere Studio

■ ■ ■

231

Transaktionsintegrität

Logging

Performanz

Ein Synchronisationsvorgang wird immer von mobilen Clients initiiert. Dabei wird Transaktionsintegrität garantiert, das heisst die Änderungen einer Datenbank werden entweder ganz mit der zentralen Datenbank synchronisiert oder gar nicht. Trotzdem kann Konsistenz innerhalb der gesamten Synchronisationsumgebung nur im Sinne einer losen Konsistenz garantiert werden. So können zu einem bestimmten Zeitpunkt verschiedene Instanzen unterschiedliche Datenbestände aufweisen. Zwar werden alle auf dem Datenbankserver eingebrachten Änderungen mit den anderen entfernten Instanzen synchronisiert, diese Synchronisation erfolgt jedoch asynchron. Um bei der Koordination der Synchronisation eine möglichst grosse Flexibilität zu bieten, können durch den Datenbank-Administrator Skripte definiert werden, die bei jedem Synchronisationsvorgang ein genau definiertes Ereignismodell ausführen. Um eine korrekte Synchronisation durchführen zu können, ist es erforderlich, dass jeder MobiLink-Client alle lokal durchgeführten Änderungsoperationen protokolliert. Jeder Client muss darüber hinaus die protokollierten Änderungsoperationen adäquat aufbereiten, bevor sie dem MobiLink-Server übermittelt werden. Gleichzeitig muss ein MobiLink-Client auch in der Lage sein, Änderungen des Datenbestandes zu integrieren, die er vom zentralen Datenbankserver erhalten hat. Um die Performanz des MobiLink-Synchronisationsservers zu verbessern, können eine Reihe von Tuning-Maßnahmen durchgeführt werden. Darunter fallen die Größe des Übertragungscaches, die Anzahl gleichzeitiger Datenbankverbindungen, die Festlegung von BLOB-Cachegrößen und die Protokollierung von Textausgaben. Durch die Unterstützung von Threads kann für das MobiLinkVerfahren hohe Skalierbarkeit gewährleistet werden. Ebenfalls verfügbare Techniken der Lastverteilung erlauben den gleichzeitigen Betrieb mehrerer MobiLink-Server.

9.4.4 Programmierung Anwendungsentwicklung

UltraLite unterstützt eine grosse Anzahl an Programmierschnittstellen für die Entwicklung von UltraLite-Anwendungen. Auf zwei Besonderheiten im Zusammenhang mit der Programmierung in C/C++ und Java gehen wir genauer ein: ■

232

■ ■ ■

C/C++. Mit C bzw. C++ entwickelte UltraLite-Anwendungen können statisches Embedded SQL (eSQL) verwenden. Durch einen Präprozessor und den Compiler wird dabei in einem

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

mehrstufigen Prozess aus dem eSQL-Quellcode und der Referenzdatenbank die UltraLite-Anwendung generiert (vgl. Abbildung 9.13). Das Ergebnis ist eine einzelne, ausführbare Datei (EXE-Datei), die neben der Datenbank auch die Anwendungsund die Datenzugriffslogik enthält. ■

Java. Die verfügbare Java-Unterstützung erlaubt es, sowohl in Java-Anwendungen als auch in Java Applets UltraLite-Datenbanken zu integrieren. Der Zugriff auf die einkompilierte Datenbank erfolgt über die JDBC-Schnittstellentechnologie. Referenzdatenbank

Database Access Code

Abb. 9.13: Programmiermodell [nach Fan00]

UltraLite Analyzer

Preprocessed SQL Code

Plattformspezifische Datenbank-Server Bibliotheken

Application Code

Compiler

Linker

UltraLite-Anwendung mit einkompilierter Datenbank

Konzeption und Entwicklung von UltraLite-Datenbankanwendungen folgen einem fest vorgegebenen Schema. Abhängig davon, welche Programmiersprache für die Entwicklung verwendet wird, sind jedoch geringe Variationen dieses Schemas möglich. Abbildung

9.4 SQL Anywhere Studio

UltraLiteAnwendungen

■ ■ ■

233

Referenzdatenbank vs. Anwendungsdatenbank

UltraLiteAnalyzer

9.13 zeigt das Programmiermodell bei der Entwicklung von eSQLC/C++-Anwendungen. Während der Anwendungsentwicklung muss eine Referenzdatenbank in die UltraLite-Anwendung integriert werden. Die Referenzdatenbank wird ausschließlich während der eigentlichen Entwicklung benötigt. Eine bereits integrierte Datenbank wird als Anwendungsdatenbank bezeichnet. Hauptfunktion der Referenzdatenbank ist die Definition des Datenbankschemas. Darüber hinaus werden in der Referenzdatenbank alle zu integrierenden SQL-Anweisungen und SQL-Funktionen festgelegt. Zusätzlich eingebettete, statische SQL-Anweisungen werden durch einen Präprozessor während einer Vorübersetzung ebenfalls in die Referenzdatenbank integriert. Im Anschluss daran erzeugt der Compiler, basierend auf der Referenzdatenbank, die konkrete Anwendungsdatenbank, die zusammen mit der Datenzugriffslogik (Data Access Code) und der Anwendungslogik (Application Code) eine UltraLiteAnwendung formt. Die Datenbankfunktionalität selbst ist in Form einer Laufzeitbibliothek implementiert und kann aus einer Anwendung heraus mittels spezieller Aufrufe angesprochen werden. Die Kernkomponenten des Entwicklungsprozesses bilden einige spezielle Java-Klassen, die zusammen als UltraLite-Analyzer bezeichnet werden und die für die Ermittlung einer unter den gestellten Rahmenbedingungen minimalen Datenbank-Engine zuständig sind. Zunächst analysiert der UltraLite-Analyzer dazu die Referenzdatenbank um im Anschluss eine minimale Datenbank-Engine zu generieren, die genau die gewünschte und in der Referenzdatenbank spezifizierte Funktionalität implementiert. Die UltraLite-Anwendung selbst entsteht aber erst durch einen Link-Prozess, der alle relevanten Bestandteile zu einer einzigen, ausführbaren Datei zusammenbindet. Das Schema einer UltraLite-Datenbank kann nach dem Verknüpfen mit einer Anwendung nicht mehr geändert werden. Macht eine neue Version einer Anwendung Änderungen des Datenbankschemas erforderlich, muss auch eine neue Anwendung erstellt werden.

9.4.5 Zusammenfassung Das SQL Anywhere Studio für den Aufbau von Infrastrukturen mobiler Datenverarbeitung umfasst zwei Komponenten: das relationale, mächtige Datenbanksystem Adaptive Server Anywhere und die flexibel anpassbare Laufzeitbibliothek UltraLite. Dazu kommen die Synchronisationsverfahren SQL Remote und MobiLink. Durch das Zusammenspiel dieser Komponenten kann eine leistungsfähige

234

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Plattform für eine effiziente mobile Datenverarbeitung aufgebaut werden. Vor allem UltraLite-Anwendungen weisen ein hohes Potential auf, was den schonenden Umgang mit Ressourcen anbelangt. Durch die Integration einer spezifischen Datenbank in eine Anwendung kann ein extrem kleiner Speicher-Footprint erreicht werden. Dies erlaubt die Realisierung mobiler Anwendungen nicht nur für Notebooks, auf denen der Adaptive Server Anywhere eingesetzt wird, sondern auch für leistungsschwächere mobile Clients, auf denen dann UltraLite eingesetzt wird. Was die Durchführung von Synchronisationsprozessen anbelangt, kann auf einen Einsatz von SQL Remote aufgrund seiner mangelnden Flexibilität und aufgrund der Verfügbarkeit des moderneren MobiLinks verzichtet werden.

9.5 Tamino Mobile Suite Die Tamino Mobile Suite [TAM04] fasst diejenigen Produkte zusammen, die von der Software AG für die mobile Datenverarbeitung von XML-Dokumenten angeboten werden. Kern der Tamino Mobile Suite ist das mobile, leichtgewichtige XML-Datenbanksystem Tamino Mobile DB. Die aktuelle (April 2004) Version 4.0 ist auf Pocket PCs und Palmtops mit StrongARM-, MIPS-, XScale- oder SH3-Prozessoren einsetzbar. Durch die Unterstützung der Java 2 Micro Edition (J2ME) können auch Nokias 9210 Communicator und andere Javafähige Clients eingesetzt werden. Die iPAQ-PDA-Serie von Hewlett-Packard wird ebenfalls unterstützt, allerdings setzt dies die Installation der Insignia Jeode Virtual Machine voraus. Nicht unterstützt wird dagegen Symbian. Serverseitig enthält die Tamino Mobile Suite eine Laufzeitumgebung, die Tamino Mobile Run-Time Environment genannt wird. Diese besteht aus verschiedenen Serverkomponenten, die unter anderem die Funktionalität für den Aufbau einer Synchronisationsinfrastruktur bereitstellen. Die wichtigsten Komponenten der serverseitigen Laufzeitumgebung sind: ■

der Tamino Mobile Synchronization Server (TMSS),

■

der Tamino Mobile Notification Server (TMNS) und

■

der Tamino Mobile Presentation Server (TMPS).

9.5 Tamino Mobile Suite

Plattformunterstützung

Serverseitige Laufzeitumgebung

■ ■ ■

235

9.5.1 Komponenten Mobile Infrastruktur

Die Komponenten der Tamino Mobile Suite sind in Abbildung 9.14 zusammengefasst und werden im Folgenden genauer beschrieben:

Mobiler Client

■

Tamino Mobile Database. Das mobile Datenbanksystem Tamino Mobile Database (TMDB) ist das leichtgewichtige SmallFootprint-Datenbanksystem, das auf mobilen Clients wie Notebooks oder PDAs installiert wird. Der Unterschied zu den bereits vorgestellten Konkurrenzprodukten liegt in der Implementierung eines XML-basierten Datenmodells. Alle gespeicherten Anwendungsdaten werden in Datenbanken in Form von XMLDaten abgelegt. Für die Formulierung von Abfragen und für die Navigation auf den XML-Daten wird nicht SQL, sondern die vom W3C vorgeschlagene Abfragesprache XQuery verwendet. Alternativ kann auch reines XPath benutzt werden.

Middleware

■

Synchronization Server & SyncModule. Der Tamino Mobile Synchronization Server (TMSS) stellt den Kern der serverseitigen Synchronisationsarchitektur der Tamino Mobile Suite dar. In den Aufgabenbereich des Synchronisationsservers fallen das Verbindungsmanagement und die Datensynchronisation. Mit dem Synchronisationsmodul SyncModule steht dem Synchronisationsserver clientseitig eine funktional ähnliche Komponente gegenüber. Beide zusammen sind für die Synchronisation zwischen den mobilen Clients und dem Datenbankserver zuständig. Ein Synchronisationsvorgang kann entweder durch die Anfrage eines mobilen Clients oder automatisch durch das Auslösen server-basierter Monitoring-Funktionen initiiert werden.

■

Presentation Server. Der Tamino Mobile Presentation Server (TMPS) realisiert die Schnittstelle für browserbasierte Zugriffe mobiler Clients. Aufgabe dieser Serverkomponente ist es, Inhalte der zentralen Datenbank in verschiedene Ausgabeformate umzuwandeln. Dazu können diverse Markup-Sprachen (VoiceXML, WML, HTML, HDML) und viele bekannte WebStandards (XHTML, XSLT, JSP) verwendet werden.

■

Notification Server. Mit dem Tamino Mobile Notification Server (TMNS) kann ein Benachrichtigungsdienst zwischen Backend und Frontend mit den drei Einsatzszenarien (a) System an Person, (b) Person an Person und (c) System an System realisiert werden. Nachrichtentypen sind SMS oder E-Mails.

236

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

■

Tamino Mobile Studio. Zur Entwicklung mobiler Datenbankanwendungen existiert mit dem Tamino Mobile Studio eine integrierte Entwicklungsumgebung, die Ähnlichkeiten zum Mobile Application Builder von DB2 Everyplace aufweist.

Anbindung des Backends

Notification Server

Abb. 9.14: Komponenten Presentation Server

Synchronization Server

Foundation Server. Der Tamino Mobile Foundation Server (TMFS) ist für die Integration und Anbindung verschiedenartiger Typen von Backend-Systemen (Datenbanksysteme, Applikationsserver, Legacy-Systeme) zuständig.

Sync Module

■

Tamino XML-Server

Foundation Server Mobiler Client

J2EE Applikationsserver

Middletier & Backend

Notification Server, Presentation Server und Synchronization Server werden zusammen auch als Solution Server bezeichnet. Solution Server und Foundation Server setzen auf einem J2EE-Applikationsserver auf (vgl. Abbildung 9.14). Dieser ist die Ausführungsumgebung der beschriebenen Server-Komponenten. Es wird also wieder die bekannte 3-schichtige Architektur, bestehend aus mobilen Clients, zwischengeschalteten Serverkomponenten und zentralem Datenbankserver im Backend realisiert.

Solution Server

3-Tier Architecture

9.5.2 Architektur der clientseitigen Datenbank-Engine Die Engine der clientseitigen mobilen Datenbank besteht aus verschiedenen Modulen, die zwischen den Anwendungsprogrammen und dem Betriebssystem angesiedelt sind und die schichtenorientierten Architekturprinzipien folgen (vgl. Abbildung 9.15). Wir beschreiben die Schichten von oben nach unten:

9.5 Tamino Mobile Suite

Komponenten

■ ■ ■

237

Anwendungsschnittstellen

■

Tamino Mobile API. Bei dem Tamino Mobile API handelt es sich um eine Programmierschnittstelle, auf der andere HighLevel-APIs (wie sie im XML-Umfeld häufig vorkommen, zum Beispiel SAX) und Anwendungen direkt aufsetzen können.

Transaktionen

■

Transaction Handler. Wenn mehrere Anwendungen auf eine gemeinsam genutzte, mobile Datenbank zugreifen, ist die Implementierung einer Transaktionsverwaltung notwendig. Der Transaction Handler sorgt durch den Einsatz von Sperren dafür, dass Schreiboperationen stets exklusiv ausgeführt werden. Leseoperationen können parallel ausgeführt werden, wobei allerdings während der Ausführung von Schreiboperationen keine Leseoperationen durchgeführt werden dürfen. Es kommt also ein ganz einfaches RX-Protokoll zum Einsatz. Dies genügt, da dieser Fall nur bei Laptops auftreten kann, alle anderen mobilen Clients (PDAs, Smartphones, …) sind typischerweise sowieso Single-Task-Systeme.

Anfrageausführung

■

Query Engine. Die Query-Engine ist für die Ausführung von Anfragen auf lokal gespeicherten Daten zuständig. Auf eine Anfrage – formuliert in den Sprachen XQuery oder XPath – wird eine Kollektion von Objekten zurückgegeben, die das festgelegte Selektionskriterium erfüllen. Um Anwendungen die Navigation innerhalb der Ergebnismenge und somit das stufenweise Verarbeiten von Objekten zu ermöglichen, wird ein einfaches Cursor-Konzept bereitgestellt.

Abb. 9.15: Architektur der TMDB-Engine [TAM04]

Mobile Anwendung Tamino Mobile API

Transaction Handler

Query Engine

Datenbankschema

Indexing and Searching Storage Management Betriebssystem (z.B. Pocket PC) ■

238

■ ■ ■

Datenbankschema. Das Datenbankschema enthält wie üblich das Data Dictionary. Dabei können Anwendungsdaten zu Objekten verschiedener Granularität zusammengefasst werden. Der Typ eines Objekts wird auch als Klasse bzw. Object Template bezeichnet. Ein Datenbankschema kann über spezielle Befehle,

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

wahlweise auch durch den Import (neuer) Schemainformationen geändert werden. ■

Indexing and Searching. Die Komponente Indexing and Searching implementiert schnelle Suchfunktionen auf den gespeicherten XML-Daten. Dazu verwendet sie verschiedene Indexstrukturen. Auch die Administration angelegter Indizes fällt in den Zuständigkeitsbereich dieser Komponente.

Indizierung

■

Storage Management. Das Speichermanagement ist für den Zugriff auf die Daten des persistenten Speichers des mobilen Clients zuständig. Wichtiger Bestandteil des Speichermanagements ist eine Mapping-Schicht, die betriebssystemspezifische Aufrufe, wie sie beispielsweise im Rahmen der Speicherplatzallokation notwendig sind, kapselt. Dieses Modul ist plattformspezifisch und kann als Portabilitätsschicht verstanden werden. Portabilitätsschichten sind austauschbar und adaptieren die Anforderungen der unterschiedlichen Plattformen. Soll eine Portierung der TMDB auf einen anderen Prozessortyp mit identischem Betriebssystem erfolgen, reicht es aus, den Quelltext der Portabilitätsschicht auf der neuen Plattform erneut zu kompilieren. Wird jedoch auch das Betriebssystem gewechselt, muss eine Adaption der Portabilitätsschicht erfolgen.

Speichermanagement

Nach der Vorstellung der wichtigsten Komponenten der Tamino Mobile Datenbank-Engine geht der folgende Abschnitt auf die verfügbaren Synchronisationsmechanismen ein.

9.5.3 Replikation und Synchronisation Replikation wird in wiederum als Synchronisation von Daten des Backends auf mobile Clients verstanden. Im Folgenden ist deswegen nur noch von Synchronisation die Rede. Für die Durchführung der Synchronisation sind der Tamino Mobile Smart Client (TMSC) auf dem mobilen Client und der Tamino Mobile Synchronization Server (TMSS) auf der Serverseite zuständig. Beide Komponenten werden auch als Tamino Mobile Offline Solution bezeichnet, da der Disconnected Mode mobiler Clients unterstützt wird. Realisiert wird ein Framework, das die Synchronisation sowohl ganzer Anwendungen als auch von Datenbeständen zwischen Backend und mobilen Clients erlaubt. Der Synchronization Server ist dabei für die Koordination der Synchronisation und die Erkennung

9.5 Tamino Mobile Suite

Tamino Mobile Offline Solution

Framework

■ ■ ■

239

Tamino Mobile Synchronization Server

und Auflösung von Synchronisationskonflikten zuständig. Es wird nicht garantiert, dass auch tatsächlich alle Konflikte behoben werden können. Synchronisationsvorgänge werden vom Entwickler noch während der Implementierung einer mobilen Anwendung in Form von Synchronisationsschablonen (Workflows) definiert und entsprechenden Client-to-Server- und Server-to-Client-Controllern zugewiesen. Die Synchronisationsschablonen legen fest, auf welche Weise ein Synchronisationsvorgang abzulaufen hat. Zur Synchronisation sind folgende Komponenten notwendig:

Persistente Objektspeicher

■

Object Queue. Object Queues sind persistente Objektspeicher auf dem mobilen Client, die sowohl für die dauerhafte Ablage lokaler Datenbestände als auch für die Zwischenspeicherung zu synchronisierender Objekte benutzt werden. Interessant ist vor allem die zweite Nutzvariante. Zu synchronisierende Objekte werden entweder vom Datenbankserver auf den mobilen Client oder vom mobilen Client auf den Datenbankserver übertragen. Jeder Synchronisationsvorgang bekommt dabei eine eigene Object Queue zugewiesen. Mit dem Ende eines Synchronisationsvorganges werden die synchronisierten Datenobjekte wieder aus der benutzten Object Queue gelöscht. Auf einem mobilen Client können beliebig viele Object Queues vorhanden sein.

Synchronisation

■

SyncManager. Diese Komponente ist für die Koordination eines Synchronisationsvorganges auf dem mobilen Client zuständig. Dazu können SyncGroups definiert und Parameter der SyncConnection gesetzt werden. Eine SyncGroup ist definiert als eine Menge von Object Queues. Sie kapselt alle die Object Queues, die im Rahmen der aktuellen Synchronisationssitzung berücksichtigt werden sollen. SyncGroups müssen mindestens eine Object Queue enthalten. Eine Object Queue kann dabei Bestandteil mehrerer SyncGroups sein. Ein Synchronisationsvorgang, in dessen Verlauf alle Anwendungsobjekte der Object Queues einer SyncGroup an den Datenbankserver übertragen werden, wird durch einen mobilen Client initialisiert. Zunächst müssen der Benutzername und das Passwort genauso wie eine Datenbank-URL für den Zugriff auf den Synchronization Server gesetzt werden. Danach wird die SyncConnection als HTTPVerbindung etabliert. Nach der Übertragung der Anwendungsobjekte an den Datenbankserver können auch neue Datenobjekte an die Object Queues des mobilen Clients übertragen werden.

■

Synchronization Server. Die Aufgabe des Synchronisationsservers ist die Bearbeitung von Synchronisationsanforderungen

240

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

mobiler Clients. Jede Anforderung eines mobilen Clients muss zunächst mit Hilfe eines speziellen Authentication Modules authentifiziert werden. Danach werden die zu synchronisierenden Daten an den Synchronization Server übermittelt. Über den Client-to-Server-Controller werden auf einem mobilen Client durchgeführte Änderungen im Backend nachgezogen. Über die Server-to-Client-Controller werden die der aktuellen SyncGroup angehörigen Anwendungsobjekte generiert, die im Gegenzug an den mobilen Client übertragen werden. Diese neuen Objekte werden als Teil der Server-Antwort auf die Synchronisationsanforderung hin an den Client übermittelt. Alle Anwendungsobjekte, die auf den mobilen Client übertragen werden sollen, die aber nicht der aktuellen SyncGroup zugewiesen werden können, werden über das Asynchronous Queue Plug-In bereitgestellt und anschließend ebenfalls übertragen. Asynchronous Queue Plug-In Authentication Plug-In

Mobiler Client SyncModule SyncManager

Abb. 9.16: Synchronisationsarchitektur [TAM04]

Synchronization Server Object Cache Client-to-Server Controller

Server-to-Client Controller

Object Queue Integration Server

Neben den eigentlichen Datenobjekten werden durch den Server-toClient-Controller auch die Anweisungen generiert, die ein mobiler Client benötigt, um die vom Server erhaltenen Datenobjekte mit den eigenen, lokal vorhandenen Datenobjekten abzugleichen. Mögliche Anweisungen sind INSERT, UPDATE und REPLACE. Mit INSERT wird das neue Datenobjekt einfach den vorhandenen Objekten hinzugefügt. Mit Update wird das lokal vorhandene Objekt durch das neu übertragene Datenobjekt ersetzt. Existiert dieses Datenobjekt auf dem mobilen Client noch nicht, hat Update die gleiche Wirkung wie INSERT. REPLACE ersetzt alle Datenobjekte der lokalen Object Queue durch die neuen Datenobjekte.

9.5 Tamino Mobile Suite

SynchronisationsController

■ ■ ■

241

■

Client-to-Server-Controller. Die Client-to-Server-Komponente verarbeitet die vom mobilen Client übermittelten, zu synchronisierenden Datenobjekte anhand der bereits während der Entwicklung spezifizierten Synchronisationsschablonen. Jede Object Queue hat auf dem Server einen eigenen Client-toServer-Controller, der für jedes einzelne Datenobjekt explizit aufgerufen wird.

■

Server-to-Client-Controller. Die Server-to-Client-Komponente generiert diejenigen Datenobjekte, die vom Datenbankserver an die mobilen Clients übermittelt werden sollen. Jeder Object Queue auf dem mobilen Client ist ein eigener Controller zugewiesen. Um neue Datenobjekte zu generieren, wird jeder Controller der Object Queues der aktuellen SyncGroup genau einmal aufgerufen.

■

Authentication Plug-In. Das Authentication Plug-In ist eine spezielle Java-Klasse, die vom Synchronization Server dazu benutzt wird, alle eingehenden Synchronisationsanforderungen zu authentifizieren. Dazu werden die als Teil der SyncConnection übermittelten Benutzernamen und Passwörter auf ihre Gültigkeit hin überprüft. Ein Entwickler kann die Java-Klasse nach eigenen Vorgaben überschreiben, um so einen beliebigen Authentifizierungsmechanismus zu realisieren. Das Ergebnis der Überprüfung wird an den Synchronisationsserver übermittelt.

■

Asynchronous Queue Plug-In. Mit Hilfe des Asynchronous Queue Plug-In, das eigentlich einer normalen Object Queue entspricht, können Datenobjekte an mobile Clients auch außerhalb einer regulären Synchronisationssitzung übermittelt werden.

Um eine Synchronisation zu ermöglichen, müssen durchgeführte INSERT-, UPDATE- und DELETE-Operationen protokolliert werden.

Zu jeder Operation werden zusätzlich der Operationstyp und die IDs der eingefügten, geänderten bzw. gelöschten Knoten gespeichert. Sobald eine Anwendung einen Synchronisationsvorgang anstößt, werden alle protokollierten Operationen in der Reihenfolge ihrer Aufzeichnung an den Synchronisationsserver übermittelt. Der Synchronisationsserver führt die protokollierten Operationen dann auf dem Datenbestand des Tamino XML Servers im Backend aus.

242

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

9.5.4 Implementierungskonzepte Jede Datenbank kann prinzipiell als Sammlung von Objekten betrachtet werden. Jedes dieser Objekte basiert auf einer Klasse. Eine Klasse wird im Datenbankschema als Teil der Metainformationen deklariert und gespeichert. Klassen definieren Schablonen für instanzierte Objekte. Von einer Klasse abgeleitete Objekte sind strukturierte Daten. Beim Anlegen eines neuen Objekts wird diesem von der Datenbank-Engine automatisch eine systemweit eindeutige ObjectID zugewiesen. Die ObjectID wird nach dem Löschen eines Objektes nicht wiederverwendet. Ein Objekt kann eine beliebige Anzahl an Attributen besitzen. Dabei unterscheidet man zwischen optionalen (Optional Attribute) und verpflichtenden, nicht-optionalen Attributen (Mandatory Attribute). Optionale Attribute können während der Laufzeit dynamisch angelegt und auch wieder gelöscht werden. Für verpflichtende Attribute gilt dies nicht. Alle Attribute besitzen einen klassenweit eindeutigen Attributnamen und einen Typ, der im Datenbankschema deklariert und gespeichert sein muss. Um die Effizienz bei einem lokalen Zugriff auf Objekte und ihre Attribute zu erhöhen, werden alle nichtoptionalen Attribute im physischen Speicher sequentiell abgelegt. Die Datenbank-Engine unterstützt im Zusammenhang mit Klassen auch einen einfachen Vererbungsmechanismus. Damit können Superklassen verpflichtende Attribute an abgeleitete Subklassen vererben. Record Header

Pflichtattribut 1

Pflichtattribut 2

Pflichtattribut 3

Optionales Attribut 1

Optionales Attribut 2

Datenstrukturen und Datenmanagement

Attribute

Abb. 9.17: Struktur eines Datensatzes

Ein Attribut kann einen der Basisdatentypen Integer, Float, Text, Time, Date, Unicode, Object Identifier oder BLOB haben. Attribute vom Typ Object Identifier speichern die eindeutige ObjectID eines Datenobjekts. Binary Large Objects (BLOB) dienen als Datentyp für grosse (Multimedia-)Objekte, wobei diese nicht direkt in der mobilen Datenbank, sondern auf separaten Speicherseiten außerhalb der Datenbank gespeichert werden. Die Verwaltung der Speicherseiten wird über ein spezielles Seitenverzeichnis (Page Directory) realisiert, das dann anstelle der BLOBs in der Datenbank gespeichert wird. Der Zugriff auf einen Teil eines BLOBs erfolgt über ein spezielles Mapping-Verfahren, welches direkt auf dem Seitenverzeichnis aufsetzt.

9.5 Tamino Mobile Suite

■ ■ ■

243

Semistrukturierte Daten

Neben strukturierten Daten, die auf einer im Datenbankschema deklarierten Klasse basieren, unterstützt die Tamino Mobile Database auch Daten, zu denen keine korrespondierende Klasse deklariert ist (so genannte semistrukturierte Daten). Damit können Objekte generiert werden, die keinen Typ haben. Allerdings dürfen sie nur optionale Attribute besitzen.

Indizes

Die Tamino Mobile Database bietet die Möglichkeit, Attribute zu indizieren. Indizes werden im Datenbankschema deklariert und auch dort gespeichert. Insgesamt können drei verschiedene Indextypen eingesetzt werden: Einzelattribut-Indizierung, MultiattributIndizierung und Attributgruppen-Indizierung. Die beiden zuerst genannten Indextypen unterstützen lediglich die Indizierung strukturierter Daten, während der zuletzt genannte Indextyp auch auf semistrukturierte Daten angewendet werden kann. Der Attributgruppen-Index ist eine neue Form des Index. Er bezieht sich auf mehrere Attribute, die aber, im Gegensatz zum Multiattribut-Index, nicht alle aus derselben Klasse stammen müssen. Damit ist auch eine klassenübergreifende Indexierung von typgleichen Attributen (bzw. von Attributgruppen) möglich. Ansonsten funktioniert diese Indexform genauso wie der Multiattribut-Index.

AttributgruppenIndex

Abb. 9.18: MultiattributIndex [TAM04]

Datenbankadressen der Objektinstanzen, die die Attributwerte enthalten

Objekt X

V1

V2

V3

Objekt Y

Ein Tupel von Werten für eine spezifische Sequenz von Attributen

Datenzugriff und Anfrageverarbeitung

Der Zugriff auf gespeicherte Daten erfolgt bei der TMDB in drei Schritten. Im ersten Schritt wird die Menge (Kollektion) von Objekten spezifiziert, auf die zugegriffen werden soll. Dies kann auf drei unterschiedliche Arten geschehen: ■

244

■ ■ ■

Variante 1: Die erste Möglichkeit ist die Formulierung einer Query (direkt oder eingebettet in ein Programm).

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

■

Variante 2: Die zweite Möglichkeit ist eine navigierende Bestimmung. Dabei wird durch alle verfügbaren Objekte navigiert und bei Bedarf das aktuell gehaltene Objekt der Kollektion hinzugefügt. Im Falle von mehreren Objekten in einer Kollektion wird für die Auswahl eines bestimmten Objektes ein Cursor verwendet, der als Objekt-Zeiger implementiert ist. Um den Cursor innerhalb einer Kollektion zu bewegen, können spezielle Methoden wie GetFirst oder GetNext verwendet werden. Enthält eine Kollektion lediglich ein Objekt, werden Cursoranweisungen ignoriert. Im letzten Schritt muss jetzt nur noch das gewünschte Attribut des ausgewählten Objekts ausgelesen oder geschrieben werden.

■

Variante 3: Die letzte Möglichkeit, eine Kollektion zu erstellen, besteht darin, für eine Kollektion ein völlig neues Objekt eines bestimmten Typs anzulegen. Die Kollektion enthält in diesem Fall allerdings ausschließlich dieses neue Objekt. Im zweiten (trivialen) Schritt kann jetzt das konkrete Objekt innerhalb der Kollektion ausgewählt werden.

Um Objektattribute auszulesen bzw. zu schreiben kann auf vordefinierte Methoden zurückgegriffen werden. Anfragen werden mit Hilfe von zwei speziellen Funktionsklassen ausgeführt. Beim LookupByClass werden alle Objekte einer einzelnen Klasse zurückgegeben, die das angegebene Selektionskriterium erfüllen. LookupByClass-Anfragen berücksichtigen ausschließlich verpflichtende Attribute. Beim LookupByGroup werden dagegen diejenigen Objekte zurückgegeben, für die das Selektionskriterium, jetzt angewandt auf eine Gruppe von Objekten verschiedener Klassen, auf TRUE evaluiert. Die Ergebnismenge kann also aus Objekten bestehen, die auch auf verschiedenen Klassen basieren können. Das implementierte Transaktionskonzept basiert auf einer einfachen Write-One-Read-Many-Strategie, das heisst, dass vor jeder Schreiboperation zunächst immer alle laufenden Leseoperationen zu Ende gebracht werden müssen. Erst dann kann das entsprechende Datenelement gesperrt und exklusiv geschrieben werden. Das ACID-Prinzip für Transaktionen erfordert jedoch nicht nur die Garantie von Atomizität und Isolation, wie sie der Einbenutzerbetrieb und das exklusive Schreiben schon implizit ermöglichen, auch die Konsistenz und Dauerhaftigkeit der Daten muss gesichert sein. Hierzu verwendet die Tamino Mobile Database über einen abgespeckten Logging-Mechanismus implementiert. Die Tamino Mobile Datenbank wird auf den mobilen Clients typischerweise im Einzelbenutzerbetrieb eingesetzt. Aufgrund dieser

9.5 Tamino Mobile Suite

Auslesen von Attributen

Transaktionskonzept

ACID-Prinzip

■ ■ ■

245

Annahme ist keine Implementierung einer aufwendigen Nebenläufigkeitsverwaltung vorhanden. Konkrete Schedules werden durch strikte Sequentialisierung erreicht und das Datenbanksystem sowie der benötigte Hauptspeicherplatz werden kleiner.

9.5.5 Programmierung Anwendungsentwicklung

Wichtiger Bestandteil der Tamino Mobile Suite ist das Tamino Mobile Studio. Dies ist eine integrierte Entwicklungsumgebung für die Entwicklung mobiler Datenbankanwendungen. Das Tamino Mobile Studio ähnelt in seiner Funktionalität dem Mobile Application Builder von DB2 Everyplace. Der Vorteil bei der Entwicklung von mobilen Anwendungen mit der Tamino Mobile Suite kann gleichzeitig auch als größter Nachteil angesehen werden. Durch die Unterstützung sehr vieler verschiedener Standards (Java, XML, XSL, XHTML, WML, VoiceXML, cHTML, HDML) bekommt der Entwickler eine enorm mächtige Sammlung von Technologien und Programmiersprachen an die Hand, um Anwendungen flexibel konzipieren entwickeln zu können. Gleichzeitig steigt dadurch allerdings auch die Komplexität bei der Entwicklung von Anwendungen stark an. Es erfordert viel Erfahrung und Routine, um diese Komplexität beherrschen zu können.

9.5.6 Zusammenfassung In der Tamino Mobile Suite (TMS) werden von der Software AG Produkte für die Entwicklung XML- und Java-basierter mobiler Datenbankanwendungen zusammengefasst. Kern der angebotenen Produkte ist die Tamino Mobile DB, ein leichtgewichtiges mobiles Datenbanksystem, dessen charakteristische Merkmale vor allem die Unterstützung des XML-Datenmodells bei der Speicherung und Verwaltung von Daten und die Unterstützung bekannter Mechanismen zur Abfragebearbeitung und Indizierung sind. Als ServerDatenbank im Backend wird zwingend der Tamino XML Server vorausgesetzt. Die Anbindung objektrelationaler Datenbanksysteme ist nur indirekt über entsprechende Schnittstellen des Tamino XML Servers möglich. Wie bei der Konkurrenz auch, werden Komponenten zur Synchronisation von Daten und Anwendungen angeboten. Mit dem Tamino Mobile Studio steht eine spezielle Entwicklungsumgebung für die Anwendungsentwicklung bereit. Die Unterstützung extrem vieler Standards und Technologien, wie Java, J2EE,

246

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

XHTML, XML, XSL, VoiceXML oder WAP fördert zwar einerseits die Definition und Verfügbarkeit eines offenen Frameworks, führt andererseits aber zu einer rasch zunehmenden Komplexität bei der Konzeption und Realisierung mobiler Datenbankanwendungen.

9.6 PointBase Micro Bei PointBase Micro (Version 4.7, April 2004) handelt es sich um ein vollständig in Java implementiertes relationales Datenbanksystem, das vor allem für eingebettete und mobile Systeme konzipiert ist, aber auch auf leistungsfähigeren Rechnern eingesetzt werden kann. Im Gegensatz zu den bisherigen Systemen (mit Ausnahme von iAnywhere’s UltraLite), die jeweils ein eigenständiges mobiles Datenbanksystem auf dem Client realisieren, kompiliert PointBase Micro die mobile Datenbank vollständig in das Anwendungsprogramm. PointBase Micro kann sowohl auf der Java 2 Micro Edition (J2ME), als auch auf der Java 2 Standard Edition (J2SE) aufsetzen. Der für J2ME-Anwendungen benötigte Speicherplatzbedarf beträgt dabei weniger als 45 kB. Aus Sicherheitsgründen können ganze Datenbanken verschlüsselt und auch sichere Kommunikationsverbindungen aufgebaut werden. Als Anfragesprache steht eine Untermenge des SQL92-Standards zur Verfügung. Transaktionen werden unterstützt (AUTOCOMMIT, COMMIT, ROLLBACK). Durch einen Synchronisationsframework können mobile Datenbankanwendungen für Offline-Szenarien entwickelt werden, die keine permanente Netzwerkverbindung voraussetzen. Ähnlich wie bei den bereits vorgestellten iAnywhere UltraLiteAnwendungen integriert PointBase Micro Anwendungsdatenbanken zusammen mit der zugehörigen Datenverwaltungsfunktionalität vollständig in eine Java-Anwendung (vgl. Abbildung 9.19). Der Zugriff auf die Datenbank aus der Anwendung heraus erfolgt über JDBC. Als Java-Implementierung setzt PointBase Micro die Existenz einer Java Virtual Machine (JVM) zur Laufzeit voraus. Diese benötigt zusätzlich 200-500 kB an Speicherplatz. Dieser kann jedoch zunehmend vernachlässigt werden, da aktuelle Trends (vor allem bei Mobiltelefonen und PDAs) dahin gehen, eine JVM bereits ab Werk im ROM mobiler Systeme vorzuinstallieren. In diesem Fall nimmt die JVM anderen Anwendungen keinen Speicherplatz weg – zumindest außerhalb des ROMs. PointBase Micro kann auf allen Plattformen eingesetzt werden, die J2ME- oder J2SE-Anwendungen unterstützen. Unterstützte Plattformen sind beispielsweise alle Win32-Betriebssysteme, Pocket

9.6 PointBase Micro

Wichtige Konzepte

Plattformunterstützung

■ ■ ■

247

Editionen

Abb. 9.19: PointBase Micro als eingebettete Datenbank

PC oder auch Symbian (allgemein alle Systeme, für die eine entsprechende JVM verfügbar ist). PointBase Micro ist aktuell in zwei unterschiedlichen Editionen erhältlich: Die Edition CDC/Personal Java Profile ist für den Einsatz auf Windows-basierten J2SE-Systemen, wie Notebooks und Pocket PCs, gedacht. Auch der Sharp Zaurus PDA ist mit einer J2SE-Umgebung ausgestattet und kann diese Edition verwenden. Dagegen ist die Edition CLDC/MIDP Profile für einen Einsatz auf leistungsschwächeren J2ME-basierten mobilen Einheiten, wie Mobiltelefonen, PDAs und Smartphones, gedacht. Java-Anwendung JDBC

PointBase Micro

Java Virtual Machine

Das leichtgewichtige Datenbanksystem PointBase Micro selbst ist wichtiger Bestandteil einer ganzen Produktsuite. Verfügbar ist neben PointBase Micro ein weiteres, ebenfalls vollständig in Java implementiertes, relationales Datenbanksystem für mächtigere J2SE- und J2EE-Umgebungen, PointBase Embedded genannt. Dieses Datenbanksystem unterstützt in seiner Basisversion mehrere parallele Datenbankverbindungen aus einer einzigen virtuellen Maschine heraus. Sollen mehrere parallele Datenbankverbindungen von mehreren virtuellen Maschinen heraus aufgebaut und genutzt werden, kann PointBase Embedded um eine zusätzliche Server-Option ergänzt werden. PointBase Embedded mit aktivierter Server-Option wird als PointBase Server bezeichnet. Mit PointBase UniSync existiert darüber hinaus ein leistungsfähiges Synchronisationsframework, das durch ein intuitiv zu nutzendes API die Durchführung bidirektionaler Synchronisationsprozesse erlaubt. PointBase UniSync implementiert dazu ein auf Snapshots basierendes Publish&Subscribe-Modell.

9.6.1 Architektur der clientseitigen Datenbank-Engine PointBase Micro baut auf einem Mikrokernel auf, der eine offene, stark modulare Architektur realisiert. Über eine proprietäre Schnitt-

248

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

stelle erlaubt PointBase Micro die Integration beliebiger JavaFunktionen in Datenbankanwendungen. Solche nutzerdefinierten Java-Methoden können beispielsweise dazu verwendet werden, SQLSkripte zu definieren. Die Integration nutzerdefinierter JavaFunktionen erfolgt dabei über die Implementierung des nachfolgend abgebildeten Java-Interfaces: public interface Function { public Object process(Object[] parameter); }

Listing 1: Nutzerdefinierte Java-Methode

Die Integration einer neuen nutzerdefinierten Java-Methode erfolgt in zwei Stufen. In einem ersten Schritt muss das Interface aus Listing 1 durch eine Java-Klasse implementiert werden (vgl. Listing 2). Anschließend muss die implementierte Klasse noch in das Datenbankmanagementsystem eingebunden werden public class Quadrat implements Function { public Object process (Object param[]) { int x =((Integer)param[0].intValue(); return new Integer (x*x); } }

Listing 2: Implementierung der nutzerdefinierten Funktion

Um die Methode dann nutzen zu können, muss sie abschließend noch dem System bekannt gemacht werden. Dazu wird eine proprietäre Erweiterung von SQL benutzt (vgl. Listing 3). Listing 3: Einbindung der Funktion

CREATE FUNCTION Quadrat (X INTEGER) RETURNS INTEGER EXTERNAL “test.FunctionQuadrat”;

Jetzt ist die benutzerdefinierte Methode im System verfügbar und kann benutzt werden (vgl. Listing 4): SELECT * FROM TEST WHERE Quadrat(VAL)>9;

Alternative Möglichkeiten, eigene Erweiterungen in das System einzubringen, bietet PointBase Micro nicht mehr an.

9.6 PointBase Micro

Listing 4: Gebrauch der Funktion

■ ■ ■

249

9.6.2 Replikation und Synchronisation

PointBase UniSync

Abb. 9.20: Integration des UniSync-API [nach PBM04]

Datenquellen, die bei PointBase Micro an Synchronisationsprozessen beteiligt sind, werden als SyncDataSources bezeichnet. Replikation wird als ein unidirektionaler Synchronisationsprozess verstanden und wird deswegen nicht gesondert untersucht. Die Synchronisation greift auf die beiden Transportprotokolle TCP/IP und HTTP zurück. Kern des Synchronisationsframeworks ist das UniSync API, das direkt aus Java-Anwendungen heraus angesprochen werden kann und logisch betrachtet als Schicht zwischen Java-Anwendung und JDBC API konzipiert ist (vgl. Abbildung 9.20). Die zu synchronisierenden Datenquellen können beliebige relationale Datenbanken (auch verschiedener Hersteller) sein, sie müssen lediglich eine JDBC-Schnittstelle anbieten. So können beispielsweise die objektrelationalen Datenbanksysteme IBM DB2, Microsoft SQL Server oder Oracle 10g als zentrale Synchronisationsquellen im Backend eingesetzt werden. Java-Anwendung UniSync API

Sync DataSource

JDBC API

Publish & Subscribe

Hubs

250

■ ■ ■

Das grundlegende Funktionsprinzip des PointBase Micro-Synchronisationsverfahrens basiert auf einem Publish&Subscribe-Modell. Dieses Modell (vgl. Kapitel 4) sieht vor, dass sich Anwendungen mobiler Clients auf einem Synchronisationsserver, der einer oder mehrerer Backend-Datenbanken vorgeschalten ist, für Synchronisationsdienste eintragen müssen. Dazu muss jede Anwendung eine oder mehrere Subscriptions für bestimmte, serverseitig verfügbare Daten definieren. Die serverseitig verfügbaren öffentlichen Daten werden als Published Data bezeichnet. Diesbezüglich verfolgt PointBase Micro eine ähnliche Strategie wie beispielsweise auch Oracle 10g Lite oder andere mobile Datenbanksysteme, deren Synchronisationsmechanismus ebenfalls durch ein Publish&SubscribeModell beschrieben wird. Wichtigste Synchronisationskomponente der Publish-Seite einer Synchronisationsarchitektur ist ein so genannter Hub, der eine Instanz der UniSync-Klasse HUB ist und auf einem fest definierten Port auf Synchronisationsanforderungen mobiler Clients wartet. Wichtigster Bestandteil eines Hubs ist der Synchronisationsserver, der in

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

unterschiedlichen Architekturvarianten realisiert sein kann (vgl. Abbildung 9.21). So kann er entweder als Stand-Alone Komponente (Stand Alone Mode) oder innerhalb eines Servlet-Containers (J2EE Application Server Mode) ausgeführt werden. Demgegenüber stehen auf der Seite des Clients die so genannten Spokes, die als Instanz der UniSync-Klasse SPOKE für die Initialisierung von Synchronisationsvorgängen und die clientseitige Koordination der Synchronisation zuständig sind. Hubs und Spokes sind zusammen für die Ausführung aller Synchronisationsprozesse verantwortlich. Administriert werden Synchronisationsprozesse durch eine Instanz der Klasse SyncManager, die unter anderem Methoden für das Anlegen von Hub- und Spoke-Objekten, aber auch zum Definieren von UniSync-Datenquellen bereitstellt. Jeder Hub ist mit einer oder mehreren Datenquellen verknüpft, deren Daten die Synchronisationsobjekte sind. Auch ein Spoke ist immer mit einer oder mehreren Datenquellen verbunden. Dabei ist die maximale Anzahl der an einen Spoke anknüpfbaren Datenquellen allerdings durch die darunter liegende Java-Plattform bestimmt. Können bei J2SE oder J2EE beliebig viele Datenquellen angeknüpft werden, muss man sich bei J2ME auf eine Datenquelle beschränken. Im Gegensatz zu einem Hub muss sich ein Spoke für die von einem Hub zur Synchronisation angeboten Daten registrieren. Eine Subscription ist im Kontext von PointBase Micro ein Objekt, das mit einem Spoke verknüpft ist und sich auf eine bestimmte Publikation eines Hubs bezieht. Das UniSync API zur Programmierung von Synchronisationsmechanismen gliedert sich in zwei Teile. Während der erste Teil für die Konfiguration der Synchronisation zuständig ist, betrifft der zweite Teil die Koordination der Synchronisation zur Laufzeit. Das Konfigurations-API besteht aus Klassen und Methoden, mit denen Hubs, Spokes, Datenquellen, Publikationen und Subscriptions angelegt und verwaltet, sowie die Konflikterkennung und -lösung koordiniert werden können. Das Laufzeit-API besteht demgegenüber aus Klassen und Methoden, mit denen konkrete Synchronisationsprozesse angestoßen und durchgeführt werden können. Die UniSync Console ist ein GUI-Tool, das eine einfache Administration von im Zusammenhang mit dem Aufbau einer Synchronisationsarchitektur notwendigen Verwaltungsaufgaben erlaubt. Intern basiert das PointBase Micro-Synchronisationsverfahren auf Snapshots. Ein Snapshot ist definiert als die vollständige Kopie eines bestimmten Datenelementes zu einem bestimmten, diskreten Zeitpunkt. Daten, die seit der letzten Synchronisation eine Änderung erfahren haben, werden als PointUpdate bezeichnet. PointUpdates treten sowohl client- als auch serverseitig auf. Ein Spoke kann über die

9.6 PointBase Micro

Spokes

Synchronisationsobjekte

Struktur des UniSync API

UniSync Console

■ ■ ■

251

Methode getPointUpdate() alle diejenigen geänderten Daten eines Hubs anfordern, für die der Hub eine entsprechende Subscription inklusive der erforderlichen Zugriffsberechtigungen besitzt. Gleichzeitig kann ein Spoke über die Methode putPointUpdate() selbst geänderte Daten an einen Hub senden, der diese Änderungen auf den eigenen Datenquellen nachführt. Typischerweise stoßen Spokes zunächst immer eine putUpdatePoint()-Operation, danach eine getPointUpdate()-Operation an. Auf diese Weise wird ein bidirektionaler Synchronisationsprozess durchgeführt. Abb. 9.21: Einsatzszenarien eines Hubs [PBM04]

HUB (Stand-Alone-Mode) Synchronisationsserver (UniSync Server)

DB

HTTP Server

zum SPOKE

HUB (J2EE Application Server) Applikationsserver Synchronisationsserver (UniSync Server)

DB

Servlet HTTP Server

zum SPOKE

Abb. 9.22: Zusammenspiel von Hub und Spoke

252

■ ■ ■

Hub Publication

Spoke SYNC

Subscription

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

9.6.3 Implementierungskonzepte PointBase Micro unterstützt sowohl nutzerdefinierte, gespeicherte Funktionen (Stored Functions), als auch nutzerdefinierte, gespeicherte Prozeduren (Stored Procedures). Nutzerdefinierte Funktionen können notwendige Konvertierungen von Daten vornehmen und liefern immer nur einen einzigen Wert zurück. Eine nutzerdefinierte Funktion wird durch den Aufruf von CreateFunction definiert. Bei ihrer Aktivierung wird eine externe Java-Methode aufgerufen, die die nutzerdefinierte Funktion implementiert. Im Gegensatz zu den nutzerdefinierten Prozeduren können nutzerdefinierte Funktionen auch direkt in statische SQL-Anfragen eingesetzt werden, da ja immer nur ein einzelner Wert zurückgegeben wird. Auch die nutzerdefinierten Prozeduren werden über externe JavaMethoden implementiert. Der Unterschied besteht darin, dass eine nutzerdefinierte Prozedur beliebig viele Input- und OutputParameter besitzen kann, das heisst es kann nicht nur ein Wert, sondern auch mehrere Werte zurückgegeben werden. Nutzerdefinierte Prozeduren werden über einen speziellen CALL-Befehl aufgerufen. Dieser ähnelt in seiner Wirkung einem Trigger.

Nutzerdefinierte Prozeduren

Abb. 9.23: Hierarchischer Aufbau einer PointBase Micro-DB

User

Datenbank

Nutzerdefinierte Funktionen

Schema

Tabelle Tabellenspalten

View

Das Zusammenspiel zwischen den verschiedenen Basisobjekten der PointBase-Datenbank-Engine verdeutlicht Abbildung 9.23. Entscheidend ist dabei die Vorstellung, dass eine Datenbank nichts anderes als ein Objekt ist, das andere Objekte wie Tabellen oder Schemata umschließt. Damit wird eine Hierarchie definiert, deren unterste Ebene die einzelnen Attribute eines Datensatzes sind. Eine

9.6 PointBase Micro

DatenbankEngine

■ ■ ■

253

Datenbank-Engine kann eine, aber auch mehrere Datenbanken hosten. Verschiedene Anwendungen greifen immer auch auf unterschiedliche Datenbanken zu. Der Wechsel zwischen Anwendungen führt durch das ständige Öffnen und anschließende Schließen von Datenbankverbindungen deswegen zu einem erheblichen Overhead. Um diesen Overhead zu vermeiden, können mit Hilfe von Datenbankschemata verschiedene logische Datenbanken innerhalb einer einzelnen physischen Datenbank angelegt und verwaltet werden.

9.6.4 Programmierung Anwendungsentwicklung in Java

Entwicklungsumgebungen

Datenbankzugriff

254

■ ■ ■

Da es sich bei PointBase Micro um ein vollständig in Java realisiertes Datenbanksystem handelt, dessen Programmierschnittstellen ebenfalls alle als Java-Bibliotheken implementiert sind, erfolgt die Entwicklung mobiler Datenbankanwendungen logischerweise ebenfalls in Java. Eine spezielle Entwicklungsumgebung für die Entwicklung mit PointBase Micro existiert nicht. Aufgrund der immensen Vielfalt existierender Java-Entwicklungsumgebungen (gerade auch für die Entwicklung mobiler Anwendungen), stellt dies jedoch kein sonderlich großes Problem dar. So reichen ein einfacher Texteditor und ein Java-Compiler dazu aus, lauffähige Anwendungen zu erstellen. Alternativ kann aber auf beliebige Java-Entwicklungsumgebungen zurückgegriffen werden. Aktuell empfehlen sich Eclipse oder das Sun ONE Studio (Mobile Edition). Die Programmierung einer mobilen Datenbankanwendung mit PointBase Micro entspricht in weiten Teilen der Programmierung gewöhnlicher J2ME-Anwendungen. Lediglich die zusätzliche Datenbankfunktionalität muss über die PointBase Micro-APIs hinzugefügt werden. Die entsprechenden Programmierschnittstellen sind jedoch intuitiv verständlich und leicht einzusetzen. In Kapitel 10 wird die Implementierung einer Beispielanwendung mit PointBase Micro vorgestellt. Nachfolgend wird beschrieben, wie aus einer Anwendung heraus ein Datenbankzugriff erfolgen kann. Um eine Verbindung zu einer Datenbank aufzubauen, muss der JDBC-Treiber (com.pointbase. jdbc.jdbcUniversalDriver) geladen werden. Darüber hinaus müssen der Datenbankname (in Form einer URL) sowie optional ein Benutzername mit einem ebenfalls optionalen Passwort angegeben werden (der Default-Wert der beiden optionalen Parameter ist PUBLIC). Die eine Datenbank spezifizierende URL ist bei den verschiedenen PointBase-Datenbanken (PointBase Micro, PointBase

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Embedded, PointBase Server) unterschiedlich. Existiert die Datenbank, auf die zugegriffen werden soll noch nicht, wird unter dem angegebenen Datenbanknamen eine neue Datenbank angelegt. Wird explizit eine neue Datenbank angelegt, die den gleichen Namen wie eine bereits existierende Datenbank besitzt, wird die existierende Datenbank ohne Nachfrage überschrieben. Nach dem Öffnen einer Verbindung zu einer Datenbank können sofort SQL-Anfragen abgesetzt werden. Ergebnisse werden in Form eines java.sql.resultSet-Objekts zurückgeliefert, die in sequentieller Reihenfolge mit der Methode next() durchlaufen werden können. Ein wahlfreier Zugriff auf einzelne Ergebniselemente ist nicht möglich. Um einzelne Werte aus dem ResultSet auslesen und weiterverarbeiten zu können, stehen Methoden wie getInteger() oder getBoolean() zur Verfügung. Sind keine weiteren Datenbankoperationen mehr erforderlich, müssen das JDBC-Statement und die Datenbankverbindung wieder geschlossen werden. PointBase Micro unterstützt dabei nicht nur statische SQLAnfragen. Auch dynamische SQL-Anfragen, die auf vorbereiteten Anfragen mit dynamisch festlegbaren Parametern basieren, sind möglich. In diesem Fall sind ein wahlfreier Zugriff auf Ergebniselemente und ausgefeilte Navigationsmöglichkeiten möglich. Verschiedene Hilfsmethoden erlauben die Extraktion zusätzlicher Metainformationen über zurück gelieferte ResultSet-Objekte.

Datenverarbeitung

Dynamisches SQL

9.6.5 Zusammenfassung Bei PointBase Micro handelt es sich um ein mobiles Datenbanksystem, das nur zusammen mit Java-Anwendungen eingesetzt werden kann. Einzige Voraussetzung ist somit eine installierte Java Virtual Machine. Durch die dadurch gewonnene Plattformunabhängigkeit und die Unterstützung der JDBC-Programmierschnittstelle für einen einfachen Zugriff auf relationale Datenbanken lässt sich PointBase Micro auf einfache und intuitive Weise verwenden und programmieren. Das Datenbanksystem beinhaltet Stored Procedures, Transaktionen und einen einfach zu programmierenden Synchronisationsmechanismus für den Abgleich verschiedener Datenquellen. Bei der Anwendungsentwicklung ist der Entwickler auf die Programmiersprache Java festgelegt. Aufgrund der im Vergleich zu anderen Konkurrenten sehr günstigen Lizenzkosten und der trotzdem gegebenen Funktionalität eignet sich dieses mobile Datenbanksystem vor allem für einen Einsatz in Projekten mittlerer Größe, bei de-

9.6 PointBase Micro

■ ■ ■

255

nen eine flexible Programmierung und die Anbindung an bestehende J2EE-Infrastrukturen eine wichtige Anforderung darstellen.

9.7 Microsoft SQL Server 2000 CE Edition Für das von Microsoft entwickelte Datenbanksystem SQL Server 2000 existiert seit geraumer Zeit ebenfalls ein leichtgewichtiger Ableger für den Einsatz auf leistungsschwachen mobilen Geräten: die SQL Server 2000 CE Edition (im Folgenden einfach als SQL Server CE bezeichnet. Aktuell ist Version 2.0 (April 2004). Als Betriebssystem auf den mobilen Clients wird Windows CE bzw. einer seiner Nachfolger vorausgesetzt (Pocket PC, Windows Mobile 2003). Eine Installation des Datenbanksystems erfordert auf den mobilen Clients zwischen 1 MB und 3 MB an Speicherplatz. Im Backend muss als Datenbanksystem der SQL Server 2000 (Service Pack 1) oder der SQL Server 7.0 (Service Pack 3) eingesetzt werden. Wird auf die ältere Version 7.0 des SQL-Servers zurückgegriffen, können einige Features nicht genutzt werden.

9.7.1 Komponenten Komponenten für den Aufbau einer mobilen Infrastruktur

256

■ ■ ■

Wie bei den anderen Systemen besteht auch eine mobile Anwendung in der der SQL Server CE eingesetzt wird, aus mehreren Komponenten: ■

SQL Server. Beim SQL-Server handelt es sich um den zentralen Datenbankserver im Backend, dessen Daten auf die mobilen Clients repliziert werden.

■

SQL Server CE. Dies ist das mobile Datenbanksystem auf dem mobilen Client.

■

ActiveSync. Bei ActiveSync handelt es sich um die Komponente, die für die Installation von Anwendungen auf mobilen Clients und für das Debugging während der Anwendungsentwicklung verwendet werden kann. Darüber hinaus koordiniert diese Komponente den gesamten Kommunikationsverkehr zwischen mobilem Client und Backend, beispielsweise also auch die Kommunikation während einer Synchronisationssitzung. Als Übertragungsmedium zwischen mobilem Client und Backend kann auf eine Infrarot-, eine serielle oder eine USB-

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Schnittstelle zurückgegriffen werden. Ältere Betriebssysteme unterstützen noch das komplizierte SQL Server CE Relay. ■

Internet Information Server (IIS). Die Internet Information Services realisieren die Funktionalität eines gewöhnlichen Webservers, werden aber für die (nachrichtenbasierte) Replikation benötigt. Implementiert werden die IIS durch den Internet Information Server, der ebenfalls mit IIS abgekürzt wird.

■

Entwicklungsumgebung. Die Entwicklungsumgebung besteht je nach Zielplattform aus dem Visual Studio .NET oder den eMbedded Visual Tools. Alle Entwicklungstools müssen auf demselben Entwicklungssystem installiert sein. Die Verwendung der eMbedded Visual Tools erfordert zusätzlich die Installation von einem der folgenden Software Development Kits: Handheld PC 2000 SDK, Pocket PC SDK, Windows Powered Pocket PC 2002 SDK.

Die mobile Umgebung kann auf zwei verschiedene Arten konfiguriert werden. Als Single-Server-Environment befinden sich alle Backend-Systeme (SQL Server und IIS) auf dem gleichen Rechner. In einer Multiple-Server-Environment verteilt sich die Funktionalität dagegen auf mehrere Rechner.

Serverseitige Umgebung

9.7.2 Architektur der clientseitigen Datenbank-Engine SQL Server CE besteht aus zwei Komponenten, der mobilen Datenbank-Engine und dem Client Agent: ■

Database-Engine. Die Datenbank-Engine ist für die Verwaltung und Speicherung der Daten auf dem mobilen Client zuständig. Um alle Datenoperationen zu dokumentieren, wird zusammen mit jedem Datensatz eine Change Tracking Information gespeichert. Über die Architektur der Datenbank-Engine sind von Microsoft leider keine Informationen verfügbar.

■

Client Agent. Der Client Agent ist auf dem mobilen Client für das Herstellen von Verbindungen zur zentralen Datenbank und das Versenden von Abfragen verantwortlich. Er besteht aus drei Objekten: dem Replikations-Objekt, dem Remote Data AccessObjekt (RDA) und dem Engine-Objekt. Das Zusammenspiel dieser drei Objekte ermöglicht eine kontrollierte Steuerung von Verbindungen zum zentralen Datenbankserver.

9.7 Microsoft SQL Server 2000 CE Edition

Clientseitige Umgebung

■ ■ ■

257

Serverseitige Umgebung

Diesen beiden wichtigsten clientseitigen Komponenten stehen serverseitig der Internet Information Server und der SQL Server 2000 gegenüber. Der IIS hostet dabei den Server Agent. ■

Sicherheit

Abb. 9.24: SQL Server CE Architektur

Server Agent. Der Server Agent ist die Komponente, die für den Empfang von Anfragen mobiler Clients zuständig ist. Er ist ein Modul des IIS. Möchte eine mobile Datenbankanwendung eine Anfrage an die zentrale Datenbank absetzen, wird diese Anfrage vom Client Agent in einem HTTP-Request gekapselt, der dem Server Agent übermittelt wird. Der Server Agent übergibt eine erhaltene Anfrage anschließend dem SQL Server, wartet auf das Resultat der Anfrage und leitet dieses nach Erhalt an den mobilen Client weiter.

Sämtliche Verbindungen zwischen Client Agent und Server Agent setzen auf HTTP auf. Ausgetauschte Daten zwischen Server und Client können über Secure Socket Layer (SSL) verschlüsselt werden. Mobiler Client

Backend-Server

Anwendung Client Agent

IIS Active Sync

Server Agent

DB-Engine

DB-Engine

SQL Server CE

SQL Server

9.7.3 Replikation und Synchronisation

Mergereplikation

258

■ ■ ■

Der SQL Server CE stellt zwei verschiedene Mechanismen für die Replikation und die Synchronisation bereit: die Mergereplikation und die nachrichtenbasierte Internetreplikation. Microsoft spricht also von Replikations- und nicht von Synchronisationsverfahren. Die Mergereplikation basiert auf einem Publish&Subscribe-Modell. Dazu werden zunächst auf einem zentralen SQL Server 2000 Publikationen erstellt, die aus einer beliebigen Anzahl von Artikeln (beispielsweise einzelnen Tabellen) bestehen. Mobile Clients können solche Publikationen über Subskriptionen abonnieren. Dazu

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

muss einzig ein Replikationsobjekt, das eine bestimmte Publikation bzw. eine Menge an Publikationen kapselt, aufgerufen werden. Flexibilität wird durch horizontale und vertikale Filter erreicht, die definiert werden können. Horizontale Filter schränken die zu replizierenden Tupel einer Tabelle ein, während vertikale Filter die Formulierung von Replikationsbedingungen für die Spalten einer zu replizierenden Tabelle ermöglichen. Mit der nachrichtenbasierten Internetreplikation existiert ein zweites Replikationsverfahren, das eine HTTP-Verbindung nutzt, die über den Internet Information Server (IIS) hergestellt wird. Durch den Einsatz von Komprimierungsverfahren kann die zu übertragende Datenmenge im Vergleich zur Mergereplikation deutlich reduziert werden.

Filter

Nachrichtenbasierte Replikation

9.7.4 Implementierungskonzepte Intern verwendet der SQL Server CE temporäre Datenbanken. Diese werden ■

zur Speicherung von Zwischenergebnissen von Anfragen,

■

zur temporären Speicherung von sortierten Zwischenergebnistabellen bei Anfragen mit ORDER BY-Klauseln und

■

zur Speicherung von Speicherseiten, die zwar noch Bestandteil einer offenen Transaktion sind, sich aber nicht länger im SQL Server CE Buffer-Cache befinden,

Temporäre Datenbanken

verwendet. Temporäre Datenbanken werden mit dem Start der Datenbank-Engine initialisiert und angelegt und beim normalen Herunterfahren der Datenbank auch wieder gelöscht. Kommt es zu einem Systemabsturz müssen zurückgebliebene temporäre Datenbank-Dateien von Hand gelöscht werden. Temporäre Datenbanken können mitunter einer sehr starken Wachstumsdynamik unterliegen (insbesondere bei UPDATE- und DELETEStatements, bei expliziten Transaktionen und vor allem bei Sortieroperationen). Zunächst wird bei der Ausführung respektive der Speicherung von Zwischenergebnissen stets auf einen Buffer-Cache zurückgegriffen. Ist dessen maximale Kapazität jedoch erreicht, werden die Daten in temporären Datenbanken abgelegt. Der Größe dieser temporären Datenbanken wird dabei nur durch den verfügbaren Speicherplatz auf dem mobilen Client eine Ober-

9.7 Microsoft SQL Server 2000 CE Edition

■ ■ ■

259

grenze gesetzt. Wird das vorgegebene Limit erreicht, kann eine Datenbank-Anwendung nicht länger ausgeführt werden. Um dies zu verhindern, kann dann auf eine externe Speicherkarte ausgewichen werden. Dies gestattet es, größere Bereiche des intern verfügbaren RAM-Speichers für andere, wichtigere Aufgaben freizuhalten. Doch muss der genaue Speicherort temporärer Datenbanken immer vor der Initialisierung der Datenbank-Engine angegeben werden. Nachträgliche Anpassungen zur Laufzeit sind nicht mehr möglich.

9.7.5 Programmierung Entwicklungsumgebungen

Datenbankzugriff

Compacting Process

260

■ ■ ■

Der SQL Server CE unterstützt zwei verschiedene Entwicklungsumgebungen: die älteren eMbedded Visual Tools und das neuere Visual Studio .NET. Mit den eMbedded Visual Tools können Anwendungen mit den Programmiersprachen C++ und Visual Basic entwickelt werden. Um mit dem Visual Studio .NET mobile Datenbankanwendungen zu entwickeln, muss zusätzlich zur eigentlichen Entwicklungsumgebung das .NET Compact Framework installiert werden. Um eine Datenbank anzulegen, kann auf drei verschiedene Methoden zurückgegriffen werden. Bei der ersten Methode wird mit Hilfe der Microsoft ActiveX Data Objects Extensions for Data Definition Language (DDL) and Security (ADOXCE) eine Datenbank mit Hilfe eines so genannten Catalog-Elements angelegt. Diesem Element muss ein OLE DB-Verbindungsname (Connection String) übergeben werden. Einer Datenbank kann dabei ein Local Identifier (LCID) zugeordnet werden. Wird darauf verzichtet, wird ein Default-Identifier generiert. Die zweite Methode stützt sich auf das Tool OLE DB Provider for SQL Server CE, das über das Interface IDBDataSourceAdmin das Anlegen und Verwalten von Datenbanken ermöglicht. Als dritte und letzte Möglichkeit kann eine neue Datenbank über die AddSubscription-Methode eines Replication-Objektes und dessen Methode CREATE_DATABASE (eMbedded Visual Tools) bzw. CreateDatabase (Visual Studio .NET) angelegt werden. Da die interne Struktur einer Datenbank im Laufe der Zeit eine starke Fragmentierung erfährt, ist es bei Microsoft notwendig, von Zeit zu Zeit einen Defragmentierungsprozess (Compacting Process) auf dem Client auszuführen. Dabei werden verschiedene Routineaufgaben abgearbeitet, beispielsweise die Reorganisation von Speicherseiten von Tabellen oder die Regeneration von Tabellenstatisti-

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

ken, die im Zusammenhang mit der durchgeführten Anfrageoptimierung eine Rolle spielen.

9.7.6 Zusammenfassung Bei dem Microsoft SQL Server CE handelt es sich um ein relativ ausgereiftes Produkt, bei dem jedoch durchaus noch Verbesserungspotential zu identifizieren ist, insbesondere, was die Automatisierung von Replikation, Synchronisation und einfachen Administrationsaufgaben anbelangt. Bezüglich der Anwendungsentwicklung bestehen dagegen kaum Defizite. Insbesondere bei Einsatz des Visual Studio .NETs ist eine schnelle und einfache Entwicklung mobiler Datenbankanwendungen möglich. Was die Wahl einer Programmiersprache anbelangt sind dem Entwickler insbesondere bei .NET dagegen kaum Schranken auferlegt. Nachteilig erweist sich jedoch, dass eigene Plattformen stark bevorzugt werden.

9.8 Eingebettete (Java-SQL)-Datenbanken Im Folgenden werden drei weitere Datenbanksysteme kurz vorgestellt, die sich aufgrund ihrer geringen Größe ebenfalls für einen Einsatz auf mobilen Systemen eignen. Bei eXtremeDB, Hypersonic SQL Database und InstantDB handelt es sich weniger um eine mobile, als vielmehr um eingebettete Datenbanken, die aufgrund ihrer Größe allerdings auch auf mobilen Clients eingesetzt werden können. eXtremeDB ist in C, Hypersonic SQL Database und InstantDB sind in Java implementiert. Darüber hinaus existieren weitere eingebettete Datenbanksysteme, wie z.B. Cloudscape oder JData Store, auf die wir hier nicht weiter eingehen, da sie bereits einen wesentlich größeren Speicherplatzbedarf für eine Installation benötigen und damit keine mobilen Small-Footprint-Datenbanksysteme im engeren Sinn mehr sind. Java-SQL-Datenbanken eignen sich aufgrund ihrer Kompaktheit vor allem für Embedded-Szenarien, das heisst für einen Einsatz zusammen mit Systemen, in denen der verfügbare ROM- und RAMSpeicher sehr knapp ausfällt. Hinzu kommt, dass sie zumeist eine sehr einfache Architektur realisieren, die einen nur geringen Administrationsaufwand mit sich bringen. Java-SQL-Datenbanken eignen sich insbesondere für einen gemeinsamen Einsatz mit Java-Anwendungen, die Daten in tabellari-

9.8 Eingebettete (Java-SQL)-Datenbanken

Java-SQLDatenbanken

■ ■ ■

261

scher Form abspeichern und auch Abfragen auf diesen Daten absetzen wollen, ohne dazu ein eigenes Datenbanksystem zu installieren.

9.8.1 eXtremeDB

Plattformunterstützung

Datenbanksystemfunktionalität

Implementierungskonzepte

262

■ ■ ■

Bei eXtremeDB handelt es sich um ein objektorientiertes Datenbankmanagementsystem (Version 1.2, April 2004). Um ein Maximum an Performanz vor allem auf leistungsschwachen eingebetteten (mobilen) Systemen zu erreichen, verzichtet eXtremeDB auf die Bereitstellung einer SQL-konformen, anwenderfreundlichen Schnittstelle. Stattdessen wird ein proprietäres objektorientiertes C++-API bereitgestellt, wodurch die Kompatibilität mit Datenbankanwendungen anderer Systeme verhindert wird. eXtremeDB ist für viele verschiedene Plattformen verfügbar. Darunter befinden sich Win32, Pocket PC, Linux, Wind River Systems’ VxWorks/Tornado und QNX Neutrino. Eine einer Anwendung zugeordnete Datenbank wird, ähnlich wie beim bereits vorgestellten PointBase Micro, immer vollständig mit der Anwendung zusammenkompiliert. Auf eine Datenbank kann so immer nur von einer einzigen Host-Anwendung zugegriffen werden. Die gewünschte Datenbankfunktionalität wird unter Verwendung einer proprietären Data Definition Language (DDL) formuliert und anschließend durch einen Compiler in Funktionsprototypen übersetzt. Diese Funktionsprototypen lassen sich anschließend in eine Anwendung integrieren. Abhängig vom eingesetzten Compiler und Prozessor beträgt der von eXtremeDB belegte Speicherplatz weniger als 100 kB. Als reine Hauptspeicherdatenbank (In-Memory Database) für eingebettete Systeme konzipiert, wird der Performanzverlust vermieden, der bei intensiven Sekundärspeicher-Zugriffen auftritt. Obwohl dieses Datenbanksystem ursprünglich nicht für einen Einsatz in mobilen Umgebungen konzipiert wurde, kann es trotzdem dort eingesetzt werden. Anwendungsdaten werden exakt in der Form gespeichert, in der sie von einer Anwendung vorgegeben werden. Dies verhindert zwar einerseits datenbankseitige Operationen, wie beispielsweise Trigger, ermöglicht aber gleichzeitig einen immensen Zuwachs an Performanz. Sowohl die Datenobjekte als auch die auf den Datenobjekten arbeitende Anwendung befinden sich im gleichen Adressraum. Dadurch können Anwendungen direkt auf Datenobjekte zugreifen und mit diesen arbeiten, ohne dass die zugegriffenen Objekte auf dem Client zwischen verschiedenen Adressräumen hin und her kopiert werden müssen. Die Integrität der Daten wird durch ein ACID-

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

konformes Transaktionsmanagement garantiert. eXtremeDB unterstützt viele Datentypen, darunter Arrays, Vektoren und auch BLOBs. Um Anfragen und Sortieroperationen zu beschleunigen, werden sowohl hashbasierte Indexstrukturen als auch B-BaumIndexe bereitgestellt. Die maximale Anzahl von Indizes beträgt 216. Um eXtremeDB auf andere Plattformen zu portieren, kann der Quellcode modifiziert und an eigene Wünsche angepasst werden.

9.8.2 Hypersonic SQL Database Bei der Hypersonic SQL Database (kurz hSQLDB) handelt es sich um ein relationales Datenbanksystem, das vollständig in Java implementiert ist. Die Software kann sowohl als ServerDatenbanksystem, als auch als Embedded-Datenbank eingesetzt werden. hSQLDB ist ein Opensource-Projekt, das mit einer BSDähnlichen, eigenen Lizenz kostenlos nutzbar ist. Das Ziel ist es, eine besonders leichtgewichtige Datenbankumgebung zu realisieren. So hat der hSQLDB-Download lediglich eine Größe von 576 kB. Die aktuelle Version 1.7.1 (April 2004) kann über SourceForge24 heruntergeladen werden. Die Datenbank-Engine ist in einem einzelnen Java-Archiv (hsqldb.jar) gekapselt und besitzt eine Größe von 247 kB. Um hSQLDB zu installieren, müssen lediglich die drei folgenden Schritte ausgeführt werden: ■

Eintragung von hsqldb.jar in den Java-Klassenpfad.

■

Anlegen eines leeren Arbeitsverzeichnisses für die Datenbank.

■

Ausführung des nachfolgend abgebildeten Beispiel-CodeFragments

import java.sql.*; import java.util.logging.*;

Opensource

Anlegen einer einfachen Adressdatenbank

public class UseHSQLDB { static Logger log = Logger.getLogger(de.myname.UseHSQLDB); public static void main(String[] args) throws SQLException, ClassNotFoundException { log.log(Level.INFO, JDBC-Treiber laden... ); 24

http://www.sourceforge.net

9.8 Eingebettete (Java-SQL)-Datenbanken

■ ■ ■

263

Class.forName(org.hsqldb.jdbcDriver); log.log(Level.INFO, JDBC-Treiber geladen!); Connection con = DriverManager.getConnection (jdbc:hsqldb:C:/arbeitsverzeichnis/adress_db,sa,); log.log(Level.INFO, Verbindung hergestellt!); Statement stmt = con.createStatement(); String sqlQuery = CREATE TABLE adressen (ID INTEGER, Name CHAR(20), Ort CHAR(20));; ResultSet rs = stmt.executeQuery(sqlQuery); sqlQuery = INSERT INTO adressen VALUES (1,'Mutschler','Ulm'); rs = stmt.executeQuery(sqlQuery); sqlQuery = INSERT INTO adressen VALUES (2,'Specht','Muenchen'); rs = stmt.executeQuery(sqlQuery); sqlQuery = UPDATE adressen SET Ort='Ulm' WHERE ID=2; rs = stmt.executeQuery(sqlQuery); sqlQuery = SELECT * FROM adressen; rs = stmt.executeQuery(sqlQuery); System.out.println(Adresse-DB); int counter = 0; while (rs.next()) { System.out.println(counter++ +.Datensatz:); int ID = rs.getInt(ID); System.out.println(\t[ID -> + ID + ]); String Name = rs.getString(Name); System.out.println(\t[Name -> + Name + ]); String Ort = rs.getString(Ort); System.out.println(\t[Ort -> + Ort + ]\n); } con.close(); }

264

■ ■ ■

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Das abgebildete Code-Fragment zeigt exemplarisch das Anlegen einer sehr einfachen Adressdatenbank und das anschließende Schreiben, Ändern und Auslesen von Daten. Interessant an dem Beispiel ist vor allem, dass explizit keine Einrichtung einer Datenbank durchgeführt wurde. Die Gründe dafür sind einfach. Wird eine Verbindung zu der angegeben Datenbank (über den Datenbank-Namen) aufgebaut und existiert die angesprochene Datenbank noch nicht, wird diese automatisch angelegt und initialisiert. Dadurch können im weiteren Verlauf der DatenbankVerbindung unmittelbar beliebige Statements ausgeführt werden, da getConnection() bei korrektem Pfad oder bei noch nicht existierender Datenbank immer erfolgreich durchgeführt wird. hSQLDB unterstützt verschiedene Anwendungsarchitekturen. So kann es als reines Hauptspeicher-Datenbanksystem genauso eingesetzt werden, wie als lokale Datenbank für eigenständige Anwendungen. Mit dem oben angeführten Code wird beispielsweise eine In-Process-Arbeitsweise umgesetzt, bei der Anwendung und Datenbank auf der gleichen virtuellen Maschine zur Ausführung gebracht werden. Dazu werden alle Daten direkt in den Hauptspeicher geschrieben, was zur Konsequenz hat, dass alle Daten beim Beenden einer Anwendung verloren gehen. Daneben werden aber auch klassische Client/Server-Anwendungsszenarien wie auch browserbasierte Datenbankzugriffe über einen integrierten Mini-Webserver unterstützt. Als Anfragesprache unterstützt hSQLDB eine Untermenge von SQL92. So fehlen beispielsweise das HAVING-Konstrukt, aber auch Views und referentielle Integrität. SQL92-Datentypen werden dagegen weitgehend bereitgestellt (bis auf den Datentyp INTERVAL). Stored Procedures werden unterstützt. Eine Besonderheit bildet der so genannte Datenbankmanager (Klasse org.hsqldb.util.databaseManager), über den eine einfache Administration der Datenbanken erfolgen kann. Einzige Voraussetzung ist die Verfügbarkeit des korrekten JDBC-Treibers und die Kenntnis der Datenbank-URL. Der Datenbankmanager selbst kann als Applet oder auch als StandAlone-Swing-Applikation ausgeführt werden. Über sein Hauptfenster sind zudem beliebige (unterstützte) SQL-Statements absetzbar. Der Zugriff auf die hSQLDB-Datenbank erfolgt ausschließlich mittels JDBC. Dazu müssen der richtige JDBC-Treiber (org.hsqldb.jdbcDriver) zusammen mit dem gewünschten DatenbankNamen (formuliert als Datenbank-URL) (jdbc:hsqldb:dbname) bekannt sein. Als Ergebnis des Aufbaus einer Verbindung zu einer (neuen oder schon existierenden) Datenbank werden durch hSQLDB vier ver-

9.8 Eingebettete (Java-SQL)-Datenbanken

Anwendungsarchitekturen

Anfragesprache

JDBC

Datenbankkonzepte

■ ■ ■

265

schiedene Dateien angelegt, deren Bedeutung bereits durch die vergebenen Namen erkenntlich ist: ■

dbname.backup

■

dbname.data

■

dbname.properties

■

dbname.script

Interessant ist vor allem die zuletzt genannte Datei, die ein Skript enthält, das den aktuellen Zustand der Datenbank beschreibt. Diese Datei enthält dabei nicht nur die strukturelle Informationen, beispielsweise die definierten Tabellenstrukturen, sondern auch die gespeicherten Daten selbst, codiert in der Form von regulären SQLStatements. Durch diese Datei wird die Entwicklung des DatenbankZustands über einen gewissen Zeitraum dokumentiert. Die Größe dieser Skriptdatei zu jedem Zeitpunkt (trotz einer großen Anzahl abgesetzter INSERT- und DELETE-Anweisungen) sehr klein gehalten werden, so dass keine Speicher-Engpässe entstehen. Positiver Nebeneffekt dieser umfassenden Zustands-Protokollierung: kommt es zum Absturz einer Datenbank, können sämtliche Tabellen mitsamt den zugehörigen Daten aus der Skript-Datei wiederhergestellt werden. Zusammenfassung

266

■ ■ ■

Für einen Einsatz von hSQLDB sprechen die sehr guten Performanzeigenschaften. So können auf einem durchschnittlich ausgestatteten mobilen Client innerhalb einer Sekunde bis zu 4000 Änderungsoperationen auf einer Datenbank ausgeführt werden. Neben dem angesprochenen Datenbankmanager existieren weitere Tools, die zusammen mit dem Kerndatenbanksystem ausgeliefert werden. Dazu gehören ein Transfer-Tool, mit dem beliebige Datenmengen zwischen verschiedenen Datenbanken ausgetauscht werden können, und ein einfach zu bedienendes Skript-Tool, mit dem grosse SQLSkripte ausgeführt werden können. Zusammenfassend lässt sich sagen, dass es sich bei hSQLDB um ein sehr einfach zu installierendes und zu bedienendes Datenbanksystem handelt, das sich aufgrund seiner Größe hervorragend für einen Einsatz auf mobilen Systemen eignet. Durch die vielen verschiedenen Programmarchitekturen sind bezüglich der Einsatzmöglichkeiten kaum Einschränkungen vorgegeben. Erst wenn es darum geht, fortgeschrittenere Datenbankfunktionalität, wie beispielsweise eine umfassendere Unterstützung von Transaktionen, einzusetzen, ist der Einsatz eines professionellen Datenbanksystems sinnvoll.

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

9.8.3 InstantDB Der Download der Java-SQL-Datenbank InstantDB25 ist insgesamt nur unwesentlich kleiner als der Download der bereits vorgestellten hSQLDB-Datenbank. Die Datenbank-Engine selbst ist in der Datei idb.jar gekapselt. Die Strukturen einer Datenbank werden bei InstantDB über Einträge einer Properties-Datei beschrieben, was es unmöglich macht, Datenbanken on-the-fly anzulegen. Der Name einer Datenbank kann frei gewählt werden und wird Bestandteil der Datenbank-URL, über die der Zugriff auf eine Datenbank erfolgt. Der genaue Speicherort der angelegten Datenbank-Dateien wird zusammen mit weiteren Metainformationen ebenfalls in der Properties-Datei vermerkt – unter Verwendung relativer oder absoluter Pfade. Bedingt durch diese Vorgehensweise wird es möglich, Datenbanken physisch an einen anderen Speicherort zu kopieren, ohne dass dies Änderungen der die Datenbank benutzenden Anwendungen zur Folge hat. Über die Properties-Datei können viele weitere verschiedene Parameter gesetzt werden. So kann eine Datenbank beispielsweise in den Read-Only-Modus gesetzt werden, so dass nur noch Lesezugriffe erlaubt sind. Auch komplexere Tuning-Maßnahmen, wie zum Beispiel die Steuerung des Cache-Verhaltens bei Datenbankzugriffen, lassen sich über eine Variation entsprechender Parameter der Properties-Datei durchführen. Auf eine Datenbank selbst wird dabei wie schon bei hSQLDB über einen geeigneten JDBC-Treiber (org.enhydra.instant-db.jdbc.idb-Driver) zugegriffen. Dieser gestattet allerdings lediglich den lokalen Zugriff auf eine Datenbank aus einer einzigen virtuellen Maschine heraus. Soll eine Client/ServerArchitektur realisiert werden, müssen sowohl der Transport der Anfrage als auch der Ergebnisse, über entsprechende Netzwerkstrukturen selbst implementiert werden. Datentabellen, Systemtabellen und Indexstrukturen werden für gewöhnlich in unterschiedlichen Verzeichnissen gespeichert. Transaktionssicherheit wird mit Hilfe einer Journal-Datei realisiert, auf die mit Hilfe einer ebenfalls mitgelieferten Anwendung (mit dem Namen dumb) zugegriffen werden kann. Die in InstantDB verfügbaren Datentypen sind eher an die Programmiersprache Java, und weniger der Datenbankabfragesprache SQL angelehnt, was zwar für JavaAnwendungen Vorteile mit sich bringt, bei der Portierung einer Datenbank allerdings zu erheblichen Problemen führen kann. Im Gegensatz zu hSQLDB ist die Anzahl der verfügbaren Funktionen nur 25

Datenbankkonzepte

JDBC

Datentypen

http://instantdb.tripod.com/old-site/

9.8 Eingebettete (Java-SQL)-Datenbanken

■ ■ ■

267

Zusammenfassung

sehr gering. Allerdings können eigene Funktionen (User Defined Functions) ergänzt werden. Darüber hinaus werden auch Trigger unterstützt. Als Besonderheit ist weiterhin zu nennen, dass InstantDB verschiedene Transaktionsmodelle unterstützt. Eines realisiert sogar ein echtes verteiltes 2-Phasen-Sperr-Protokoll. Zusammenfassend kann gesagt werden, dass es sich bei InstantDB um ein im Vergleich zu hSQLDB schwieriger einzusetzendes Datenbanksystem handelt. Als Vorteil von InstantDB sind vor allem die Unterstützung komplexerer Transaktionsmodelle und die mögliche Definition von nutzerdefinierte Funktionen (User Defined Functions) und Triggern, aber auch die wesentlich ausführlichere Dokumentation zu nennen. Was jedoch die Performanz anbelangt, zeigen sich bei InstantDB erhebliche Schwächen vor allem im Vergleich mit hSQLDB.

9.9 Vergleich der mobilen Datenbanksysteme In den Abschnitten 9.2 bis 9.7 wurden insgesamt sechs verschiedene kommerzielle mobile Datenbanksysteme ausführlich vorgestellt: DB2 Everyplace, Oracle 10g Lite, Adaptive Server Anywhere und UltraLite, Tamino Mobile Suite, PointBase Micro und Microsoft SQL Server CE Edition. In diesem Abschnitt werden diese sechs Systeme bezüglich ihrer wichtigsten Implementierungsmerkmale verglichen. Abschließend wird eine Empfehlung gegeben, welches mobile Datenbanksystem sich für welchen Aufgabenbereich besonders gut eignet. Die in Abschnitt 9.8 vorgestellten eingebetteten Datenbanken finden bei dem Vergleich aufgrund ihrer untergeordneten Position keine Berücksichtigung. Am ehesten würde man aber hSQLDB den Aufstieg in die Leistungsklasse der anderen Systeme zutrauen. Zum jetzigen Zeitpunkt (April 2004) spielen die in Abschnitt 9.8 vorgestellten Systeme jedoch nur eine Nebenrolle.

9.9.1 Architektur der Datenbank-Engine Klassifikation

268

■ ■ ■

Bei den von den untersuchten Datenbanksystemen realisierten Anwendungsarchitekturen lassen sich zwei Ansätze unterscheiden. Dem klassischen, um spezielle Middleware ergänzten Client/ServerAnsatz, wie er bei DB2 Everyplace, Oracle 10g Lite, Tamino Mobile Suite und Microsoft SQL Server CE Edition realisiert wird (vgl. Abbildung 9.25), steht als Alternative die vollständige Integration einer mobilen Datenbank in eine Anwendung (vgl. Abbildung 9.25)

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

gegenüber. Sybase UltraLite und PointBase Micro sind Vertreter dieser zweiten Kategorie. Drahtlose Netzwerkanbindung Mobile Clients DB Anwendung

Festnetzverbindung

Middleware (Synchronisations-Server)

DB-Server

Abb. 9.25: Architektur von DB2 Everyplace, Oracle 10g Lite, Tamino Mobile und SQL Server CE

Während im ersten Fall die mobile Datenbank von den auf sie zugreifenden Anwendungen getrennt bleibt, wird beim letzteren eine in ihrer Funktionalität angepasste Datenbank vollständig in eine Anwendung „einkompiliert“. Die Unabhängigkeit einer Datenbank von den Anwendungen wird in diesem Fall somit aufgegeben. Mobile Anwendung

Integrierte Datenbank

Drahtlose Netzwerkanbindung

Festnetzverbindung

Optionale Middleware

DB-Server

Abb. 9.26: Architektur von Sybase UltraLite und PointBase Micro

In ihrer grundlegenden Anwendungsarchitektur unterscheiden sich die untersuchten Datenbanksysteme vor allem in Bezug auf die Architektur der mobilen Kerndatenbanksysteme. Während die eine Seite eine saubere Trennung zwischen Anwendung und Datenbanksystem aufrechterhält, wird diese Unabhängigkeit auf der anderen Seite zugunsten eines geringeren Speicherbedarfs aufgegeben.

9.9.2 Replikation und Synchronisation Ziel der Synchronisation ist die Aufrechterhaltung bzw. Wiederherstellung eines konsistenten Zustands aller Kopien eines Datenelementes innerhalb einer Replikationsumgebung. Der Synchronisationsprozess besteht aus zwei Phasen. Die Reintegration überträgt die auf dem mobilen Client geänderte Daten auf den Datenbankserver (Phase 1), während bei der anschließenden (optionalen) Rückübertragung (Phase 2) zwischenzeitlich auf dem Datenbestand des Servers vorgenommene Änderungen auf die Clients übertragen werden. Alle in dieser Arbeit untersuchten mobilen Datenbanksysteme bieten Verfahren zu dieser bidirektionalen Synchronisation an.

9.9 Vergleich der mobilen Datenbanksysteme

Bidirektionale Synchronisation

■ ■ ■

269

Disconnected Mode

Um das Arbeiten mit mobilen Clients im unverbundenen Zustand (Disconnected Mode) zu unterstützen, ist es notwendig, während einer bestehenden Netzwerkverbindung (Connected Mode) Daten eines zentralen Datenbankservers auf den mobilen Client zu replizieren. Die Datenbanksysteme DB2 Everyplace, Tamino Mobile und Sybase UltraLite fassen Replikation lediglich als eine Teilphase eines zweistufigen, bidirektionalen Synchronisationsprozesses auf. Oracle 10g Lite definiert dagegen ein Replikationsverfahren auf der Basis von Snapshots. Auf Snapshots basiert ebenfalls das Synchronisationsverfahren von PointBase Micro, das wie die zuerst genannten Datenbanksysteme Replikation als eine Teilphase bidirektionaler Synchronisation ansieht. Auch Microsofts SQL Server CE Edition bietet mit der Mergereplikation und der nachrichtenbasierten Replikation sogar zwei Replikationsverfahren an. Synchronisation wird in diesem Fall als zweistufige Replikation angesehen und ist sozusagen implizit definiert.

9.9.3 Programmierung Klassifikation

DB2 Everyplace

Tamino Mobile Suite

270

■ ■ ■

Bezüglich der Entwicklung mobiler Datenbankanwendungen, können die untersuchten Systeme in zwei Klassen eingeteilt werden. Während die erste Klasse (DB2 Everyplace, Tamino Mobile Suite, Microsoft SQL Server CE) eine Entwicklungsumgebung für eine einfache und schnelle Implementierung beinhaltet, existiert ein solches Spezialtool bei den Systemen der zweiten Klasse (Sybase UltraLite, Oracle 10g Lite und PointBase Micro) zum jetzigen Zeitpunkt noch nicht. Doch auch in diesem Fall stellt die Programmierung entsprechender Anwendungen kein allzu großes Problem dar. Mobile Datenbankanwendungen, die auf DB2 Everyplace basieren, lassen sich sehr leicht mit Hilfe des Mobile Application Builders realisieren. Im Idealfall muss keine einzige Zeile Quellcode von Hand getippt werden. Ein weiterer Vorteil ist die Unterstützung einer großen Anzahl von Zielplattformen. Anwendungen können in Java, C oder Visual Basic programmiert werden. Die Tamino Mobile Suite hat mit dem Tamino Mobile Studio ein ähnliches Entwicklungstool wie IBM mit dem Mobile Application Builder. Anwendungen werden in C, vornehmlich aber in Java entwickelt. Eine Besonderheit ist die enorme Vielfalt der unterstützten Standards und Webtechnologien, die dem Entwickler viele Möglichkeiten eröffnet, gleichzeitig aber auch die Komplexität der Anwendungserstellung stark erhöht.

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Auch die Erstellung von mobilen Datenbankanwendungen, die auf Microsofts SQL Server CE basieren, gestaltet sich relativ einfach. Wird mit dem Visual Studio .NET entwickelt, ist der Entwickler auf keine besondere Programmiersprache festgelegt. Werden dagegen die eMbedded Visual Tools verwendet, erfolgt die Anwendungsentwicklung in C/C++. Gerade bei der Erstellung einfacher mobiler .NET-Anwendungen wird der Entwickler stark unterstützt. Die Anwendungsentwicklung für Sybase Adaptive Server Anywhere und Sybase UltraLite gestaltet sich vergleichsweise schwierig. Ein spezielles Entwicklungstool existiert nicht und das Konzept der Integration einer anwendungsspezifischen Datenbank in eine Applikation erweist sich auf den ersten Blick als recht ungewohnt. Nach Überwindung der ersten Startschwierigkeiten ist aber auch in diesem Fall die Anwendungsentwicklung machbar. Entwickler können verschiedene Programmiersprachen verwenden, darunter C/C++ und Java. Die Implementierung von Datenbankanwendungen, die auf Oracle 10g Lite basieren, erweist sich ebenfalls als relativ aufwendig. Leider wird auch in diesem Fall keine Entwicklungsumgebung mitgeliefert. Wird allerdings in Java entwickelt, kann auf generische Java-Entwicklungsumgebungen zurückgegriffen werden, wie den JDeveloper von Oracle. Von allen untersuchten Datenbanksystemen weist Oracle mit Sicherheit die größte Mächtigkeit auf. Aus diesem Grund erweist sich vor allem der Aufbau einer mobilen Infrastruktur und der Synchronisationsmechanismen als recht schwer. Sind diese Konfigurationsarbeiten allerdings sauber durchgeführt, sind die zugehörigen Anwendungen ebenfalls recht schnell erstellt und einsatzbereit. Einen Spezialfall stellt das mobile Datenbanksystem PointBase Micro dar. Als vollständig in Java implementiertes Datenbanksystem kann auch die Entwicklung mobiler Datenbankanwendungen ausschließlich in Java erfolgen. Entwickler sollten also zumindest keine Java-Anfänger sein, um dieses Datenbanksystem effektiv einsetzen zu können. Wer sich aber ein wenig mit Java auskennt wird sehr schnell erkennen, wie intuitiv und leicht verständlich sowohl die Anwendungserstellung als auch die Programmierung der durchzuführenden Synchronisationsprozesse ist. Verschiedene grafische Tools unterstützen den Entwickler vor allem bei der Administration bereits vorhandener Infrastrukturen.

9.9 Vergleich der mobilen Datenbanksysteme

SQL Server CE

iAnywhere

Oracle 10g Lite

PointBase

■ ■ ■

271

9.9.4 Zusammenfassung Zielsetzung

IBM, Oracle, Microsoft, Software AG

iAnywhere, PointBase

272

■ ■ ■

Entscheidend für den Einsatz eines bestimmten Produktes sind die Anforderungen, die an das mobile Datenbanksystem gestellt werden. Ein mobiles Datenbanksystem muss sich flexibel an die verfügbaren Ressourcen mobiler Clients anpassen. Anwendungsentwicklern muss eine leicht zu benutzende und gleichzeitig mächtige Schnittstelle bereitgestellt werden, die auch eine Möglichkeit zur Erweiterung um nutzerspezifische Funktionen bietet. Gerade die Konzeption als modulares, leicht konfigurierbares Datenbanksystem, das sich bei Bedarf um zusätzliche Funktionalitäten erweitern lässt, spielt eine sehr wichtige Rolle für einen effizienten und produktiven Einsatz in Unternehmensinfrastrukturen. Welches mobile Datenbanksystem tatsächlich eingesetzt wird, ist letztlich abhängig von den Prämissen und Anforderungen der Kunden. Generell lässt sich feststellen, dass alle Produkte grundlegende Aufgaben beim Aufbau mobiler Infrastrukturen erfüllen. Als Vorteil der Systeme der vier großen Hersteller IBM, Oracle, Microsoft und Software AG muss die nahtlose Integration und die guten Kombinationsmöglichkeiten mit anderen Produkten des jeweils gleichen Unternehmens gesehen werden. Durch die Unterstützung von JDBC oder ODBC können aber auch herstellerfremde Komponenten eingebunden werden. In dieser Konstellation kommt es beim Aufbau der mobilen Infrastruktur und auch bei der Administration der Synchronisationsarchitektur kaum zu nennenswerten Schwierigkeiten. Positiv ist die perfekt aufeinander abgestimmte Laufzeitumgebung. Negativ sind die hohen Lizenzgebühren. Vor allem bei Großprojekten wird man aber trotz allem mit diesen Systemen auf der sicheren Seite sein. Wer dagegen ein mobiles Datenbanksystem sucht, das mit anderen Datenbanksystemen im Backend kombiniert werden soll, kann durchaus auch auf die Alternativen von Sybase oder PointBase Micro zurückgreifen. Dass die Unternehmensgröße nicht immer entscheidend bei der Auswahl eines Produktes zeigt iAnywhere, das mit seinen Produkten für mobile Umgebungen Marktführer in Europa ist. PointBase Micro stellt insofern einen Sonderfall dar, als dass die Anwendungsentwicklung ausschließlich in Java erfolgen kann. Insbesondere bei Projekten, die auf bereits existierenden J2EEArchitekturen und –Umgebungen aufsetzen, kann sich dieses System aufgrund seiner intuitiven Benutzung als erste Wahl erweisen. Auch die vergleichsweise günstigen Lizenzkosten sprechen für dieses Datenbanksystem.

9 Konzepte, Bewertung und Vergleich kommerzieller mobiler Datenbanksysteme

Für ganz Mutige empfiehlt kann es sich auch durchaus empfehlen, auf eines der angesprochenen Nischenprodukte auszuweichen. Insbesondere hSQLDB macht einen teilweise bereits sehr guten Eindruck. Da sich hSQLDB aber zweifellos noch in einem relativ frühen Entwicklungsstadium befindet, sollte dieses System zunächst immer nur in Testumgebungen, und erst danach in Produktionsumgebungen eingesetzt werden. Generell empfiehlt es sich, bei Projekten, denen eine grosse Bedeutung zukommt, die vorgesehene Infrastruktur lieber einmal mehr als normal zu testen. eXtremeDB als hochoptimiertes Spezialdatenbanksystem und InstantDB als noch recht unausgereiftes OpenSource-Projekt stellen im Normalfall keine vernünftige Alternative dar. Lediglich zum Vergleich verschiedener Systeme oder in sehr speziellen Anwendungsszenarien sollte auf eines dieser beiden Datenbanksysteme zurückgegriffen werden.

9.9 Vergleich der mobilen Datenbanksysteme

hSQLDB, eXtremeDB, InstantDB

■ ■ ■

273

Teil 3 Praxis

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

Nachdem in den bisherigen Kapiteln die konzeptionellen Grundlagen und technischen Beschreibungen existierender Systeme vorgestellt wurden, wird nun, als Beispiel für den praktischen Einsatz mobiler Datenbanksysteme, die Implementierung einer mobilen Datenbankanwendung vorgestellt. Das gewählte Anwendungsszenario einer Adressdatenbank bleibt dabei bewusst einfach strukturiert, um möglichst intuitiv aufzuzeigen, welche Möglichkeiten der Einsatz mobiler Datenbanksysteme und Entwicklungsumgebungen mit sich bringt. Darüber hinaus sollen die Prinzipien verdeutlicht werden, was anhand einer einfachen Anwendung besser geht als mit einer komplexen. Der Programmcode kann dann ohne Schwierigkeiten als Ausgangspunkt für komplexere Anwendungsszenarien verwendet werden. Um verschiedene Systeme auch praktisch zu vergleichen, wird die Beispielanwendung in drei verschiedenen Varianten implementiert26. Während die beiden ersten Implementierungsvarianten in C programmiert werden, ist die dritte Anwendung in Java realisiert.

Motivation

10.1 Implementierungsvarianten In einer ersten Variante wird das Anwendungsszenario mit der Programmiersprache C unter Verwendung der vom Palm Software Development Kit (SDK) bereitgestellten Programmbibliotheken und

Variante 1

26

Da im Rahmen dieses Kapitels nur auf die wichtigsten Charakteristika und Besonderheiten der drei Implementierungsvarianten eingegangen werden kann, sei auf die dem Buch beiliegende CD-ROM verwiesen. Die CD-ROM enthält den vollständigen Programmcode aller drei Beispielanwendungen zusammen mit weiteren Materialien sowie zusätzliche Erläuterungen zu Installation und Konfiguration.

10.1 Implementierungsvarianten

■ ■ ■

277

APIs mit einem einfachen Texteditor implementiert. Auf den Einsatz eines mobilen Datenbanksystems wird in diesem Fall verzichtet, stattdessen wird bei der Programmierung lediglich auf rudimentäre Datenbankfunktionalität zurückgegriffen, wie sie sich direkt aus dem Speicherkonzept und dem Programmiermodell von Palmgeräten ergibt. Die als Ausführungsplattform gewählten Palmgeräte (auch als Palmtops bezeichnet) verfügen über keine Festplatte, sondern lediglich über einen RAM-ähnlichen Speicher, der jedoch in der Lage ist, Daten persistent zu speichern. Für die Ablage von Daten werden einfache Datenbanken verwendet, die direkt auf der blockorientierten Speicherstruktur der Palmtops aufsetzen. Über eine Bibliothek von Schnittstellenfunktionen können sämtliche Daten innerhalb einer Datenbank verwaltet werden. Darüber hinaus existieren weitere Methoden für das Anlegen und Löschen einer Datenbank und für das Anlegen, Ändern, Anfügen und Löschen von Datensätzen. Alle diese Methoden arbeiten dabei sehr hardwarenah, so dass die Programmierung der notwendigen Datenbankfunktionalität sehr komplex ist. Zudem sind die mit diesen Methoden realisierbaren Datenbankfeatures nicht mit den Datenverwaltungsfunktionen vollständiger Datenbanksysteme vergleichbar. Für die Synchronisation mit einer anderen entfernten Datenquelle muss neben der eigentlichen Applikation zusätzlich ein Conduit programmiert werden. Ein Conduit ist ein selbständig ablaufendes Programm, dessen Aufgabe die Koordination und Ausführung von Synchronisationsprozessen ist. Diese erste Implementierungsvariante soll aufzeigen, wie komplex und aufwendig die manuelle Programmierung von Datenbank- und Synchronisationsfeatures ist. Darüber hinaus bildet diese erste Anwendung die Basis für spätere Vergleiche mit anderen Implementierungsvarianten. Variante 2

278

■ ■ ■

In einer zweiten Variante wird die Adressdatenbank unter Verwendung des kommerziellen mobilen Datenbanksystems DB2 Everyplace von IBM implementiert. DB2 Everyplace ist ein mobiles Datenbanksystem, das viele mächtige Datenbankfunktionen bereitstellt und auch Mechanismen für die Synchronisation verschiedener Datenquellen anbietet (vgl. Kapitel 9.2). In diesem Fall wird die mobile Datenbankanwendung mit der integrierten Entwicklungsumgebung Mobile Application Builder erstellt, die Bestandteil des DB2 Everyplace Software Development Kit (SDK) ist und eine effiziente, weitgehend automatisierte Anwendungsentwicklung erlaubt. DB2 Everyplace wird dabei exemplarisch als Vertreter der Produkte der großen Datenbankhersteller (IBM, Oracle, Microsoft, iAnywhere) herangezogen.

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

Da verstärkt kleinere Nischenanbieter in den Markt der kommerziellen mobilen Datenbanksysteme drängen, wird in der dritten Variante PointBase Micro als Vertreter leichtgewichtiger Datenbanksysteme herangezogen. PointBase Micro ist der aktuell wichtigste Vertreter dieser Anbietergruppe. Da es sich dabei um ein vollständig in Java implementiertes, eingebettetes Datenbanksystem handelt, erfolgt auch die Anwendungsentwicklung in Java.

Variante 3

Dieses Kapitel gliedert sich im weiteren Verlauf wie folgt: Abschnitt 10.2 stellt zunächst Programme und Tools vor, die für die Anwendungsentwicklung aller drei Varianten benötigt werden und beschreibt wichtige Aspekte der Anwendungsentwicklung. Abschnitt 10.3 beschreibt anschließend zunächst die Eigenschaften des PalmBetriebssystems (bzw. des Palm-Programmiermodells), die für die Entwicklung von Palmtops in unserem Zusammenhang wichtig sind. Am Ende von Abschnitt 10.3 stehen dann die konkreten Implementierungen der Beispielanwendungen im Vordergrund. Abschnitt 10.4 geht auf die manuell programmierte C-Implementierung ein. Abschnitt 10.5 erläutert die mit DB2 Everyplace und dem Mobile Application Builder erstellte Anwendung und in Abschnitt 10.6 werden in Grundzügen die wichtigsten Implementierungsmerkmale der mit PointBase Micro erstellten Java-Anwendung vorgestellt. Eine Bewertung und ein Vergleich der drei Implementierungsvarianten anhand verschiedener Kriterien (Installation, Anwendungsentwicklung, Synchronisation und Lizenzkosten) runden dieses Kapitel ab.

Überblick

10.2 Programmierwerkzeuge und Konfiguration der Entwicklungsumgebung Die Entwicklung der Beispielanwendungen ist in allen drei Implementierungsvarianten an die Verfügbarkeit zusätzlicher SoftwareTools, Programmierbibliotheken oder Laufzeitumgebungen gekoppelt. Erst der abgestimmte Einsatz dieser Programme macht die Entwicklung von Anwendungen für mobile Clients (konkreter: für die Palm-Plattform) möglich. Insbesondere für die Anwendungsentwicklung mit der Programmiersprache C in den beiden ersten Implementierungsvarianten wird gleich eine ganze Reihe von Zusatztools benötigt. In Java ist dies einfacher.

10.2 Programmierwerkzeuge und Konfiguration der Entwicklungsumgebung

Zusätzliche Werkzeuge

■ ■ ■

279

10.2.1 Entwicklung in C Um die ersten der beiden Implementierungs-Varianten für Palmtops realisieren zu können, müssen gleich eine ganze Reihe an Programmen unterschiedlicher Hersteller auf dem vorgesehenen Entwicklungssystem installiert werden. Dies sind im Einzelnen:

280

■ ■ ■

■

GNU C-Compiler/Cygwin. Soll in C programmiert werden, benötigt man zunächst einmal einen C-Compiler. Während unter Linux der GNU C-Compiler (GCC) verwendet werden kann, der bei den meisten Linux-Distributionen automatisch Teil der Standardinstallation ist, muss bei der Programmierung unter Windows auf das Programm Cygwin zurückgegriffen werden. Dieses Programm emuliert auf Windows-Betriebssystemen eine vollständige UNIX-ähnliche POSIX-Kommandozeile. Für die Kommandozeile wird auch ein GCC-Compiler bereitgestellt, so dass Quelltext auch auf der Windows-Plattform kompiliert und auch ausgeführt werden kann. Cygwin ist Opensource-Software, die aktuell (Februar 2004) in Version 1.5.5 vorliegt.

■

PRC-Tools. Die PRC-Tools, die auch unter dem Namen GCC Tool Chain bekannt sind, beinhalten weitere Zusatzprogramme, die Cygwin nicht zur Verfügung stellt, die aber für die Programmierung von Palmtops benötigt werden. Neuere Versionen von Cygwin bieten bereits während der Installation die Option, die jeweils aktuelle Version der PRC-Tools automatisch mit einzubinden. Bei älteren Versionen von Cygwin müssen die PRC-Tools noch manuell nachinstalliert werden. Aktuell (Februar 2004) ist Version 2.3 der PRC-Tools, die ebenfalls als Opensource-Software entwickelt werden.

■

PilRC. PilRC ist ein Ressourcen-Compiler. Formulare, Schaltflächen, Listen und andere graphische Oberflächenelemente einer Anwendung werden bei der Programmierung von Palmtops über textuelle Ressourcen-Dateien zunächst beschrieben. Für die Beschreibung der Elemente ist eine genau definierte Syntax definiert. Die textuellen Ressourcen-Dateien werden mit PilRC in Binärdateien übersetzt. Diese Binärdateien werden anschließend in die Anwendungen eingebunden und bilden deren grafische Oberfläche. PilRC liegt aktuell (Januar 2004) in Version 3.1 vor. Wie bei Cygwin und den PRC-Tools zuvor handelt es sich wiederum um Opensource-Software.

■

Palm Software Development Kit. Das Palm Software Development Kit (Palm-SDK) ist ein umfangreiches Entwicklerpaket

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

für die Programmierung von Palmtops. Für die Entwicklung mit dem GCC-Compiler muss mindestens Version 3.5, besser jedoch Version 4 des SDK eingesetzt werden. Zwar ist aktuell (Februar 2004) bereits Version 6 des SDK verfügbar, diese unterstützt die Entwicklung mit GCC jedoch noch nicht. Auch Version 5 weist gegenüber Version 4 des SDK lediglich Anpassungen an die speziellen Anforderungen neuerer ARMProzessoren auf, die nur dann eine Rolle spielen, wenn Palmtops der neuesten Generation (beispielsweise ein Tungsten T3) als Ausführungsumgebung der erstellten Anwendung eingesetzt werden. Nur diese neueste Gerätegeneration verfügt über moderne ARM-Prozessoren. Auch der Mobile Application Builder von DB2 Everyplace unterstützt lediglich Version 4 des SDK. Abb. 10.1: Anordnung der Tools

PRC-Tools

Editor

SDK MAB

PilRC

Programmierung ■

Kompilierung

Cygwin

Entwicklungssystem

Emulator

Simulator

Test

Palm-Emulator/Palm-Simulator. Um kompilierte Anwendungen sicher und einfach testen zu können, ohne Datenverluste zu riskieren, ist der Einsatz eines Palm-Emulators/Palm-Simulators sinnvoll. Während der neuere Simulator ausschließlich das Display eines Palmgerätes anzeigt und auf die Darstellung der Geräteumrandung und der Schnellzugriffstasten verzichtet, kann der ältere Emulator über austauschbare Oberflächen (Skins genannt) an das Aussehen verschiedener Gerätetypen angepasst werden. Um das Betriebssystem eines Palms zu simulieren, muss das Speichermodell eines Palmtops simuliert werden. Sowohl Emulator als auch Simulator verwenden dazu ein Speicherabbild (ROM-Image) eines Palmtops, das auch direkt aus dem Speicher eines real verfügbaren Palmtops ausgelesen werden kann. Das dazu notwendige Werkzeug ist Teil des PalmSDK. Der Simulator bringt die benötigten ROM-Images bereits mit. Alternativ kann auch direkt auf einem echten Palm getestet werden, was aber eher unpraktisch ist. Der Einsatz eines Simu-

10.2 Programmierwerkzeuge und Konfiguration der Entwicklungsumgebung

■ ■ ■

281

lators ist deswegen ratsam, da es aufgrund von Programmfehlern auf für das Testen verwendeten Palmtops zu Systemabstürzen kommen kann, die zu einem kompletten Verlust sensitiver Daten führen können. Bei einem Emulator besteht diese Gefahr dagegen nicht. Bis einschließlich Version 4 des Palm-SDK wird ein Emulator, ab Version 5 ein Simulator bereitgestellt. Palm-OS Developer Suite

Neuerdings steht auf der Palm-Homepage auch eine erste Version der Palm OS Developer Suite zum Download bereit. Diese fokussiert die Entwicklung von Business-, Multimedia- und mobilen Applikationen vor allem für Palm-OS-basierte Smartphones. Das Entwicklerpaket erlaubt die Anwendungsprogrammierung für alle vorhandenen Versionen von Palm-OS (inklusive Palm-OS Version 6). Wichtigster Bestandteil der Developer Suite ist eine auf IBMs Eclipse basierende integrierte Entwicklungsumgebung, die verschiedene Programmiersprachen wie C/C++ oder Java unterstützt. Besonders vorteilhaft ist die Developer Suite für alle Programmierer, die sowohl für 68K- als auch für ARM-basierte Palmtops entwickeln. Für Synchronisationsvorgänge verwendet Palm-OS so genannte Conduits. Um Synchronisationsmechanismen respektive Conduits programmieren zu können ist, muss auf dem Entwicklungssystem zusätzlich das Conduit Development Kit installiert werden. Auch dieses SDK steht auf der Palm-Homepage zum Download bereit. ■

282

■ ■ ■

Conduit Development Kit (CDK). Bei der ersten Implementierungsvariante direkt in C muss für die Programmierung des Synchronisationsmechanismus auf das ebenfalls von Palm angebotene Conduit Development Kit (CDK) zurückgegriffen werden. Ein Conduit ist ein selbstständig ablaufendes Programm, das für die Koordination und Durchführung aller Synchronisationsprozesse zwischen verschiedenen Datenquellen zuständig ist. Conduits werden für gewöhnlich auf mobilen Clients ausgeführt und können mit den Programmiersprachen C, Visual Basic oder Java erstellt werden. Im Fall des Conduits der ersten Implementierungsvariante wurde die Programmiersprache C/C++ gewählt. Entwicklungsumgebungen, die das CDK direkt unterstützen, erlauben mit Hilfe eines Assistenten eine schnelle Erstellung des Grundgerüsts eines Conduits. Alternativ kann ein Conduit natürlich auch direkt programmiert werden. Für die Erstellung des hier vorgestellten Conduits wurde Microsofts Visual Studio .NET verwendet. In den Projektvorlagen dieser Entwicklungsumgebung steht nach der Installation des CDK der angesprochene Assistent zur Verfügung.

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

Das CDK beinhaltet eine spezielle Entwicklerversion des HotSync-Programms, mit dem das Debuggen und Testen von Conduits erheblich vereinfacht wird. Das HotSync-Programm ist für die Koordination aller Synchronisationsvorgänge zwischen einem Palm und einer oder mehreren anderen Datenquelle(n) zuständig. Dazu führt das HotSync-Programm bei jedem Synchronisationsvorgang alle angemeldeten Conduits aus. Während der Entwicklungsphase muss die normale HotSync-Anwendung durch die Entwicklerversion ersetzt werden. Mit der Beendigung der Anwendungsentwicklung kann dieser Schritt ohne grosse Schwierigkeiten wieder rückgängig gemacht werden.

EntwicklerHotSync

10.2.2 Entwicklung in Java Nachdem im vorhergehenden Abschnitt diejenigen Tools vorgestellt wurden, die sowohl bei ersten Implementierungsvariante, als auch bei der auf DB2 Everyplace basierenden Lösung die Voraussetzung jeder Programmiertätigkeit sind, wird nun auf die wichtigsten Konzepte und Begriffe der Java 2 Micro Edition (J2ME) eingegangen, die die Grundlage der dritten vorgestellten, auf PointBase Micro basierende Implementierungsvariante ist [Kro03]. Im Jahre 1999 unterteilte Sun Microsystems die Java-Familie in drei Sparten: die Java 2 Enterprise Edition (J2EE), die Java 2 Standard Edition (J2SE) und die Java 2 Micro Edition (J2ME). Zweck dieser Aufteilung war es, verschieden mächtige Laufzeitumgebungen und Klassenbibliotheken für unterschiedliche Anwendungsszenarien und Geräteklassen/Hostsysteme zu realisieren. Dadurch können Applikationen erstellt werden, die besser an die jeweiligen Entwicklerbedürfnisse angepasst sind. Die Java 2 Micro Edition zielt dabei auf kleine, meist mobile oder eingebettete Systeme, wie Handys, PDAs, Smartphones oder Pager ab. Wichtigstes Kernelement der J2ME ist eine leichtgewichtige virtuelle Maschine, die die Einschränkungen eingebetteter und mobiler Systeme berücksichtigt. Aufgrund ihres geringen Speicherplatzbedarfs von nur einigen wenigen Kilobyte wird sie auch als Kilobyte Virtual Machine (KVM) bezeichnet. Die Weiterentwicklung der KVM obliegt dem Java Community Process (JCP)27.

Java 2 Micro Edition

27

Der Java Community Process wurde von Sun Microsystems 1998 ins Leben gerufen. Das Ziel war es, weitere Hersteller an der Entwicklung der Java-Standards zu beteiligen. In der Zwischenzeit gehören dem JCP nach Angaben von Sun Microsystems bereits mehr als 700 Unternehmen und Einzelpersonen als Mitglied an.

10.2 Programmierwerkzeuge und Konfiguration der Entwicklungsumgebung

■ ■ ■

283

Reduktion der Klassenbibliotheken

Konfigurationen

CDC und CLDC

Profile

MIDP

284

■ ■ ■

Nachdem mit der KVM eine neue Laufzeitumgebung definiert war, bestand eine weitere Aufgabe darin, die bereits existierenden Klassenbibliotheken der Java 2 Standard Edition auf ihre Eignung für eingebettete und mobile Systeme hin zu untersuchen. Das Ergebnis war die Erkenntnis, dass nur ein Bruchteil der insgesamt verfügbaren Klassen sinnvoll in die Java 2 Micro Edition integriert werden konnten. Neben einigen wenigen, einfach übernommenen Klassen war es notwendig, neue Klassen für die speziellen Bedürfnisse mobiler Systeme zu entwickeln. So verfügen viele mobile Clients wie PDAs oder Smartphones über kein richtiges Dateisystem mehr, sondern speichern Daten unter Verwendung von Flash-Speicher oder speziellen, nichtflüchtigen RAM-Modulen. Deshalb mussten hierfür Klassen entwickelt werden, die direkt auf den hardwarenahen Speicherstrukturen mobiler Clients aufsetzen und diese direkt ansprechen. Um zusätzliche Struktur in die verschiedenen Geräteklassen zu bringen, wird zwischen Konfigurationen und Profilen unterschieden. Konfigurationen definieren die Grundfunktionalität der Laufzeitumgebung für bestimmte Geräteklassen. Alle Geräteklassen einer Konfiguration ähneln sich hinsichtlich Rechenleistung, Speicherausstattung und sonstiger Ausstattungsmerkmale. Aktuell existieren nur zwei verschiedene Konfigurationen. Weitere neue Konfigurationen sind in ihrer Spezifikation jedoch bereits weit fortgeschritten. Die Connected Device Configuration (CDC) ist eine Konfiguration, die eher leistungsstarke PDAs fokussiert, die die Möglichkeit haben, eine leistungshungrige, herkömmliche Java Virtual Machine auszuführen. Bezüglich verfügbarer Klassen sind bei dieser Konfiguration kaum Einschränkungen hinzunehmen. Demgegenüber steht die Connected Limited Device Configuration (CLDC), die vor allem auf die Leistungsfähigkeit kleinerer mobiler und eingebetteter Systeme ausgerichtet ist. Kernanforderungen dieser Konfiguration sind eine Mindestausstattung an Speicher zwischen 128 und 512 kB (RAM und ROM zusammengenommen), eine ausreichende Stromversorgung (beispielsweise über Batterien) und die Fähigkeit, Netzwerkverbindungen mit einer minimalen Datengeschwindigkeit von 9600 bps aufrechtzuerhalten. Profile sind Verfeinerungen von Konfigurationen. Während Konfigurationen eine relativ grosse Klasse an Geräten fokussieren, sind Profile wesentlich stärker auf einen bestimmten Gerätetyp, wie beispielsweise einen PDA oder ein Mobiltelefon, ausgerichtet. Ein Beispiel eines solchen Profils ist das Mobile Information Device Profile (MIDP), das speziell an die Bedürfnisse und Fähigkeiten von Mobiltelefonen angepasst ist und somit die Entwicklung von Handy-Applikationen in den Vordergrund stellt, aber auch für die Entwicklung für PDAs und Smartphones eingesetzt werden kann.

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

CDC

Abb. 10.2: Java 2 Plattform

Mobile Information Device Profile

Personal Profile

Für die CDC-Konfiguration existiert mit dem Personal Profile (PP) ein Profil, das dem Entwickler fast die gleiche Funktionalität bietet, was die Eigenschaften der Laufzeitumgebung anbelangt, wie die Java 2 Standard Edition (speziell wie die Java Runtime Environment 1.1). Das Personal Profile unterstützt auch das ursprünglich für die CLDC-Konfiguration entwickelte Generic Connection Framework (GCF), mit dem Netzwerkfunktionen (über Infrarot-, WLAN- und Bluetooth-Schnittstellen) sehr einfach in Anwendungen integriert werden können.

CLDC

JavaCard

Java-Plattform

JVM

KVM

CardVM

Das Mobile Information Device Profile (MIDP) setzt direkt auf der Connected Limited Device Configuration (CLDC) auf. Dazu stellt es eine abstrakte grafische Benutzerschnittstelle bereit (gekapselt in der Klasse LCDUI), die zu anderen existierenden graphischen Oberflächenframeworks wie AWT oder Swing nicht kompatibel ist. Mobile CLDC/MIDP-Anwen-dungen werden als MIDlets bezeichnet. Listing 1 zeigt den Quelltext eines einfachen MIDlets. import javax.microedition.midlet.*; import javax.microedition.lcdui.*;

Listing 1

public class HalloMIDPWelt extends MIDlet { public void startApp() { Form form = new Form (“Hallo MIDP”); Display.getDisplay (this).setCurrent(form) } public void pauseApp() {} public void destroyApp(boolean unconditional) {} }

Zunächst werden die Klassen der beiden Pakete MIDLET und LCDUI importiert, die die für die Anwendungsentwicklung benötigten MIDP-Methoden und grafischen Oberflächenelemente verfügbar machen. Die Startroutine startApp() des MIDlets initiiert das Startformular der Anwendung mit der Bezeichnung „HalloMIDP“

10.2 Programmierwerkzeuge und Konfiguration der Entwicklungsumgebung

■ ■ ■

285

und übergibt das Formular der Methode getDisplay() der Klasse Display, wodurch das Formular auf dem Bildschirm der Ausführungsplattform angezeigt wird (also zum Beispiel dem HandyBildschirm). Die Methode pauseApp() unterbricht die Anwendung in ihrer Ausführung. Sun Wireless Toolkit (WTK)

Das Sun Wireless Toolkit (Version 2.0, Februar 2004) ist ein Projektverwaltungswerkzeug, dass die Entwicklung mobiler J2MEAnwendungen unterstützt. Mit den integrierten Tools können Projekte kompiliert und getestet werden.

10.3 Programmierung von Palmtops28 PalmProgrammierung

Bei der Programmierung von Palmtops müssen einige Randbedingungen beachtet werden, die bei der klassischen Anwendungsentwicklung in dieser Form nicht auftauchen. Im Speziellen sind dies einerseits vor allem das Palmtop-Speichermodell, das eine sehr hardwarenahe Programmierung notwendig macht, andererseits das ereignisgesteuerte Programmiermodell. Für ein besseres Verständnis beider Punkte wird zunächst auf das Speichermodell, danach auf das ereignisbasierte Ablaufmodell von Palmtops eingegangen [Noe03].

10.3.1 Speicheraufbau Persistenz auf Palmtops

Speicherstrukturen

Palmtops verwenden für die dauerhafte Speicherung von Daten kein gewöhnliches Dateisystem, zumindest was den direkt integrierten Speicher anbelangt. Dazu werden die Daten in einfach strukturierten Anwendungsdatenbanken gespeichert, die als logische Abstraktionssicht auf der Hardware aufsetzen. Auf externen Speicherkarten können dagegen durchaus komplette Dateisysteme im herkömmlichen Sinn eingerichtet werden. Der interne Speicher eines Palmtops ist in mehrere Speicherbereiche aufgeteilt, die Heaps genannt werden. Anwendungsdatenbanken werden einem speziellen Speicherbereich, dem Storage Heap, zugeordnet und durch einen Data Manager verwaltet. Verschiedene Speicherbereiche übernehmen verschiedene Aufgaben:

28

Für weitergehende Informationen sei insbesondere auf Dirk Nöldners Buch PalmOS-Programmierung mit GCC (ISBN 3-89864-164-3) hingewiesen, das ein idealer Einstiegspunkt auch für die komplexere Palm-Programmierung ist.

286

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

■

Dynamic Heap. Der Dynamic Heap ist der Speicherbereich, in dem während der Applikationsausführung temporäre Daten abgelegt werden. Temporäre Daten sind beispielsweise Zwischenergebnisse oder ermittelte Anfrageergebnisse. Soft- oder HardResets29 des Palmtops führen dazu, dass alle im Dynamic Heap abgelegten Daten verloren gehen. Im Gegensatz dazu gehen die in diesem Speicherbereich abgelegten Informationen durch das Ausschalten des Palmtops (laufende Anwendungen werden nicht unterbrochen!) jedoch nicht verloren. Im Dynamic Heap abgelegte Daten können somit zeitliche Unterbrechungen bei der Anwendungsausführung überdauern. Erst mit dem Ende der Ausführung einer Anwendung werden alle zu dieser Anwendung gehörenden Daten gelöscht, die aktuell im Dynamic Heap abgelegt sind. Beim Dynamic Heap wird deshalb auch nur von eingeschränkter Persistenz gesprochen. Der Dynamic Heap wird von einem Memory Manager verwaltet und kann mit dem Arbeitsspeicher herkömmlicher Rechnersysteme verglichen werden.

■

Storage Heap. Der Storage Heap ist der Speicherbereich, der dem dauerhaften Ablegen von Daten beliebigen Typs dient. In Bezug auf herkömmliche Computersysteme ähnelt der Storage Heap dem Sekundärspeicher. Weder durch das Ausschalten des Palmtops noch durch einen Soft-Reset gehen die in diesem Bereich gespeicherten Informationen verloren. Im Falle eines Hard-Reset wird jedoch der gesamte Storage Heap vollständig gelöscht. Auch der Storage Heap wird durch eine spezielle Verwaltungskomponente, dem Data Manager, verwaltet.

■

ROM Heap. Der ROM Heap ist ausschließlich dem Betriebsystem vorbehalten und dient darüber hinaus der Ablage nicht zu verändernder Softwarekomponenten, zum Beispiel einer Java Virtual Machine. Weder Soft- noch Hard-Reset wirken sich auf diesen Speicherbereich aus.

Die Unterscheidung zwischen Dynamic Heap und Storage Heap ist eher konzeptioneller Natur, da beide Speichertypen durch dieselbe Speichertechnik realisiert werden. Jeder Heap besteht aus einem oder mehreren Chunks, die den direkt von Anwendungen nutzbaren Speicherblöcken entsprechen. Ein Chunk ist ein in seiner Größe va-

Chunks

29

Bei einem Soft-Reset wird das Betriebssystem des Palmtops neu initialisiert und hochgefahren. Auf dem Palmtop gespeicherte Daten (mit Ausnahme der Anwendungsdaten der gerade geöffneten Applikationen) bleiben erhalten, werden also nicht gelöscht. Im Rahmen eines Hard-Resets werden dagegen alle Speicherbereiche des Palmtops und alle selbst installierten Anwendungen gelöscht.

10.3 Programmierung von Palmtops

■ ■ ■

287

Typen

Feste Speicherbereiche

Variable Speicherbereiche

Zeiger vs. Handle

Sperren

288

■ ■ ■

riabler Speicherbereich mit Größen zwischen einem Byte und 64 kB (zuzüglich eines Chunk-Headers). Im Header sind verschiedene Verwaltungsdaten (wie Belegungsvermerk, Größe, aktuelle Sperren) abgelegt. Chunks können in fester und variabler Größe untergliedert werden, wobei im ROM Heap nur feste Chunks möglich sind. Feste Chunks sind in ihrer Größe festgelegt, bewegliche Chunks können in ihrer Größe an die jeweiligen Bedürfnisse angepasst werden. 10.3.1.1 Speicherzugriffsfunktionen Wie bereits zuvor beschrieben wird hardwareseitig zwischen festen und variablen Chunks unterschieden. Entsprechend gestaltet sich auch der Zugriff auf Chunks unterschiedlich. Einfach ist der Zugriff auf Chunks, wenn diese eine feste Größe besitzen. Dazu muss ein fester Chunk lediglich durch einen Zeiger referenziert werden. Um einen neuen Chunk fester Größe zu definieren, muss die Funktion MemPtrNew() verwendet werden. Das Ergebnis dieser Methode ist der benötigte Zeiger. Um den angelegten Chunk jedoch nutzen zu können, muss zusätzlich dessen Existenz explizit bekannt gemacht werden. Wird dies nicht gemacht, kommt es zu einem so genannten Speicherloch. Um den Chunk systemweit bekannt zu machen, muss die Funktion MemPtrFree() verwendet werden, der der bereits generierte Zeiger übergeben werden muss. Um die aktuelle Größe eines Chunks zu ermitteln, kann die Funktion MemPtrSize() verwendet werden. Bei Chunks variabler Größe ist der Speicherzugriff dagegen komplizierter. Beim Anlegen eines solchen Chunks wird kein Zeiger auf den neuen Speicherbereich zurückgegeben. Stattdessen wird ein so genannter Handle zurückgeliefert. Die Funktion zum Anlegen eines neuen Speicherbereichs heisst MemHandleNew(). Der Unterschied zwischen Handle und Zeiger ist dabei eher konzeptioneller Natur. Während ein Zeiger immer eine konkrete physische Speicheradresse impliziert, wird über einen Handle eine logische Referenz auf einen Speicherbereich definiert, die unabhängig vom tatsächlichen physischen Speicherort bleibt. Wie zuvor muss auch ein variabler Chunk über MemHandleFree() systemweit bekannt gemacht werden. Um die Größe eines solchen Chunks zu ändern, kann die Funktion MemHandleResize() benutzt werden. Eine Besonderheit beim Zugriff auf variable Speicherbereiche ist die Verwendung von Sperren. Um zu verhindern, dass ein Speicherbereich verschoben oder in seiner Größe geändert wird, während gerade auf ihn zugegriffen wird, muss eine Anwendung die für den Zugriff vorgesehenen Speicherbereiche zunächst sperren, bevor sie

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

dann tatsächlich gelesen werden können. Die Aktivierung solcher Speicherbereichssperren ist dabei nicht mit den ansonsten aus Datenbanksystemen bekannten Sperren zu vergleichen, wo Funktionen in ihren Ausführungsmöglichkeiten beschnitten werden. Hier geht es lediglich darum, Speicherbereiche vor dem Verschieben zu bewahren. Insgesamt können bis zu 16 Sperren (Locks), aktiviert werden. Um einen variablen Speicherbereich zu sperren, muss die Funktion MemHandleLock() verwendet werden. Dieser wird der bereits generierte Handle übergeben. Nur wenn auf einem Speicherbereich keinerlei Sperren gesetzt sind, kann dieser in seiner Größe verändert oder im physischen Speicher verschoben werden. Um einen Speicherbereich wieder zu entsperren, muss die Funktion MemHandleUnlock() verwendet werden.

Entsperren

10.3.2 Ereignisgesteuerte Programmierung Alle Palm-Programme sind ereignisorientiert. Ein Ereignis ist beispielsweise das Drücken einer Schaltfläche oder das Öffnen eines Formulars. Ereignisse besitzen im Normalfall verschiedene Parameter, die bestimmte Informationen über das Ereignis an die das Ereignis interpretierende Methode übergeben. In diesem Fall spricht man von parametrisierten Ereignissen. Um ein Ereignis zu interpretieren und im Sinne einer definierten Programmlogik darauf zu reagieren, muss es jedoch zunächst abgefangen werden. Dazu geht eine Anwendung mit ihrer Initiierung in eine Endlosschleife über. Im Schleifenrumpf wartet dann ein aktives Listener-Objekt auf den Empfang von Ereignissen. In dem Fall, dass das Ereignis StopEvent abgefangen wird, wird die Endlosschleife und mit ihr die Anwendung beendet. Ereignisse besitzen verschiedene Typen. Jeder Ereignistyp kann jeweils nur auf spezifischen Ereignisebenen interpretiert werden. Dabei wird für alle abgefangenen Ereignisse zunächst versucht, diese auf der niedrigsten aller Ereignisebenen zu interpretieren. Kann ein Ereignis auf dieser Ebene nicht interpretiert werden, das heisst eine entsprechende Reaktion in die Wege leiten, wird das Ereignis an die nächst höher gelegene Ebene weitergereicht, die nun ihrerseits versucht, das erhaltene Ereignis zu interpretieren. Mit Hilfe von Ereignisbehandlungsroutinen (auch Ereignishandler genannt) können beliebige Aktionen und Programmablaufstrukturen implementiert werden. Es werden vier Ereignistypen unterschieden:

10.3 Programmierung von Palmtops

Ereignisorientierung

Interpretation von Ereignissen

Ereignistypen, Ereignisebenen

■ ■ ■

289

■

Systemereignisse. Systemereignisse sind Ereignisse, die durch die niedrigste Ereignisebene interpretiert werden und die von Anwendungen nicht direkt abgefangen werden können. Reaktionen auf Systemereignisse werden durch das Betriebssystem definiert und ausgeführt. Das Betriebssystem implementiert dazu den Ereignishandler SysHandleEvent. Beispiele sind StiftEingaben oder das Drücken von Gerätetasten. Nach einer korrekten Ausführung des Quellcodes liefert der Ereignishandler den Wert TRUE zurück und signalisiert dadurch, dass die Reaktion auf das Ereignis abgeschlossen ist. Normalerweise hat ein Entwickler keine Möglichkeit, direkt auf die Programmierung des SysHandleEvent Einfluss zu nehmen. Kann ein Ereignis durch das Betriebssystem nicht interpretiert werden, wird es an die nächst höhere Ereignisebene weitergereicht. In einem solchen Fall ist das abgefangene Ereignis kein Systemereignis.

■

Menüereignisse. Menüereignisse sind Ereignisse, die bei der Navigation in Menüstrukturen ausgelöst werden. Beispiel ist die Auswahl einzelner Menüpunkte. Über den Ereignishandler MenuHandleEvent können entsprechende Reaktionen implementiert werden. Ähnlich wie bei den Systemereignissen muss auch der Ereignishandler MenuHandleEvent zumeist nicht explizit implementiert werden, da der Entwickler keinen Zugriff auf ihn hat.

■

Anwendungsereignisse. Anwendungsereignisse werden durch den Ereignishandler ApplicationHandleEvent interpretiert. Der Unterschied zu den vorherigen Ereignishandlern besteht darin, dass diese Ereignishandler nun erstmals vollständig durch den Anwendungsentwickler implementiert werden. Anwendungsereignisse betreffen ausschließlich die Verwaltung von Anwendungsformularen, das heisst, konkrete Programmablauflogik bzw. Verarbeitungslogik wird an dieser Stelle noch nicht implementiert. Wird beispielsweise ein Ereignis vom Typ frmLoadEvent abgefangen, kann anhand der übermittelten Ereignisparameter die eindeutige Kennung desjenigen Formulars ermittelt werden, welches geladen werden soll. Ist die Kennung bekannt, wird das entsprechende Formular geladen und als aktiv markiert. Dabei ist zu beachten, dass ein Formular erst mit seiner Aktivierung auf dem Display angezeigt wird. Um die eigentliche formularspezifische Programmlogik zu implementieren, wird der Ereignishandler FrmSetEventHandler verwendet. Über diesen können weitere Ereignishandler aufgerufen werden, die für die Implementierung der Geschäftslogik verantwortlich sind.

290

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

■

Formularereignisse. Formularereignisse werden auf einem aktiven Formular ausgelöst. Nach der Beendigung der vorgesehenen Aktion wird TRUE zurückgegeben. Kommt es während der Ereignisbehandlung zu Fehlern, wird das Ereignis automatisch an den standardisierten Ereignishandler FrmDispatchEvent weitergeleitet, der eine fest vorgegebene Fehlerroutine definiert.

Nach der Vorstellung der beiden wichtigsten technischen Randbedingungen – Speichermodell und Ereignisorientierung –, die die Programmierung von Palmtops beeinflussen, werden nachfolgend nun nacheinander die drei bereits angesprochenen Implementierungsvarianten vorgestellt.

10.4 Variante 1: Implementierung in C Als erstes stellen wir die direkt in C programmierte Implementierungsvariante vor. Listing 2 zeigt die Startroutine der Anwendung, die auf Palmtops immer den Namen PilotMain besitzen muss. Die Startroutine stellt den zentralen Einstiegspunkt in den Quellcode der mobilen Datenbankanwendung dar. Der erste Parameter der PilotMain-Funktion (cmd) ist der durch das Palm-Betriebssystem übergebene Startcode der Anwendung. Mit Hilfe eines Startcodes – es existiert eine ganze Reihe an Startcodes – kann einer Anwendung mitgeteilt werden, was der Grund des Programmstarts war, so dass darauf bei Bedarf reagiert werden kann. Startcodes müssen dabei nicht immer direkt durch das Betriebssystem übergeben werden. Alternativ können sie auch durch andere Anwendungen übermittelt werden (man denke an eine Situation, in der Anwendung B aus Anwendung A heraus gestartet wird). Es liegt im Verantwortungsbereich jeder einzelnen Anwendung, ob Startcodes abgefangen werden und wie im Zweifelsfall darauf reagiert wird. Standardmäßig wird der Startcode sysAppLaunchCmdNormalLaunch übermittelt, der das Anklicken des entsprechenden Programm-Icons oder einer Schnellstart-Taste, allgemeiner eines normalen Programmstarts, signalisiert. Die beiden letzten Parameter von PilotMain() übermitteln weitergehende Informationen über den Startcode. Beide Parameter sind aber nur optional und spielen nur in wenigen Ausnahmefällen eine Rolle, die hier nicht weiter betrachtet werden. Die in Listing 2 gezeigte Startroutine der Anwendung kann auch für andere Anwendungen benutzt werden.

10.4 Variante 1: Implementierung in C

PilotMain

■ ■ ■

291

Listing 2

UInt32 PilotMain(UInt16 cmd, void *cmdPBP, UInt16 launchFlags) { // Ereignisvariable EventType event; // Startcode überprüfen if (cmd == sysAppLaunchCmdNormalLaunch) { // Initialisierung der Anwendung StartApplication(); //Endlosschleife für das Ereignisabfangen do { EvtGetEvent(&event, evtWaitForever); // Systemereignisse if (!SysHandleEvent(&event)) { // Anwendungsereignisse if (!ApplicationHandleEvent(&event)) { // Formularereignisse FrmDispatchEvent(&event); } } } while (event.eType != appStopEvent); // Beenden der Anwendung StopApplication(); } return 0; }

Um Ereignisse abfangen und interpretieren zu können, muss zunächst eine Ereignisvariable (EventType event) deklariert werden. Dieser kann dann ein abgefangenes Ereignis zugewiesen werden. Nach dem Start der Anwendung über StartApplication() wird die bereits angesprochene Endlosschleife als Do/While-Schleife initiiert. Innerhalb dieser Endlosschleife werden alle auftretenden Ereignisse abgefangen. Durch das Ereignis appStopEvent wird die Endlosschleife beendet und die Anwendung über die Funktion StopApplication() beendet.

292

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

Der im nachfolgenden Listing 3 abgebildete Code realisiert die Ablaufsteuerung für die Formulare. Nachdem das Anwendungsereignis abgefangen wurde (event->eType == frmLoadEvent), wird das gewünschte Formular geladen. Dazu muss zunächst die eindeutige Kennung des Formulars ermittelt werden (formularID). Ist dies erfolgt, wird das Formular über FrmInitForm() initiiert und mit FrmSetActiveForm() aktiv gesetzt. Über den mit dem geladenen Formular verknüpften Ereignishandler FrmSetEventHandler wird dann die Programmablauflogik implementiert (zum Beispiel, in dem der Ereignishandler HauptFormularFormHandleEvent aufgerufen wird). Boolean ApplicationHandleEvent(EventPtr event) { FormPtr formular; int formularId; Boolean handled; handled=false; if (event->eType == frmLoadEvent) { // Formular-ID ermitteln und Formular initiieren formularId = event->data.frmLoad.formID; formular = FrmInitForm(formularId); FrmSetActiveForm(formular);

Listing 3

// Programmablauflogik switch (formularId) { case HauptFormular: FrmSetEventHandler(formular, HauptFormularFormHandleEvent); break; case AendernFormular: FrmSetEventHandler(formular, AendernFormularFormHandleEvent); break; case DetailFormular: FrmSetEventHandler(formular, DetailFormularFormHandleEvent); break; } handled = true;

10.4 Variante 1: Implementierung in C

■ ■ ■

293

} return handled; }

10.4.1 Datenbankfunktionalität Implementierung von Datenbankfunktionalität

Datenbankentypen

Records

Daten werden auf Palmtops mit Hilfe einfacher Datenbanken persistent im Speicher abgelegt (vgl. Abschnitt 10.3), die durch den Data Manager des Storage Heap verwaltet werden. Der Data Manager besitzt dabei jedoch nicht die Funktionalität eines vollständigen Datenbankmanagementsystems. Zwar können auch auf den PalmDatenbanken einfache Suchoperationen durchgeführt werden, mit den leistungsstarken Abfragesprachen und Suchalgorithmen klassischer Datenbanksysteme ist dies aber nicht vergleichbar. Als vorteilhaft erweist es sich, dass für den Zugriff auf gespeicherte Anwendungsdaten keine gesonderte Ladeoperation notwendig ist, um die Daten in den Arbeitsspeicher zu transferieren. Stattdessen werden die Daten direkt aus dem Storage Heap gelesen und auch direkt wieder in diesen geschrieben. Der Dynamic Heap dient im Gegensatz dazu der ausschließlichen Speicherung temporärer Zwischenergebnisse, die bei der Verarbeitung von Anwendungsdaten anfallen. Grundsätzlich werden zwei Arten von Datenbanken unterschieden [Noe03]: Anwendungsdatenbanken und Ressourcen-Datenbanken. Eine Anwendung besitzt in jedem Fall eine RessourcenDatenbank, in der alle Informationen zu den von der Anwendung genutzten Oberflächenelementen (Schaltflächen, Formulare, Listenelemente, …) abgelegt sind. Anwendungsdatenbanken dienen dagegen der persistenten Ablage von Anwendungsdaten. Da nicht jede Anwendung automatisch Daten generiert, sind Anwendungsdatenbanken optional. Wann immer es aber das Ziel ist, Daten persistent über einen längeren Zeitraum zu speichern ist der Einsatz von Anwendungsdatenbanken obligatorisch. Eine Anwendungsdatenbank besteht aus einer beliebigen Anzahl von logischen Datensätzen, Records genannt. Ein Record selbst wird auf einen oder mehrere Chunks abgebildet. Dabei ist die maximale Größe einer Datenbank lediglich durch den verfügbaren Speicherplatz begrenzt. Jede Anwendungsdatenbank verfügt über einen Datenbank-Header, in dem für die jeweilige Datenbank charakteristische Informationen (Name der Datenbank, Version, CreatorID30, 30 Mit der direkt im Quelltext hinterlegten CreatorID wird die Anwendung identifiziert, die die zugehörige Datenbank angelegt hat. Anwendungen unter Palm-OS können so den gleichen Namen besitzen, die CreatorIDs aller installierten Programme

294

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

Anzahl der gespeicherten Einträge) zusammen mit einer Liste der gespeicherten Records abgelegt sind. Darüber hinaus verfügt jeder Header über zwei beliebig nutzbare Felder AppInfo und SortInfo. Die Verwaltung dieser Liste erfolgt durch das System. In der Liste der Datensätze im Datenbankheader wird jeder Datensatz durch eine physische ID, eine logische LocalID und eine Reihe von Flags repräsentiert. Die physische ID kennzeichnet jeden vorhandenen Datensatz eindeutig und kann nicht verändert werden. Mit der LocalID wird eine von der konkreten Speicheradresse eines Records unabhängige Referenzadresse eines Records bereitgestellt. Das dynamische Mapping der unabhängigen LocalID auf die sich eventuell ändernde physische Adresse eines Datensatzes wird vom Data Manager übernommen. 10.4.1.1 Flags Mit der Hilfe der Flags Busy, Dirty, Delete und Secret kann auf einfache Weise der Zugriff auf einzelne Datensätze gesteuert werden. Flags werden für jeden Datensatz einer Datenbank in der Datensatzliste des Datenbank-Headers gespeichert. Sie werden – als Bestandteil der Datensatzliste – automatisch durch das Palm-Betriebssystem verwaltet. Während die beiden Flags Busy und Secret in ihrer Funktionsweise eher der Zugriffskontrolle zuzuordnen sind, dienen die beiden Flags Dirty und Delete der Koordination von Synchronisationsprozessen. Die genauen Aufgaben der einzelnen Flags sind: ■

Busy-Flag. Wenn das Busy-Flag eines Datensatzes gesetzt ist, findet gerade eine Schreib- bzw. Leseoperation auf dem Datensatz statt. In diesem Fall ist der Datensatz für einen weiteren schreibenden Zugriff gesperrt. Lesezugriffe sind dagegen noch erlaubt. Mit diesem Flag werden Konflikte verhindert, die durch einen gleichzeitigen Zugriff mehrerer Anwendungen bzw. Funktionen auf denselben Datensatz entstehen.

■

Dirty-Flag. Das Dirty-Flag wird bei all denjenigen Datensät-

LocalID

Automatische Verwaltung von Flags

zen gesetzt, die seit dem letzten Synchronisationsvorgang geändert wurden. Diese Änderungen müssen bei der nächsten Synchronisationssitzung berücksichtigt werden. müssen jedoch stets verschieden sein. Wird eine Anwendung installiert, die die gleiche CreatorID wie ein bereits installiertes Programm hat, wird das alte Programm ohne Nachfrage ersetzt, das heisst gelöscht. Um für Anwendungen eine eindeutige CreatorID zu reservieren, kann eine CreatorID in einer zentralen Datenbank bei Palm registriert werden.

10.4 Variante 1: Implementierung in C

■ ■ ■

295

Transaktionen

Datenbank anlegen

Datenbank finden

296

■ ■ ■

■

Delete-Flag. Mit dem Delete-Flag werden Datensätze markiert, die logisch gelöscht wurden. Logisch gelöschte Datensätze müssen bei der nächsten Synchronisationssitzung auch beim Synchronisationspartner gelöscht werden. Erst danach kann der gelöschte Datensatz endgültig physisch entfernt werden.

■

Secret-Flag. Mit dem Secret-Flag werden Records gekennzeichnet, auf die erst nach der zusätzlichen Eingabe eines Passworts zugegriffen werden kann. Das Flag dient somit der Zugriffskontrolle.

Palm-Datenbanken unterstützen keine Transaktionen. Aus diesem Grund sind die Auswirkungen aller durchgeführten Operationen sofort für nachfolgende Operationen sichtbar. Einmal beendete Operationen können dementsprechend in ihren Auswirkungen auch nicht rückgängig gemacht werden. Sollen trotzdem transaktionsähnliche Konzepte realisiert werden, muss die entsprechende Funktionalität, beispielsweise Transaktionsgrenzen, explizit implementiert werden (oder auf ein mobiles Datenbanksystem zurückgegriffen werden). 10.4.1.2 Datenbank-Initialisierung Wird eine Anwendung mit StartApplication() zum ersten Mal auf einem Client gestartet, müssen zunächst alle notwendigen Anwendungsdatenbanken angelegt und initialisiert werden (vgl. Listing 4). Dazu wird auf die Funktion DmCreateDatabase() zurückgegriffen, die insgesamt fünf Parameter erwartet. Der erste Parameter bestimmt die Speicherkarte, auf der eine Datenbank angelegt wird. Die Standardeinstellung ist dabei 0, was bedeutet, dass kein externes Speichermedium, sondern direkt der integrierte Speicher des Palmtops benutzt wird. Über den zweiten Parameter wird ein Datenbank-Name festgelegt, der bis zu 31 Zeichen lang sein darf. Der dritte Parameter ist die bereits angesprochene CreatorID. Der vierte, optionale Parameter spielt für unseren Kontext keine Rolle. Über den fünften und letzten Parameter wird der Typ einer Datenbank spezifiziert (TRUE = Ressourcen-Datenbank, FALSE = normale Datenbank). Vor der Initialisierung einer neuen Datenbank sollte zunächst immer versucht werden, anhand des vorgesehenen Namens und der Funktion DmFindDatabase() eine bereits existierende, gleichnamige Datenbank zu finden. Als Ergebnis der Funktion DmFindDatabase() wird die LocalID (= Datenbanknummer) zurückgegeben (falls

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

eine Datenbank entsprechenden Namens auf der angegebenen Speicherkarte gefunden wurde). Über diese LocalID kann eine Datenbank dann angesprochen werden. Liefert die Funktion stattdessen eine 0 zurück, existiert die Datenbank noch nicht und es kann eine neue angelegt werden. 10.4.1.3 Datenbankprogrammierung Um eine Datenbank zu Öffnen kann die Funktion DmOpenDatabase() verwendet werden. Diese Funktion erwartet als Parameter die Nummer der Speicherkarte, auf der sich die zu öffnende Datenbank befindet, die Datenbanknummer (LocalID), über die die Datenbank angesprochen wird, sowie den Verarbeitungsmodus, in dem die Datenbank geöffnet werden soll. Der Verarbeitungsmodus bestimmt, auf welche Art eine Datenbank geöffnet wird und wie dann auf der Datenbank gearbeitet werden kann: ■

dmModeReadOnly. Öffnet eine Datenbank ausschließlich zum Lesen (Æ Read Only).

■

dmModeWrite. Öffnet eine Datenbank ausschließlich zum Schreiben (Æ Write).

■

dmModeReadWrite. Öffnet eine Datenbank zum Lesen und Schreiben (Æ Read Write).

■

dmModeLeaveOpen. Lässt eine Datenbank auch dann für weitere Zugriffe geöffnet, wenn die zugehörige Anwendung bereits beendet ist (Æ Leave Open).

■

dmModeExclusive. Öffnet eine Datenbank für eine einzige Anwendung. Andere Anwendungen können auf die Datenbank dann nicht zugreifen (Æ Exclusive).

Datenbank öffnen

Kann eine Datenbank nicht im gewünschten Verarbeitungsmodus geöffnet werden, liefert die Funktion DmOpenDatabase() den Wert 0 zurück. void InitDB() { Err fehler=0; // Zunächst Versuch: DB öffnen. // Gelingt dies nicht: neue Datenbank angelegen datenbankNr = DmFindDatabase (speicherkarte, datenbankName);

10.4 Variante 1: Implementierung in C

Listing 4

■ ■ ■

297

if (datenbankNr == 0) // DB nicht vorhanden -> neue DB { fehler = DmCreateDatabase (speicherkarte, datenbankName, 'Adre', 'Data', false); if (fehler) { FrmAlert(DB_Fehler); } else // Nummer der angelegten DB ermitteln { DatenbankNr=DmFindDatabase(speicherkarte, datenbankName); } } // DB öffnen datenbankZeiger = DmOpenDatabase(speicherkarte, datenbankNr, dmModeReadWrite); // Bei erfolgreichem Öffnen der DB Æ DB-Zeiger // Bei Fehler Æ 0 zurück if (datenbankZeiger == 0) FrmAlert(DB_Fehler); }

Um mit einer Datenbank anschließend arbeiten zu können, muss der beim Öffnen einer Datenbank zurückgegebene Zeiger auf die Datenbank abgefangen werden (datenbankzeiger in Listing 4).

Datensätze einfügen

Datensätze ablegen

298

■ ■ ■

10.4.1.4 Einfügen von Datensätzen Neue Datensätze können in eine Datenbank mit der Funktion DmNewRecord()eingefügt werden (vgl. Listing 5). Diese Funktion besitzt drei Parameter. Der erste Parameter ist eine Referenz auf diejenige Datenbank, in die der neue Datensatz eingefügt werden soll, und entspricht der Datenbanknummer. Über den zweiten Parameter wird die genaue Position bestimmt, an der der neue Datensatz physisch geschrieben werden soll. Der dritte Parameter schließlich spezifiziert die Größe des neuen Datensatzes. Neue Datensätze können an beliebiger Stelle im Speicher abgelegt werden, solange der vorgesehene Speicherplatz noch nicht belegt ist. Der über den zweiten Parameter festgelegte physische Speicherort ist dabei keine logische Speicherblocknummer, sondern ein Zeiger auf den gewünschten Speicherort (vgl. Kapitel 10.3.1.1). Dies

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

bedeutet, dass der Funktion DmNewRecord()ein Zeiger übergeben werden muss. Kann ein Datensatz an dem durch einen Zeiger spezifizierten Speicherort tatsächlich angelegt werden, liefert DmNewRecord() einen Datensatzhandler zurück. Auf den Speicherbereich wird über einen aus dem Datensatzhandler generierten Zeiger zugegriffen (recordZeiger). Auch hier wird wieder die zeigerbasierte Programmierung der Palm-Anwendung deutlich. Boolean Speichern(FormPtr formular) { MemHandle recordHandle; feldZeiger = FrmGetObjectPtr(formular, FrmGetObjectIndex(formular, NummerField)); textZeiger = FldGetTextPtr (feldZeiger);

Listing 5

// Nummer ist Primärschlüssel if (textZeiger == NULL) { FrmAlert(NummerEingeben); return false; } else { if (neuerEintrag == true) { // Neuen Datensatz anlegen recordHandle = DmNewRecord(datenbankZeiger, &position, sizeof(Datensatz)); } if (recordHandle == 0) // Fehler beim Anlegen des neuen Datensatzes { FrmAlert(DB_Fehler); return false; } else { einDatensatz.Nummer = StrAToI(textZeiger); // Nachname feldZeiger = FrmGetObjectPtr(formular, FrmGetObjectIndex(formular, NachnameField)); textZeiger = FldGetTextPtr (feldZeiger);

10.4 Variante 1: Implementierung in C

■ ■ ■

299

if (textZeiger != NULL) StrCopy(einDatensatz.Nachname, textZeiger); else StrCopy(einDatensatz.Nachname, "\0"); // Hier folgen weitere Attribute... // Schreiben des Datensatzes recordZeiger = MemHandleLock(recordHandle); DmWrite (recordZeiger, 0, &einDatensatz, sizeof(Datensatz)); // Speicherblock wieder freigeben MemHandleUnlock(recordHandle); // Datensatz wieder freigeben if (neuerEintrag == true) DmReleaseRecord (datenbankZeiger, position, true); else DmReleaseRecord (datenbankZeiger, gewaehlterEintrag, true); } } }

Speicherbereich sperren

Datenstrukturen

300

■ ■ ■

Vor dem Zugriff auf einen variablen Speicherblock (Chunk) ist es stets erforderlich, den Speicherbereich für Zugriffe anderer Anwendungen bzw. Funktionen zu sperren. Dazu wird die Anweisung MemHandleLock() verwendet. Die Struktur zu speichernder Daten spielt keine Rolle, das heisst ein einzelner Datensatz kann aus beliebigen Datenfeldern bestehen. Jedes Datenfeld entspricht einem Datensatzattribut, es ist also mit den Attributen eines Tupels in relationalen Tabellen vergleichbar. Auf die einzelnen Attribute eines Datensatzes kann dann gezielt zugegriffen werden. Bevor ein neuer Datensatz geschrieben werden kann, muss er zunächst im Dynamic Heap aufgebaut werden. Diese Aufgabe fällt jeder mobilen Datenbankanwendung individuell zu. Um einen Datensatz von Grund aufzubauen, werden Zeiger verwendet. Wie in Listing 4 zu sehen ist, verweist die Zeigervariable textZeiger auf die zu speichernden Zeichenketten (Nachname, Vorname, usw.). Im Normalfall werden die Zeichenketten aus Formulareingabefeldern übernommen, die über einen weiteren Zeiger referenziert werden (feldZeiger). Um auf die Formulareingabefelder

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

einer Anwendung zuzugreifen und eingegebene Werte auszulesen, wird die Funktion DmStrCopy() verwendet. Diese besitzt zwei Parameter. Der erste Parameter ist ein Zeiger auf das auszulesende Datenfeld (einDatensatz.Nachname). Der zweite Parameter ist ein Zeiger, dem die aus dem Formulareingabefeld ausgelesene Zeichenkette zugeordnet wird (textZeiger). Um einen im Dynamic Heap aufgebauten Datensatz endgültig in den Storage Heap zu schreiben, wird danach die Funktion DmWrite() benutzt. Der wichtigste Parameter dieser Funktion ist ein Zeiger auf den gewünschten Speicherort. Nach Beendigung einer Schreiboperation müssen die zuvor gesetzten Sperren des geschriebenen Speicherblocks (MemHandleUnlock) und des Datensatzes (DmReleaseRecord) wieder aufgehoben werden. 10.4.1.5 Reines Lesen von Datensätzen Die einfachste Weise, einen bereits existierenden Datensatz aus dem Storage Heap auszulesen, besteht in der Verwendung der Funktion DmQueryRecord(). Diese Funktion erlaubt jedoch kein explizites Suchen eines Datensatzes anhand vorgegebener Suchkriterien; auf den Datensatz wird über dessen LocalID zugegriffen. Ist diese Datensatznummer nicht bekannt, müssen alle vorhandenen Datensätze Schritt für Schritt sequentiell durchlaufen und gegen ein direkt im Programm hinterlegtes (und somit hart kodiertes) Selektionskriterium geprüft werden. Als Ergebnis dieser Funktion wird ein Lesehandler zurückgegeben. Aus diesem muss wiederum ein Zeiger generiert werden, um einen Datensatz auch tatsächlich auslesen zu können. 10.4.1.6 Ändern von Datensätzen Bereits gespeicherte Daten müssen auch geändert werden können (Stichwort: Datenpflege). Um Änderungen auf existierenden Daten durchzuführen, muss zunächst die Funktion DmGetRecord() verwendet werden. Diese ähnelt in ihrer Funktionsweise der bereits vorgestellten Funktion DmQueryRecord(), so dass an dieser Stelle nicht weiter auf sie eingegangen wird. Wiederum muss aus dem zurückgegebenen Handle ein Zeiger generiert werden, um die Daten auslesen zu können. Änderungen eines Datensatzes können dann über die bekannten Funktionen DmStrCopy() und DmWrite() umgesetzt werden.

10.4 Variante 1: Implementierung in C

Datensatz schreiben

Datensatz lesen

Datensatz ändern

■ ■ ■

301

Wurde ein Datensatz statt mit DmGetRecord() über die Funktion DmQueryRecord() ausgelesen, wird eine Änderung durch das PalmBetriebssystem nicht zugelassen. 10.4.1.7 Löschen von Datensätzen Um einen Datensatz zu löschen, können drei verschiedene Methoden eingesetzt werden. In jedem Fall muss vor einer Löschoperation allerdings die betroffene Datenbank mit dem zu entfernenden Datensatz geöffnet werden: ■

DmRemoveRecord(). Der Einsatz der Funktion DmRemoveRecord() bewirkt ein direktes physisches Löschen eines Daten-

satzes, das heisst der von dem Datensatz belegte Speicherplatz wird freigegeben und auch der Datensatzeintrag in der Datensatzliste im Datenbank-Header wird gelöscht. Die nachfolgenden Einträge dieser Liste rücken danach jeweils eine Position auf, damit keine Lücke entsteht. Da ein Datensatz sofort physisch gelöscht wird, besteht allerdings keine Möglichkeit mehr, die Löschoperation bei der nächsten Synchronisation auf der entfernten Datenquelle nachzuvollziehen. Gut geeignet ist die Löschmethode deswegen vor allem für Szenarien, in denen Datensätze gelöscht werden, seit deren Generierung keine Synchronisation stattgefunden hat. ■

DmDeleteRecord(). Der Einsatz der Funktion DmDeleteRecord() bewirkt wie DmRemoveRecord() ein direktes physi-

sches Löschen eines Datensatzes. Der zugehörige Eintrag im Datenbank-Header wird in diesem Fall zunächst jedoch nicht entfernt. Stattdessen erhält er den Wert NULL, was bei einer späteren Synchronisation signalisiert, dass die Löschoperation auch auf dem entfernten Synchronisationspartner nachgezogen werden muss. ■

302

■ ■ ■

DmArchiveRecord(). Im Fall von DmArchiveRecord() wird lediglich das Delete-Flag des Listeneintrags im DatenbankHeader gesetzt. Ansonsten wird der Datensatz weder physisch gelöscht, noch anderweitig verändert. Mit dieser Funktion kann ein Datensatz logisch gelöscht werden, um in einem späteren Synchronisationsprozess als Archivkopie auf dem entfernten Synchronisationspartner abgelegt zu werden. Dazu wird nicht nur der Header-Eintrag eines Datensatzes, sondern der vollständige Datensatz benötigt. Erst nach Beendigung der Synchronisationssitzung wird er dann endgültig gelöscht.

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

Boolean Loeschen(void) { if (FrmAlert(Sicherheitsabfrage)==0) { DmDeleteRecord(datenbankZeiger, gewaehlterEintrag); return (true); } else { return (false); } }

Listing 6

In Listing 6 ist eine Funktion aus dem Quelltext der Beispielanwendung zu sehen, mit der ein gespeicherter Datensatz gelöscht wird.

10.4.2 Programmierung des Conduits Für die Programmierung des Conduits ist die Installation des von Palm bereitgestellten Conduit Development Kit (CDK) notwendig (vgl. Abschnitt 10.3). Conduits werden in C/C++ implementiert. Mit der Installation des CDK werden die Projektvorlagen von Visual Studio .NET um einen Assistenten ergänzt, mit dem schnell und einfach ein Grundgerüst eines Conduits erstellt werden kann. Über den Assistenten können verschiedene Basisoptionen festgelegt werden. Dazu gehören der Typ eines Conduits (Generic, MFC Tables Based, Entry Points Only), die Art der Synchronisation (Two way mirror image synchronization, Upload from the organizer, Download to the organizer, Custom) und die optionale Integration einer Archivierungsfunktion31. Das so erstellte Grundgerüst muss jedoch anhand der individuellen Vorgaben des gewünschten Synchronisationsprozesses angepasst werden. Bei der Ausführung eines Conduits werden nacheinander verschiedene Methoden aufgerufen. Diese Methoden (GetConduitName, GetConduitInfo, GetConduitVersion, OpenConduit und ConfigureConduit) bilden die Ansatzpunkte für Anpassungen des Conduit-Grundgerüstes. Damit ein Conduit auf die zu synchronisierenden Daten zugreifen kann, muss die entsprechende Datenbank zunächst geöffnet werden. Dazu benötigt der Conduit den Daten-

Conduit Development Kit (CDK)

Konfiguration eines Conduits

31

Detaillierte Angaben zu den verfügbaren Einstellungsmöglichkeiten finden sich in der Dokumentation des Conduit Development Kits.

10.4 Variante 1: Implementierung in C

■ ■ ■

303

banknamen und die Nummer der Speicherkarte, auf der die Datenbank zu finden ist. Um Daten zu synchronisieren, werden schließlich die Methoden der C++-Klasse CRawRecordInfo benutzt.

10.4.3 Zusammenfassung Variante 1 Betrachtet man die Entwicklung einer mobilen Datenbankanwendung in der gerade beschriebenen Weise, zeigt sich schnell, dass fast die gesamte Datenbankfunktionalität von Hand programmiert werden muss. Viele klassische Datenbankfunktionen können aufgrund ihrer Komplexität nicht ohne bedeutenden Aufwand integriert werden. So erweist sich der Verzicht auf ein vollfunktionsfähiges Datenbanksystem insbesondere dann als nachteilig, wenn auch weitergehende Datenbankfunktionen wie die Unterstützung von Transaktionen oder Recovery-Mechanismen gewünscht werden. Auch die Programmierung von Synchronisationsmechanismen ist schwierig. Während die Konzeption und Programmierung eines Conduits auf den ersten Blick recht einfach wirkt, erweist sich diese Aufgabenstellung aber bei wachsender Größe des Anwendungsszenarios als äußerst schwierig und komplex. Sollen jedoch nur einfache Datenbankanwendungen erstellt werden, deren Funktionsumfang sich in relativ engen Grenzen bewegt, kann diese Vorgehensweise durchaus adäquat sein. Dabei dürfte es auch ein entscheidender Vorteil sein, dass alle benötigten Werkzeuge entweder von den entsprechenden Unternehmen oder als Opensource-Projekte kostenlos im Internet heruntergeladen werden können. Für die Programmierung von Conduits kann es aber durchaus sinnvoll sein, auf eine der verfügbaren kommerziellen Entwicklungsumgebungen zurückzugreifen. Zwar kann das Grundgerüst eines Conduits sicherlich auch ohne eine solche Entwicklungsumgebung erstellt werden, der durch das CDK bereitgestellte Assistent unterstützt den Entwickler aber doch erheblich.

10.5 Variante 2: Implementierung mit DB2 Everyplace Als Beispiel für die Erstellung einer mobilen Datenbankanwendung mit einem kommerziellen mobilen Datenbanksystem wird jetzt das Anwendungsszenario mit dem Mobile Application Builder (MAB)

304

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

implementiert, der Bestandteil des DB2 Everyplace Software Development Kit (SDK) ist. Der MAB ist eine integrierte Entwicklungsumgebung, mit der Anwendungen schnell erstellt werden können. Einfache Anwendungen (wie die Beispielanwendung) können sogar ohne eine einzige direkt eingetippte Zeile Quellcode erstellt werden. Der durch den MAB erzeugte Quelltext kann aber jederzeit von Hand angepasst und weiter ausgebaut werden. Dadurch wird ein schnelles Prototyping erreicht. Wie zuvor soll für die Palm-Plattform programmiert werden. Der Quellcode der Beispielanwendung besteht ebenfalls wieder aus C-Code. Der Mobile Application Builder benötigt die gleichen Tools, wie sie bereits bei der ersten Implementierungsvariante vorausgesetzt wurden. Damit ist der Mobile Application Builder ein Integrationswerkzeug, das alle für die Programmierung in C erforderlichen Tools (Palm-SDK, Cygwin, PRC-Tools, PilRC) unter einer gemeinsamen Oberfläche zusammenfasst. Darüber hinaus stellt er dem Anwendungsentwickler auch wesentlich weitergehende Funktionalität, vor allem in der Oberflächenentwicklung und im Debuggen zur Verfügung.

Mobile Application Builder

10.5.1 Konfiguration der Synchronisationsarchitektur Durch die ausgefeilten Synchronisationstools des DB2 Everyplace SyncServers wird die Programmierung eines Conduits für die Synchronisationskoordination überflüssig. Zwar entfällt somit die komplexe und schwierige Programmierung eines Conduits, dafür muss jedoch die gesamte Synchronisationsarchitektur von DB2 Everyplace aufwendig konfiguriert werden, sofern später Daten zwischen mobilen Clients und einer DB2-Installation im Backend synchronisiert werden sollen. Die Synchronisationsarchitektur (vgl. Kapitel 9.2) besteht für gewöhnlich aus einem zentralen Datenbankserver (DB2-Installation), einem Synchronisationsserver (DB2 Everyplace SyncServer) und der Datenbankanwendung auf dem mobilen Client (aufsetzend auf DB2 Everyplace). Als Datenbanksystem im Backend können auch andere JDBC-fähige Datenbanksysteme verwendet werden. Alle nachfolgend beschriebenen Konfigurationsarbeiten können über das Mobile Device Administration Center (MDAC) ausgeführt werden. Um eine Synchronisation zwischen der Datenbankanwendung des mobilen Clients und dem Datenbankserver im Backend zu realisieren, muss eine so genannte Subscription angelegt werden. Die Synchronisationsarchitektur basiert auf einem Publish&Sub-

10.5 Variante 2: Implementierung mit DB2 Everyplace

Aufbau der Synchronisationsarchitektur

Subscriptions

■ ■ ■

305

scribe-Modell, bei dem sich mobile Clients mit speziellen Anmeldeverfahren für die Synchronisation mit auf dem Datenbankserver eintragen müssen. Es existieren verschiedene Typen von Subscriptions, im Fall unserer Beispielanwendung wird eine JDBC-Subscription angelegt. Subscriptions definieren die Vorgehensweise für den Abgleich von Daten. Um eine JDBC-Subscription anlegen zu können, müssen zunächst zwei andere Synchronisationsobjekte definiert werden: eine Synchronisationsgruppe und ein Subscription Set. Abb. 10.3: Anlegen einer JDBCSubscription über das MDAC

Synchronisationsgruppe

Subscription Set

Konfiguration der Synchronisation

306

■ ■ ■

Einer Synchronisationsgruppe werden diejenigen Nutzer zugewiesen, die bei der Ausführung eines Synchronisationsvorganges berücksichtigt werden. Einzelne Synchronisationsvorgänge betreffen immer alle in einer Synchronisationsgruppe eingetragenen Nutzer. Ein Subscription Set fasst mehrere Subscriptions logisch zusammen. Damit können die Synchronisationsanforderungen verschiedener DB2 Everyplace-basierender Anwendungen für einen einzelnen Synchronisationsprozess zusammengefasst werden. Die im Falle der Beispielanwendung definierte Subscription Set enthält lediglich eine JDBC-Subscription. Aber auch in einem solch einfachen Fall muss stets ein Subscription Set angelegt werden. Nachdem Synchronisationsgruppe und Subscription Set angelegt sind, kann eine Subscription generiert werden. Dazu muss auf der Registerkarte Identifikation des entsprechenden Dialogs zunächst ein Name vergeben werden. Darüber hinaus können weitergehende Angaben zu den zu synchronisierenden Tabellen bzw. Datenstrukturen gemacht werden. So kann beispielsweise die Anzahl der zu synchronisierenden Datenbanktabellen eingeschränkt werden.

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

Über die Registerkarte Quelle muss danach die Synchronisationsquelle im Backend, in unserem Fall also die DB2-Installation, spezifiziert werden. Die Registerkarte Spiegel dient ergänzend dazu, die Spiegeldatenbank auf dem Synchronisationsserver zu bestimmen. Dabei ist zu berücksichtigen, dass zu synchronisierende Tabellen auf allen beteiligten Instanzen und Zwischeninstanzen (mobiler Client, Synchronisationsserver, Datenbankserver) die gleiche Struktur besitzen müssen. Nur dann kann eine korrekt funktionierende Synchronisation garantiert werden. Die Registerkarte Synchronisationsgruppe erlaubt schließlich die Zuweisung einer Subscription zu einem Subscription Set. Wird der Dialog mit OK beendet, sind alle Konfigurationsarbeiten, die die Synchronisation betreffen, abgeschlossen. Um einen Synchronisationsvorgang durchzuführen, muss der Synchronisationsserver als Dienst gestartet werden (Æ Start Servlet for SyncServer). Über den SyncServer läuft dann der gesamte bei einer Synchronisation anfallende Kommunikationsverkehr ab. Nachdem wir alle notwendigen Konfigurationsarbeiten vorgestellt haben, wenden wir uns jetzt der Anwendungsentwicklung zu.

Start der Servlet-Engine

10.5.2 Anwendungsentwicklung Der strukturelle Aufbau der mit dem Mobile Application Builder erstellten Anwendung ähnelt in weiten Teilen der zuvor programmierten Anwendung. Wie zuvor wird ereignisorientiert programmiert und der Einstiegspunkt in jede Anwendung ist die Funktion PilotMain(). Allerdings wird jetzt das kommerzielle mobile Datenbanksystem DB2 Everyplace verwendet, um Daten persistent und strukturiert auf einem Palmtop zu speichern. Auf in Datenbanktabellen gespeicherte Daten wird dabei über die einfacher zu nutzenden Funktionen des DB2e Call Level Interface und nicht hardwarenah zugegriffen. Bevor die Anwendungserstellung beginnen kann, müssen zunächst die benötigten Zusatztools (Palm-SDK, Cygwin, PRCTools und PilRC) in den Mobile Application Builder eingebunden werden. Dazu reicht es aus, in einem Dialog des MAB die Pfade zu den jeweiligen ausführbaren Programmdateien zu setzen. Um eine neue Anwendung zu erstellen, ist es am einfachsten eine der verfügbaren Projektvorlagen zu benutzen. Eine solche Projektvorlage erlaubt die Spezifikation der wichtigsten Parameter (Projektname, Projektverzeichnis, Anwendungsname, Zielplattform, Entwicklungsverzeichnis) einer Anwendung.

10.5 Variante 2: Implementierung mit DB2 Everyplace

Projektvorlagen

■ ■ ■

307

Natürlich muss DB2 Everyplace auch auf dem mobilen Client (wahlweise auch auf dem Palm-Simulator) installiert werden, um die Datenbankfunktionalität, die auf dem Entwicklungssystem mit der DB2 Everyplace-Installation schon bereit steht, nutzen zu können. Abb. 10.4: Integrierte Entwicklungsumgebung

Aufbau der Entwicklungsumgebung

Projektverwaltung

308

■ ■ ■

Der Mobile Application Builder ist eine integrierte Entwicklungsumgebung, die die Implementierung mobiler Datenbankanwendungen unterstützt. Für eine Installation des Mobile Application Builder muss eine Java-Laufzeitumgebung installiert sein. Der Mobile Application Builder unterstützt die Programmiersprachen C/C++ und Java, nach Integration eines speziellen Plug-Ins auch Visual Basic. Insbesondere durch die Unterstützung mobiler Java-Anwendungen wird ein großer Spielraum an möglichen Einsatzplattformen erreicht. Die Entwicklungsumgebung selbst folgt dem bekannten Aufbau vergleichbarer Produkte. In der Entwicklungsumgebung links oben befindet sich die Projektverwaltung (vgl. Abbildung 10.4). Diese zeigt für das aktuelle Projekt relevante Informationen und Ressourcen. Über den Bereich direkt darunter können Merkmale und Ereignisse der Komponenten gesetzt werden. Eigenschaften betreffen vor allem das Layout (Höhe, Breite, Position, Farbgebung), die Datenanbindung und das Verhalten. So kann einzelnen Formularfeldern beispielsweise sehr einfach der Inhalt eines bestimmten Attributs einer Datenbanktabelle

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

zugewiesen werden. Ereignisse sind ein Ergebnis bestimmter (Inter-) Aktionen, zum Beispiel eine Reaktion auf die Auswahl eines bestimmten Listenwertes. Formulare stellen die Grundeinheiten bei der Gestaltung der Benutzeroberfläche einer Anwendung dar. Jedes Formular füllt den Bildschirm des mobilen Gerätes vollständig aus. Im Zentrum der Entwicklungsumgebung werden alle Formulare des aktuellen Projektes angezeigt. Auf diesen können per Drag & Drop beliebige Bedienungs- und Steuerelemente (auch Kontrollelemente oder Controls genannt) platziert werden. Für eine schnelle Anwendungsentwicklung kann auf eine ganze Bibliothek von Bedienungs- und Steuerelementen zurückgegriffen werden. Auf der rechten Seite der Entwicklungsumgebung sind die verfügbaren Bedienelemente angeordnet. Abhängig vom Typ des geöffneten Projektes (C-, Java- oder Visual Basic-Projekt) stehen nur bestimmte Kontrollelemente zur Auswahl bereit. Die wichtigsten Kontrollelemente für C-Projekte sind: ■

Form Bitmap. Das Form Bitmap zeigt ein Bild bzw. eine Grafik auf einem Formular an.

■

Button. Ein Button dient der Initiierung der Ablaufsteuerung. Mit dem Klick auf einen Button wird eine bestimmte Aktion ausgelöst.

■

Checkbox. Die Checkbox kann dazu benutzt werden, eine exklusive Auswahl über zwei verschiedene boolesche Zustände (Markiert und Unmarkiert) zu setzen.

■

Field. Das Kontrollelement Field zeigt vorhandene Daten an bzw. dient der Eingabe neuer Daten. So können Anzeige- und Eingabemasken aufgebaut werden.

■

Graffiti Shift. Das Graffiti Shift-Kontrollelement erlaubt den Wechsel zwischen Groß- und Kleinschreibung bei der Eingabe von Daten per Stift.

■

Ink. Ink erfasst eine Signatur bzw. Unterschrift als BLOB.

■

Label. Label zeigt einen einzeiligen, nicht zu ändernden Text (Read-Only) an. Dieses Kontrollelement wird vor allem zur Beschriftung bzw. textuellen Aufgabenpräzisierung anderer Elemente verwendet, deren Zweck sich nicht unmittelbar aus ihrer Anordnung erschließen lässt.

■

Pop-Up-Trigger. Der Pop-Up-Trigger erlaubt es einem Nutzer, eine von mehreren Alternativen auszuwählen, die bei Aktivierung eines Kontrollelements in der Form einer heruntergeklappten Liste bereitgestellt werden.

10.5 Variante 2: Implementierung mit DB2 Everyplace

Formulare

Kontrollelemente, Steuerelemente

■ ■ ■

309

Abb. 10.5: Überblick wichtiger Controls

Kompilierung

Aus der Entwicklungsumgebung heraus kann das aktuelle Projekt kompiliert und gestestet werden. Da sich die Anwendungserstellung mit dem Mobile Application Builder fast intuitiv erschließt, wird an dieser Stelle nicht auf weitere Einzeleinheiten eingegangen. Die ausführliche Produktdokumentation bietet hier weitere Informationen.

10.5.3 Zusammenfassung Variante 2 Die Realisierung des gewählten Anwendungsszenarios mit dem Mobile Application Builder zeigt deutlich die Vorteile des Einsatzes eines clientseitigen mobilen Datenbanksystems und einer integrierten Entwicklungsumgebung (wie sie ja schon von der klassischen Anwendungsentwicklung her bekannt sind und somit auch nichts völlig Neues darstellen). Alle notwendigen Teilaufgaben des Entwicklungsprozesses (Erstellung der graphischen Benutzeroberfläche, Erstellung der Datenzugriffsroutinen, Kompilierung, Test usw.) sind unter einer einzigen Oberfläche zusammengefasst. Die Umsetzung des gewählten Beispielsszenarios gestaltet sich denn auch wesentlich einfacher, als die doch recht komplexe Programmierung der ersten Implementierungsvariante. Einige wenige Schwierigkeiten treten allerdings bei der Konfiguration der Synchronisationsarchitektur auf. Gerade am Anfang, ist

310

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

man durch die vielen verschiedenen Begriffe, die im Zusammenhang mit der Synchronisation auftauchen, etwas überfordert. Durch etwas Spielen ändert sich dies jedoch schnell.

10.6 Variante 3: Implementierung mit PointBase Micro Die Implementierung des gewählten Anwendungsszenarios in der Programmiersprache Java mit dem kommerziellen mobilen Datenbanksystem PointBase Micro steht im Mittelpunkt der dritten Variante. Dabei setzt sich die Anwendung aus einer Menge von insgesamt nur 8 Klassen zusammen. Verwendet wird eine Use-Case-orientierte Vorgehensweise, bei der, ausgehend von den geplanten Benutzerschnittstellen der Anwendung, die einzelnen Interaktionsmöglichkeiten schrittweise verfeinert und implementiert werden. Da jede Interaktion aber auch ein Ereignis auslöst, ist diese Vorgehensweise gleichzeitig auch ereignisorientiert. Die Beispielanwendung selbst setzt auf der Connected Device Configuration und dem Personal Profile auf (vgl. Abschnitt 10.2) und fokussiert somit auf den Einsatz auf PDAs. Allerdings kann die Beispielanwendung auch auf allen anderen Clients zur Ausführung gebracht werden, die diese Kombination aus Konfiguration und Profil unterstützen.

10.6.1 Startformular Um die Beispielanwendung zu starten (ein installiertes Java Wireless Toolkit wird an dieser Stelle vorausgesetzt), muss auf der Windows-Kommandozeile in das Installationsverzeichnis der Beispielanwendung gewechselt werden. Über den Befehl run wird das Startformular (vgl. Abbildung 10.5) der Beispielanwendung geladen und auf einem Simulator angezeigt. Der Simulator ist Bestandteil des Wireless Toolkit und wird bei dessen Installation automatisch mit auf dem Entwicklungssystem installiert. Der Befehl run ruft eine Batchdatei auf, die alle notwendigen Schritte für den Anwendungsstart erledigt. Die Batchdatei befindet sich ebenfalls im Heimatverzeichnis der Beispielanwendung. Neben run.bat befindet sich eine weitere Batchdatei im Heimatverzeichnis – make.bat. Diese kann dazu benutzt werden, eine neue ausführbare Datei nach Änderungen im Quellcode zu erzeugen.

10.6 Variante 3: Implementierung mit PointBase Micro

■ ■ ■

311

Abb. 10.6: Startformular der J2MEAnwendung

Einstiegspunkt in den Quellcode ist die Klasse AdressManager, die die Startroutine der Anwendung enthält (vgl. Listing 7). Die wichtigste Aufgabe dieser Klasse besteht darin, das Startformular der Beispielanwendung zu erzeugen, zu initiieren und anzuzeigen. Das Startformular ist eine Instanz der Klasse MainFrame. Listing 7

public static void main(String[] args) { // Anzeigen des Anwendungsfensters new MainFrame().show();

} Die Klasse MainFrame (vgl. Listing 8) wiederum wird von der J2ME-Klasse Frame abgeleitet. Wichtiger Bestandteil der Klasse MainFrame ist die Deklaration von Objektvariablen. Diesen werden im Konstruktor der Klasse Instanzen von Anwendungsformularen und Formularelemente wie Buttons oder Eingabefelder zugewiesen. Listing 8

public class MainFrame extends Frame { // Objektvariablen private Datensatzliste datensatzliste; private EditDialog editDialog; private Suchdialog suchdialog;

312

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

private private private private private private

Button Button Button Button Button Button

addButton; editButton; deleteButton; searchButton; allButton; exitButton;

// Konstruktor public MainFrame() { super("Adressmanager"); // Initiierung der Variablen editDialog = new EditDialog(this); suchdialog = new Suchdialog(this); initUI(); initEventHandler(); } // Methode zur Initialisierung der Oberfläche private void initUI() { int width = 240; int height = 295; setSize(width, height); setResizable(false); DBManager.getInstance().center(this); ... // Hinzufügen der Steuerelemente addButton = new Button("Neu"); addButton.setBounds(170, 30, 58, 25); panel.add(addButton); editButton = new Button("Ändern"); editButton.setBounds(170, 57, 58, 25); panel.add(editButton); } // Methode zur Initialisierung der Anwendungs// logik (Definition der Ereignishandler) private void initEventHandler() { // WindowListener hinzufügen addWindowListener(new WindowAdapter() {

10.6 Variante 3: Implementierung mit PointBase Micro

■ ■ ■

313

public void windowClosing(WindowEvent e) { DBManager.getInstance().disconnect(); System.exit(0); }; // ActionListener addButton.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { if (editDialog.open(null) == true) { Datensatz datensatz=editDialog.getDatensatz(); datensatzliste.addDatensatz(datensatz); } } } ); } // Ende der Methode initEventHandler() } // Ende der Klasse

Im Konstruktor der Klasse MainFrame (vgl. Listing 8) sind zwei wichtige Methodenaufrufe enthalten: initUI() und initEventHandler(). Über die Methode private void initUI()wird die Benutzeroberfläche der Beispielanwendung, die aus den Formularen und Steuer- und Bedienelemente besteht, initialisiert und erzeugt. Über die Methode private void initEventHandler() werden spezielle Ereignishandler definiert, die die Reaktion auf bestimmte Ereignisse implementieren, die von Steuerelementen ausgelöst werden. Als Beispiel ist in Listing 8 die Definition eines Ereignishandlers für einen Button zu sehen (addButton.addActionListener). Wird durch einen Mausklick das dem Button zugeordnete Ereignis ausgelöst, so wird zum Eingabeformular für Datensätze gewechselt.

10.6.2 Datenbank-Programmierung In der Methode initUI() zur Initialisierung der Programmoberfläche (vgl. Listing 8) wird die Klasse DBManager referenziert (DBManager.getInstance().center(this)). Diese Klasse ist für die Koordination aller Datenbankzugriffe verantwortlich. Da diese Funktion im Rahmen unserer Betrachtungen die wichtigste Klasse

314

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

der Beispielanwendung ist, wird die Klasse DBManager deshalb im Folgenden genauer vorgestellt. Bevor auf die Daten einer Datenbank zugegriffen werden kann, muss zunächst eine Verbindung zur gewünschten Datenbank aufgebaut werden. Diese Aufgabe wird in unserer Beispielanwendung durch die Methode connect() realisiert (vgl. Listing 9). Da der Datenbankzugriff bei PointBase Micro über JDBC erfolgt, wird im Folgenden nicht weiter auf Details des Datenbankzugriffs eingegangen, da dieser nach dem bekannten Muster erfolgt. private void connect() { System.out.println("DB-Verbindung..."); Class.forName(driver);

Listing 9

// Neue Datenbank anlegen, wenn noch // keine Datenbank existiert connection = DriverManager.getConnection (url, user, password); statement = connection.createStatement(); System.out.println("DB initialisieren..."); boolean newdb=initDatabase(); System.out.println ("Initialisierungsarbeiten durchführen..."); createStatement(); if(newdb) { System.out.println ("Beispieldaten erstellen..."); // Aufruf des Beispieldatengenerators SampleDataCreator.insert(connection); } }

Besonders interessant in der Methode connect() sind vor allem die beiden Methoden initDatabase()und createStatement(). Während die erste der beiden Methoden die Datenbank initialisiert und benötigte Tabellenstrukturen anlegt (vgl. Listing 10), werden über die zweite Methode eine ganze Reihe vorbereiteter SQLAnfragen definiert (vgl. Listing 11). Diese vorbereiteten Anfragen sind parametrisiert und werden später auf den Daten der zugegriffenen Datenbank ausgeführt.

10.6 Variante 3: Implementierung mit PointBase Micro

■ ■ ■

315

Interessant im Zusammenhang mit der Methode connect() ist weiterhin der Aufruf der Methode insert(connection) der Klasse SampleDataCreator. Die Klasse SampleDataCreator() implementiert, wie der Name schon andeutet, einen Datengenerator, der beim Anlegen der Datenbank der Beispielanwendung diese automatisch mit einigen Datensätzen befüllt. Listing 10

private boolean initDatabase() { String sql = "CREATE TABLE Datensatz (ID INT PRIMARY KEY,Nachname VARCHAR(254)," + "Vorname VARCHAR(254),Firma VARCHAR(254),"+ "Strasse VARCHAR(254),Ort VARCHAR(254),"+ "Telefon_Privat VARCHAR(254),Email VARCHAR(254)," + "Bild Binary(1000000))"; statement.executeUpdate(sql); return true; }

Die Methode private boolean initDatabase() zur Initialisierung der Datenbank (vgl. Listing 10) generiert die Tabellenstrukturen der Beispielanwendung. Dazu wird eine einzige Tabelle Datensatz über die bekannte Create Table-Anweisung von SQL definiert. Die einzelnen Tabellenfelder entsprechen den verfügbaren Adressfeldern der Beispielanwendung. Um die Datenbanktabelle anzulegen, wird die in der String-Variablen sql gespeicherte vorformulierte SQL-Anweisung ausgeführt. Bei einer erfolgreichen Initialisierung wird der boolesche Wert TRUE zurückgegeben. Listing 11

private void createStatement() { insert = connection.prepareStatement( "INSERT INTO Datensatz (ID, Nachname, Vorname, "+ "Firma, Strasse, Ort, Telefon_Privat, Email, "+ "Bild) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?) "); find = connection.prepareStatement( "SELECT * FROM Datensatz WHERE (Nachname LIKE ?) "+ "AND (Vorname LIKE ?) AND (Firma LIKE ?) "+ "AND ((Strasse LIKE ?) OR (Ort LIKE ?)) "+ "AND (Telefon_Privat LIKE ?) AND (Email LIKE ?) "); delete = connection.prepareStatement( "DELETE FROM Datensatz WHERE ID = ? ");

316

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

update = connection.prepareStatement( "UPDATE Datensatz SET ID=?, Nachname=?, "+ "Vorname=?, Firma=?, Strasse=?, Ort=?, "+ "Telefon_Privat=?, Email=?, Bild=? WHERE ID = ? "); }

Die Methode createStatement() (vgl. Listing 11) definiert eine ganze Reihe an parametrisierten SQL-Anfragen: INSERT, UPDATE, DELETE und FIND. Die einzelnen Anfragen implementieren die konkrete Datenbankfunktionalität der Beispielanwendung. Die definierten Parameter, die in den vordefinierten Abfragen durch Fragezeichen symbolisiert sind, werden zur Laufzeit durch konkrete, vom Nutzer vorgegebene Werte ersetzt. Eine weitere wichtige Methode der Klasse DBManager ist void addDatensatz(Datensatz datensatz), die das Anlegen neuer Datensätze erlaubt (vgl. Listing 12). Für das Anlegen eines neuen Datensatzes muss zunächst eine neue ID über die Methode getNewID() generiert werden. Anschließend werden die über die attributspezifischen Get-Methoden (zum Beispiel getNachname()) eingelesenen Werte über die Methode insert.setString() in die Datenbank geschrieben. void addDatensatz(Datensatz datensatz) { datensatz.setID(getNewID()); insert.setInt(1, datensatz.getID()); insert.setString(2, datensatz.getNachname()); insert.setString(3, datensatz.getVorname()); insert.setString(4, datensatz.getFirma()); insert.setString(5, datensatz.getStrasse()); insert.setString(6, datensatz.getOrt()); insert.setString(7, datensatz.getTelefon_Privat()); insert.setString(8, datensatz.getEmail()); insert.setBytes(9, datensatz.getBild().getBytes()); insert.executeUpdate(); }

Listing 12

Um einen gespeicherten Datensatz zu löschen, implementiert die Klasse DBManager die Methode deleteDatensatz() (vgl. Listing 13). Einzige Voraussetzung einer solchen Operation ist die Kenntnis der eindeutigen ID des zu entfernenden Datensatzes. void deleteDatensatz(Datensatz datensatz) { delete.setInt(1, datensatz.getID()); delete.executeUpdate(); }

10.6 Variante 3: Implementierung mit PointBase Micro

Listing 13

■ ■ ■

317

Nachdem nun die wichtigsten Methoden der Klasse DBManager vorgestellt wurden, gehen wir – gemäß unserer Use-Case-orientierten Vorgehensweise – zum Suchformular über, um damit die Beschreibung der Java-Beispielanwendung abzuschließen.

10.6.3 Suchformular Das Suchformular (vgl. Abbildung 10.7) stellt dem Nutzer zwei verschiedene Möglichkeiten zur Verfügung eine Suchabfrage auf der Adressdatenbank abzusetzen. Einerseits kann anhand konkreter Suchbegriffe eine weitgehend automatische Suche initiiert werden. Andererseits kann der WHERE-Teil einer SQL-Anfrage auch direkt in SQL-Syntax formuliert werden. Abb. 10.7: Such-Dialog

Dazu muss der Nutzer allerdings die durch die Anwendung zugegriffenen Datenbankstrukturen genau kennen. Als Ergebnis werden einzelne oder mehrere Datensätzen zurückgegeben. Über einen Radio-Button kann zwischen beiden Varianten für Suchabfragen gewechselt werden. Die Ausführung einer Suchanfrage unter Verwendung der Eingabefelder für Suchbegriffe (Variante 1) erfolgt über die Methode findNameCardsbyKeyword(). Über eine FOR-Schleife werden zunächst die in die Suchfelder eingetragenen Suchparameter bestimmt.

318

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

Als Eingabeparameter erwartet die Methode (vgl. Listing 14) die Menge der eingegebenen Suchbegriffe. Die eingegebenen Suchparameter ersetzen in der vorbereiteten SQL-Anfrage find (vgl. Listing 11) die definierten Parameter. Das Ergebnis ist eine Liste mit den gefundenen Datensätzen. Vector findNameCardsByKeyword(String nachname, String vorname, String firma, String strasse, String ort, String email) {

Listing 14

Vector NameCards = new Vector(); // Vektor zur Speicherung der Ergebnismenge String[] keywords = {nachname, vorname, firma, strasse, ort, , email}; for (int i = 0; i < keywords.length; i++) { String criteria = (keywords[i].equals("")) ? "%" : "%" + keywords[i] + "%"; find.setString(i + 1, criteria); } ResultSet resultSet = find.executeQuery(); while (resultSet.next()) { Datensatz datensatz = new Datensatz( resultSet.getInt(1), resultSet.getString(2), resultSet.getString(3), resultSet.getString(4), resultSet.getString(5), resultSet.getString(6), resultSet.getString(7), resultSet.getString(8)); if (!delay) loadBild(datensatz); NameCards.addElement(datensatz); } return NameCards; }

Die Ausführung einer direkt in SQL formulierten Anfrage (Variante 2) erfolgt über die Methode findNameCardsbySQL(). Als Eingabe-

10.6 Variante 3: Implementierung mit PointBase Micro

■ ■ ■

319

parameter erwartet diese Methode (vgl. Listing 15) die SQL-Anfrage als Zeichenkette. Ausgeführt wird die Anfrage in der üblichen Weise unter Verwendung eines Statement-Objekts. Als Ergebnis liefert sie eine Liste mit allen ermittelten Datensätzen zurück, die einem Objekt des Typs ResultSet zugewiesen werden. Listing 15

Vector findNameCardsBySQL(String sql) { Vector NameCards = new Vector(); ResultSet resultSet = statement.executeQuery("SELECT ID, Nachname,"+ "Voname, Firma, Strasse, Ort, Telefon_Privat,"+ "Email FROM Datensatz WHERE sql); while (resultSet.next()) { Datensatz datensatz = new Datensatz(resultSet.getInt(1), resultSet.getString(2), resultSet.getString(3), resultSet.getString(4), resultSet.getString(5), resultSet.getString(6), resultSet.getString(7), resultSet.getString(8)); if (!delay) loadBild(datensatz); NameCards.addElement(datensatz); } return NameCards; }

Synchronisation

Um Synchronisationsmechanismen zu implementieren, stellt PointBase Micro das PointBase UniSync API zur Verfügung. Mit diesem kann das bereits in Kapitel 9.6 beschriebene Publish&SubscribeVerfahren mit Hubs und Spokes umgesetzt werden.

10.7 Zusammenfassung der Implementierungsvarianten Die Konzeption und die Programmierung (inklusive der zugehörigen Synchronisationsverfahren) haben erhebliche Unterschiede bei der Vorgehensweise und der Komplexität der drei Implementierungsva-

320

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

rianten gezeigt. In diesem Abschnitt wird daher abschließend ein kurzer Vergleich der drei realisierten Implementierungsvarianten der Beispielanwendung durchgeführt. Der wichtigste Unterschied zwischen den drei Beispielanwendungen ist die Art und Weise der Implementierung der Datenbankfunktionalität. Während die erste C-Anwendung die gesamte Datenbankfunktionalität direkt zu Fuß und ohne den Rückgriff auf ein mobiles Datenbanksystem implementiert, wird bei der zweiten Beispielanwendung die mobile Datenbankanwendung an ein eigenständiges mobiles Datenbanksystem angebunden (DB2 Everyplace). Die dritte Beispielanwendung stellt einen weiteren Spezialfall dar, da hier zwar ebenfalls ein mobiles Datenbanksystem benutzt wird, dieses jedoch direkt in die Anwendung hineinkompiliert wird. Das mobile Datenbanksystem existiert als eigenständiges Modul nicht mehr.

Kernunterschied

10.7.1 Variante 1: C-Anwendung Im Falle der ersten Implementierungsvariante wird bei der persistenten Speicherung von Anwendungsdaten, bedingt durch das von Palm-OS unterstützte Speichermodell, auf einfache Datenbanken zurückgegriffen. Grundlegende Funktionen zum Öffnen und Schließen von Datenbanken, wie auch Methoden zum Arbeiten mit Datensätzen, werden über die Palm-Programmierschnittstelle bereitgestellt. Bereits die Durchführung komplexerer Suchoperationen auf bestehenden Datenbeständen wird jedoch nicht mehr unterstützt. Um einen Datensatz anhand eines bestimmten Suchkriteriums zu suchen, müssen alle existierenden Datensätze sequentiell durchlaufen werden. Die Überprüfung auf Übereinstimmung eines Datensatzes mit dem definierten Suchkriterium muss dabei direkt im Quelltext hinterlegt werden. Eine deskriptive Anfragesprache wie SQL wird nicht unterstützt. Die sehr hardwarenahe Programmierung führt darüber hinaus sehr schnell zu einer großen Komplexität in der Entwicklung. Die Programmierung der graphischen Oberfläche gestaltet sich ebenfalls schwierig. Die Einbindung und Konfiguration verfügbarer Elemente über externe Ressourcen-Dateien ist nicht nur zu Beginn schwierig. Auch Transaktionssicherheit, ein wichtiges Kriterium für einen Einsatz in realistischen Produktionsumgebungen, wird nicht direkt unterstützt. Über die Programmierung von Conduits können beliebig komplexe Synchronisationsverfahren implementiert werden. Die Verfügbarkeit eines entsprechenden Entwicklerbaukastens (Conduit Development Kit) lässt die Programmierung eines Conduits zunächst

10.7 Zusammenfassung der Implementierungsvarianten

■ ■ ■

321

denn auch recht einfach erscheinen. Sehr schnell können jedoch durch die komplexen Möglichkeiten der Programmierung enorme Schwierigkeiten auftreten. Um Fehler schnell und effizient beseitigen zu können, wird mit dem Conduit Development Kit eine spezielle Entwicklerversion des HotSync-Programms mit einem leistungsfähigen Debugger bereitgestellt, welche das normale HotSync während der Conduit-Entwicklung ersetzen kann. Ein weiterer Vorteil der ersten Implementierungsvariante ist, dass die Entwicklung mobiler Anwendungen keine finanziellen Aufwendungen verursacht. Alle benötigten Entwicklungswerkzeuge sind kostenlos im Internet zum Download verfügbar. Natürlich existiert auch eine ganze Reihe kommerzieller Tools, mit denen einzelne oder mehrere Aufgaben effizienter durchgeführt werden können. Die Installation der benötigten Entwicklungswerkzeuge gestaltet sich teils aufwendig und fehleranfällig. Insbesondere die Installation und Verwendung der emulierten Unix-ähnlichen Kommandozeile (Cygwin) führen gerade am Anfang zu einigen Verwirrungen. Nachdem die ersten Hürden aber gelöst sind, können alle Tools (relativ) einfach eingesetzt werden.

10.7.2 Variante 2: DB2 Everyplace Bei der mit dem mobilen Datenbanksystem DB2 Everyplace realisierten Implementierungsvariante zeigt sich schnell der enorme Komfort und die hohe Effizienz bei der Entwicklung mobiler, datenbankgestützter Anwendungen. Die Anwendungsentwicklung ähnelt dabei stark der Entwicklung herkömmlicher Anwendungen mit graphischen Entwicklungsumgebungen (wie Visual Studio .NET). So ist es möglich, eine voll funktionsfähige, wenn auch nur einfach strukturierte mobile Datenbankanwendung zu erstellen, ohne eine einzige Zeile Programmcode von Hand zu tippen. Gerade die Verfügbarkeit einer speziellen Entwicklungsumgebung, die die effiziente Konzeption und Realisierung mobiler, datenbankgestützter Anwendungen unter einer einheitlichen Oberfläche erlaubt, ist ein immenser Vorteil gegenüber der direkten Implementierung der Anwendung. Auch die Synchronisation gestaltet sich extrem einfach. Der Aufruf eines speziellen, ebenfalls in DB2 Everyplace integrierten Synchronisationstools reicht dazu aus. Der Einsatz von DB2 Everyplace bringt jedoch auch einige Schwierigkeiten mit sich. Da der MAB zur Anwendungsentwicklung auf die bereits vorgestellten Zusatztools (Palm-SDK, PRC-Tools, Cygwin, usw.) zurückgreift, müssen nach der Installation des Mobile Application

322

■ ■ ■

10 Konzeption und Realisierung einer mobilen Datenbankanwendung

Builders diese Werkzeuge zunächst eingebunden werden. Zwar existiert für diese Aufgabe ein entsprechender Dialog, in dem lediglich die Pfade zu den jeweiligen Programmdateien einzutragen sind, doch kann dies, gerade wenn beispielsweise mehrere Versionen von Cygwin oder den PRC-Tools installiert sind, zu Irritationen führen. Komplex ist darüber hinaus auch die Konfiguration der notwendigen Infrastruktur, womit dies insbesondere für die Konfiguration des Synchronisationsservers und der Synchronisationsquellen im Backend gilt. Letztlich ist der Einsatz von DB2 Everyplace aber vor allem eine Frage der Investitionsbereitschaft, schlägt doch eine vollständige Installation, bestehend aus mobilem Datenbanksystem und Synchronisationsserver mit über 15.000,- Dollar zu Buche. Lizenzen für DB2Installationen sind hierbei noch nicht berücksichtigt.

10.7.3 Variante 3: PointBase Micro Im dritten Anwendungsszenario wird die Beispielanwendung mit dem kommerziellen mobilen Datenbanksystem PointBase Micro implementiert. Zwar existiert keine spezielle Entwicklungsumgebung wie der Mobile Application Builder, es kann jedoch auf beliebige Java-IDEs, beispielsweise Eclipse, zurückgegriffen werden. Java-Programmierer werden kaum Schwierigkeiten haben, schnell ansprechende Ergebnisse zu erzielen. Die Einbindung der Datenbankfunktionalität folgt weitgehend bekannten Prinzipien und gestaltet sich somit recht einfach. Lediglich die Programmierung der Benutzeroberfläche erweist sich als aufwendig, da Steuer- und Bedienelemente direkt im Quellcode definiert und entsprechend entworfen werden müssen. Eine bessere Unterstützung bei der Gestaltung der Oberfläche wäre wünschenswert. Insbesondere nachdem jederzeit auf andere kommerzielle Entwicklungswerkzeuge ausgewichen werden kann, die einen entsprechenden Editor für die Oberflächenerstellung gleich mitbringen (beispielsweise Metrowerks CodeWarrior). Die anfallenden Kosten für den Aufbau einer kompletten Infrastruktur sind um einiges günstiger als mit den entsprechenden IBMProdukten. Für die Integration mobiler Anwendungen in bereits bestehende J2EE-Anwendungen ist PointBase Micro ein guter Kandidat. Während PointBase Micro also vor allem diesbezüglich punktet, ist DB2 Everyplace durch die Verfügbarkeit des MAB gerade für schnelles Prototyping sehr gut geeignet.

10.7 Zusammenfassung der Implementierungsvarianten

■ ■ ■

323

11 JDBC Optional Package für Java 2 Micro Edition

Auf mobilen Clients werden mobile Datenbanksysteme installiert, um Daten lokal zu speichern, zu verwalten und diese unabhängig von einer bestehenden Verbindung zu einer entfernten Datenbank zu bearbeiten. Um auf ein solches Datenbanksystem zugreifen zu können, stellen die Standardprofile der Java 2 Micro Edition (J2ME) standardmäßig allerdings keine Funktionen bereit. Will man trotzdem aus einer mobilen J2ME-Anwendung heraus auf relationale Datenbanken zugreifen, kann – wie bei herkömmlichen Datenbanksystemen auch – auf JDBC (Java Database Connectivity) zurückgegriffen werden. Das JDBC Optional Package, die mobile und leichtgewichtige Variante der herkömmlichen JDBCSchnittstelle steht deswegen im Mittelpunkt dieses Kapitels.

Motivation

11.1 Grundlagen Aufgrund der geringen physischen Leistungsfähigkeit vieler mobiler Clients (gemeint sind in diesem Fall klassische J2ME-Clients wie beispielsweise PDAs) ist die klassische JDBC-Schnittstelle mit ihrer mächtigen und umfangreichen Funktionalität viel zu groß. Für den Zugriff auf relationale Datenbanksysteme ist deswegen eine immer noch relativ mächtige, aber wesentlich schlankere Untermenge der JDBC-Schnittstelle (also von Klassen der Pakete java.sql und javax.sql) definiert worden. Diese Untermenge wird als J2ME JDBC Optional Package (JDBC OP) bezeichnet. Optional, da das Paket standardmäßig nicht Teil der J2ME ist. Die Entwicklung dieser leichtgewichtigen Alternative ist im Java Specification Request 169 dokumentiert. Eine Referenzimplementierung von Sun Microsystems existiert aktuell jedoch noch nicht. Lediglich eine Schnittstellenbeschreibung steht zur Verfügung, die von Herstellern dazu benutzt werden kann, eigene Implementierungen der Spezifika-

11.1 Grundlagen

Entstehung

■ ■ ■

325

tion zu realisieren. Um das JDBC Optional Package nutzen zu können, muss eine Anwendung mindestens die technischen Anforderungen der Connected Device Configuration erfüllen. Die Connected Limited Device Configuration unterstützt das leichtgewichtige JDBC dann allerdings schon nicht mehr.

11.2 Details Vergleich zu JDBC 3

Das schlanke JDBC-API unterstützt die wichtigsten Funktionen, wie sie auch das klassische JDBC unterstützt. Aufgrund der speziellen Anforderungen der Connected Device Configuration muss jedoch auf einige Funktionen verzichtet werden, die allerdings auf mobilen Clients sowieso nicht sinnvoll einsetzbar sind. Die wichtigsten nicht mehr unterstützten Einschränkungen sind: ■

Connection Pooling. Unter Connection Pooling versteht man die Wiederverwendung physischer Datenbankverbindungen. Da der Aufbau einer Datenbankverbindung eine relativ ressourcenintensive Operation darstellt, ist es besser, eine Datenbankverbindung im Server nicht sofort zu schließen, wenn ein Client seine Arbeit beendet hat. Sie kann gespeichert und für nachfolgende Client-Zugriffe wiederverwendet werden. Connection Pooling in JDBC 2.0 stellt dem Entwickler genau diese Funktionalität zur Verfügung.

■

Das Interface DriverManager zum Aufbau von Verbindungen zu einer Datenbank wird durch das Interface DataSource ersetzt. Dieses minimiert den Aufwand beim Verbindungsaufbau. Zusammen mit dem Interface DriverManager werden auch die Interfaces Driver und DriverPropertyInfo entfernt.

■

Das Interface ParameterMetaData wird nicht mehr unterstützt.

■

Die Möglichkeit, Parameter in gespeicherten Prozeduren anhand eines Namens im Interface CallableStatement zu setzen, wird nicht mehr unterstützt.

■

Folgende SQL99-Datentypen werden nicht mehr unterstützt: Struct, Array, Ref, SQLData, SQLInput, SQLOutput.

■

Nutzerdefiniertes Typ-Mapping über die Methoden setTypeMap() und getTypeMap() wird nicht mehr unterstützt.

Um eine Datenbankverbindung aufzubauen, wurde mit Version 2 der klassischen JDBC-Programmierschnittstelle das Interface Data-

326

■ ■ ■

11 JDBC Optional Package für Java 2 Micro Edition

Source eingeführt. Im Vergleich zum Verbindungsaufbau über die ursprüngliche Methode unter Verwendung des DriverManager, der das Laden eines JDBC-Treibers und eine Datenbankadresse in Form einer URL voraussetzt, vereinfacht dies den Datenbankzugriff deutlich. Das folgende Beispiel zeigt den Aufbau einer Datenbankverbindung über das Interface DataSource. Das Interface wird dabei durch eine herstellerspezifische Klasse BeispielDataSource implementiert:

Beispiel

BeispielDataSource ds = new BeispielDataSource(); ds.setServerName("adressdatenbank"); ds.setPortNumber(5000); Connection connection = ds.getConnection("username", "password");

Im Folgenden wird ein kompakter Überblick über die Interfaces und Klassen des JDBC Optional Packages gegeben. Interfaces, die vom Paket java.sql geerbt werden, sind: Interfaces BLOB CallableStatement CLOB Connection PreparedStatement ResultSet ResultSetMetaData Savepoint Statement

Erklärung Implementiert ein BLOB (Binary Large Object). Zur Ausführung gespeicherter SQL-Prozeduren (SQL Stored Procedures). Definiert ein CLOB (Character Large Object). Definiert eine Datenbankverbindung. Definiert eine vorkompilierte SQL-Anfrage. Ergebnistabelle, die nach der Ausführung einer SQLAnfrage zurückgegeben wird. Informationen über Typen und Eigenschaften der Spalten in einem Objekt des Typs ResultSet. Frei wählbarer Sicherungspunkt in einer Transaktion, der über Connection_Rollback angesprungen werden kann. Ausführung einer SQL-Anfrage.

Unterstützte Features

Tab. 11.1

Klassen, die vom Paket java.sql geerbt werden, sind: Klassen Date Time Timestamp Types

Erklärung Definiert den SQL-Wert DATE. Definiert den SQL-Wert TIME. Definiert den SQL-Wert TIMESTAMP. Definiert Konstanten, die generische SQL-Typen implementieren (JDBC-Typen).

Tab. 11.2

Exceptions, die vom Paket java.sql geerbt werden, sind:

11.2 Details

■ ■ ■

327

Tab. 11.3

Exceptions BatchUpdateException DataTruncation SQLException SQLWarning

Erklärung Wird erzeugt, wenn ein Fehler während einer Batch Update-Operation auftritt. Wird erzeugt, wenn JDBC unerwarteterweise einen Wert bei einer Lese- oder Schreiboperation abschneidet. Stellt Informationen zur Verfügung, die Auskunft über den abgefangenen Fehler geben. Stellt Informationen zur Verfügung, die Auskunft über die abgefangenen Warnungen geben.

Das JDBC Optional Package erbt jedoch nicht nur Klassen und Interfaces vom Paket java.sql. Das Paket javax.sql definiert weitere Programmierschnittstellen, beispielsweise das DataSourceInterface für den Datenbankzugriff oder Methoden für die Manipulation von Tabellenstrukturen über JavaBeans. Interfaces und Klassen, die vom Paket javax.sql geerbt werden, sind: Tab. 11.4

Klassen/Interfaces DataSource

RowSet RowSetInternal RowSetListener

RowSetMetaData RowSetReader RowSetWrite RowSetEvent

Erklärung Kann anstelle des DriverManager benutzt werden. Repräsentiert eine Generatorklasse für Verbindungen zu Datenbanken. Erweitert die JDBC API um das Komponentenmodell der JavaBeans. Wird durch ein RowSet-Objekt implementiert. Wird von einer Komponente implementiert, die bei einem Ereignis in einem RowSet-Objekt darüber informiert werden möchte. Implementiert ein Objekt, das Informationen über die Spalten eines RowSet-Objekts enthält. Implementiert ein Leseobjekt. Implementiert ein Schreibobjekt. Implementiert ein Ereignisobjekt, das instantiiert wird, wenn auf einem RowSet-Objekt ein Ereignis eintritt.

Es wird deutlich, wie mächtig selbst die leichtgewichtige JDBCSchnittstelle noch immer ist. Alle wichtigen Funktionen für den Zugriff auf relationale Datenbanken sind nach wie vor vorhanden. Lediglich einige sehr spezielle, in den Anwendungsszenarien von mobilen Clients vernachlässigbare Interfaces, Klassen und Methoden werden nicht mehr unterstützt.

328

■ ■ ■

11 JDBC Optional Package für Java 2 Micro Edition

12 Ausblick

Die technologischen Fortschritte im Mobile Computing sind enorm. Betrachtet man die technische Entwicklung mobiler Endgeräte in den letzten drei Jahren und geht man weiterhin davon aus, dass dieses Wachstumstempo noch einige Jahre anhält (und alle tun das), so sind die sich ergebenden Möglichkeiten derzeit nicht abschätzbar. So werden sich neue Felder und Märkte öffnen. Vor allem datenbzw. bandbreitenintensive Multimediadienste und -anwendungen rücken dabei verstärkt in den Vordergrund. Gerade für die Nutzung multimediaorientierter Anwendungen ist jedoch die Entwicklung neuer mobiler Geräteklassen notwendig, die die technischen Fähigkeiten mitbringen, sehr viele verschiedene Anwendungen in einem einzigen Client bereitzustellen. Eine besondere Rolle kommt deswegen den hybriden Endgeräten zu.

Technologischer Fortschritt

Das Ziel bei der Entwicklung von hybriden Endgeräten ist die Integration der Fähigkeit zur Verarbeitung von Fernsehsignalen in einen mobilen Client. So soll ein mobiles Endgerät nicht nur aus dem Mobilfunk stammende Übertragungstechnologien, sondern auch drahtlose Netzwerktechnologien wie Wireless-LAN oder Bluetooth, vor allem aber digitale Rundfunk- und TV-Signale nutzen können. Zwar sind dies alles bereits existierende, größtenteils auch ausgereifte Technologien. Was jedoch noch fehlt, ist die Definition einer neuen, alle Technologien integrierenden Softwarearchitektur. So erfordert beispielsweise die Verarbeitung digitaler Audio- oder TVSignale eine zusätzliche, von den anderen Hardwarekomponenten weitgehend unabhängige Prozessorarchitektur mit Tuner- und Demulatorfunktionen. Die Kopplung aller oben genannten Fähigkeiten in einem einzigen hybriden Gerät erfordert somit hochintegrierte Komponenten. Diese sind aktuell jedoch noch nicht in Stückzahlen produzierbar, wie sie für die Massenfertigung benötigt werden. Als besonders problematisch erweist sich dabei insbesondere der hohe Energieverbrauch der jetzigen Gerätegeneration. In hybriden

Mobile hybride Endgeräte

12 Ausblick

Integration von TV-Fähigkeiten

■ ■ ■

329

Geräten nach unserer obigen Definition verschärft sich dieses Problem durch die duale Prozessorarchitektur und die notwendige Signalumwandlung noch weiter. Wann die erste Generation echter mobiler Hybridgeräte verfügbar sein wird, ist derzeit noch nicht absehbar. Gerade aber die großen Mobilfunker wie Vodafone oder die Ausrüster wie Nokia arbeiten fieberhaft an Mobilgeräten, die TV-tauglich sind. Mit der Einführung mobiler Fernsehcomputer mit integriertem Browser ist aber nicht vor ca. 2008 zu rechnen. Sicherheit in mobilen Umgebungen

Nutzerakzeptanz

Ein noch weitgehend ungelöster Punkt ist auch die Sicherheit der mobilen Geräte. Vor allem Systemadministratoren befürchten, dass über nicht adäquat gesicherte mobile Clients Viren, Würmer sowie Hacker einen leicht nutzbaren Weg ins eigene Unternehmensnetzwerk finden. Zwei wichtige Gründe für diese Befürchtungen sind: ■

Es existiert oft kein zentrales Antivirus- und Patch-Management, das eine schnelle Reaktion auf neue Bedrohungssituationen ermöglichen würde (mangelnde Unterstützung des Systemmanagements).

■

Es fehlt schlicht an Sicherheitsschranken, egal ob diese in Hardware oder Software implementiert sind.

Ein weiterer wichtiger Problembereich ist die Akzeptanz neuer mobiler Anwendungen durch die Nutzer. Eine solche mangelnde Akzeptanz hat ihre Gründe vor allem in unzuverlässigen und veralteten Geräten, aber auch in technologischen Unsicherheiten, was die Zukunftsaussichten neuer Technologien anbelangt. Man denke diesbezüglich nur an die Einführung von UMTS in Deutschland. Im gleichen Zusammenhang ist die Motivation der Mitarbeiter zu sehen, die neue mobile Technologie innerhalb bereits existierender Geschäftsprozesse verwenden sollen. Weitere Problemfelder sind: ■

Mangel an Überwachung und Möglichkeiten zur Fernsteuerung

■

geringe Übereinstimmung mit Prozessen und unternehmensweit festgelegten Richtlinien (Policies)

Von besonderer Bedeutung erweist sich zudem das Vorhandensein einer nachhaltigen und nachvollziehbaren Strategie bei der Einführung von mobilen Geräten und zugehöriger Anwendungen. So starten IT-Abteilungen mobile Projekte sehr oft als Versuchsballon und sind anschließend mit den ausufernden Anforderungen und Wünschen der Nutzer überfordert. Gerade durch wohldurchdachte mobile

330

■ ■ ■

12 Ausblick

Strategien kann eine solche Situation jedoch unter Kontrolle gebracht werden. Als eines der Hauptprobleme kann die Vernachlässigung von Möglichkeiten zur Erweiterung neuer mobiler Anwendungen angesehen werden. In vielen Projekten wird einfach ein bestimmter Geschäftsprozess isoliert herausgegriffen, um für diesen – isoliert von anderen korrelierten Geschäftsprozessen – dann eine unterstützende Anwendung zu implementieren. Die Erweiterung von Anwendungen zu einem späteren Zeitpunkt ist jedoch enorm wichtig, damit Infrastrukturen mit einer steigenden Nutzeranzahl skalieren bzw. an neue Anforderungen angepasst werden können. Am Ende des Entwicklungsprozesses steht dann eine proprietäre Anwendung, für die oft nur ein bestimmter Typ eines mobilen Gerätes eingesetzt werden kann, ohne dass wirkliche Planungssicherheit und Zukunftsfähigkeit gegeben ist. Doch einige wenige Unternehmen oder IT-Abteilungen setzen bereits auf eine durchgehende, konsistente Strategie bei der Integration mobiler Anwendungen in unternehmensweite IT-Infrastrukturen. So geht eine aktuelle Gartner-Studie davon aus, dass es noch mindestens drei Jahre dauert, bis Unternehmen mobile und auch drahtlose Technologien als selbstverständlichen Baustein übergeordneter strategischer Initiativen akzeptieren. Aktuell berücksichtigt erst ein Drittel aller Unternehmen in Deutschland mobile Geräte im Rahmen ihrer IT-Strategie. Für die Integration mobiler Geräte kann der folgende, grobe Leitfaden verwendet werden: ■

Schritt 1: Erfassung mobiler Geräte. In einem ersten Schritt muss abgeklärt werden, welche mobilen Geräte überhaupt im Unternehmen eingesetzt werden bzw. überhaupt eingesetzt werden dürfen. Sehr oft ist heute in Unternehmen die Situation anzutreffen, dass Mitarbeiter eigene Geräte mitbringen und deren Anwendungen isoliert von Kollegen nutzen.

■

Schritt 2: Erfassung mobiler Anwendungen. In einem zweiten Schritt muss abgeklärt werden, für welche Anwendungen es überhaupt einen Sinn ergibt, auf mobilen Geräten ausgeführt und in größere Geschäftsprozesse eingebunden zu werden. Interessant sind diesbezüglich alle Anwendungen des Personal Information Managements (PIM), also die mitarbeiterübergreifende Nutzung von Kontakten, Terminen und Notizen. Diese Anwendungen werden auch als Groupware-Applikationen bezeichnet.

12 Ausblick

Erweiterungsfähigkeit mobiler Anwendungen

Leitfaden für mobile Projekte

■ ■ ■

331

■

Schritt 3: Pilotprojekt. Nachdem die ersten beiden Punkte abgeklärt wurden, ist es sinnvoll, ein erstes, unkritisches Pilotprojekt zu initiieren, um die anfallenden Kosten einer mobilen Strategie zu evaluieren. In diesem müssen die Kosten für Geräte, Anwendungslizenzen und Kommunikationsverbindungen abgeschätzt werden. Die ermittelten Ausgaben können dann exemplarisch auf andere Projekte übertragen werden.

Mobile Datenbanksysteme

Auch was die weitere Entwicklung mobiler Datenbanksysteme anbelangt, ist die Richtung eigentlich vorgegeben. Alle großen Anbieter von Datenbanktechnologie (IBM, Oracle, Sybase, Software AG) sind im Segment mobiler Datenbanken vertreten. Nischenanbieter wie PointBase Micro oder eXtremeDB werden sich ohne Neuausrichtung ihrer Strategie dagegen nur in sehr speziellen Anwendungsdomänen etablieren können. Hier ist es am ehesten noch PointBase Micro mit seinen einfachen Möglichkeiten zur Integration in J2EE-Umgebungen zuzutrauen, für Furore zu sorgen. Nachdem die aktuellen Produktversionen die Grundlagen für eine effiziente mobile Datenverarbeitung jedoch fast vollständig bereitstellen, und sich bei der Implementierung gewöhnlicher Anwendungsszenarien bereits kaum mehr Schwierigkeiten identifizieren lassen (gerade auch was den Aufbau mobiler Infrastrukturen anbelangt), steht nun vor allem eine weitere Verfeinerung der Produkte im Mittelpunkt. Vor allem in einer besseren Unterstützung bei der Entwicklung mobiler Datenbankanwendungen und in der Automatisierung administrativer Aufgaben liegen die Herausforderungen für die Zukunft. Der Mobile Application Builder von IBM zeigt diesbezüglich die einzuschlagende Richtung auf. Zusätzliche Impulse für Weiterentwicklungen gehen auch von der Zielsetzung einer weitgehenden Automatisierung von Replikation und Synchronisation aus.

Plattformvielfalt

Schwierigkeiten bei der Konzeption und Realisierung mobiler Datenbankanwendungen (aller mobilen Anwendungen) macht die grosse Vielfalt existierender Mobilplattformen (Palm-OS, Windows Mobile 2003, Symbian), die die Entwicklung universell einsetzbarer mobiler Anwendungen aktuell doch noch sehr stark behindert. Das Ziel muss deswegen eine bessere Unterstützung von Plattformunabhängigkeit sein. Die Einführung des J2ME Mobile Information Device Profile 2 (MIDP2) stellt einen aussichtsreichen Versuch dar, eine plattformunabhängige Mobilplattform für einen umfassenden unternehmensweiten Einsatz bereitzustellen.

332

■ ■ ■

12 Ausblick

In Zukunft wird die mobile Datenverarbeitung eine zunehmend wichtige und bedeutende Rolle spielen. Immer leistungsfähigere und intelligenter nutzbare mobile Endgeräte werden die Integration mobiler Datenbankanwendungen in bestehende nicht-mobile Infrastrukturen forcieren. Vor allem der standortunabhängige Zugriff auf unternehmensweite Datenpools wird dabei stark an Bedeutung gewinnen und kann sicherlich als ein weiterer Wachstumsmarkt gesehen werden. Die mobile Datenbanktechnologie ist bereits weit gekommen und wird sich auch in Zukunft in großen Schritten weiterentwickeln. Viele der grundlegenden Fragestellungen aus dem Bereich der mobilen Datenbanksysteme sind bereits hinreichend geklärt, einige sind noch offen. Bei den mobilen Datenbanksystemen als Teilvision des Mobile Computing bzw. Pervasive Computing handelt es sich um einen der am schnellsten wachsenden und spannendsten Forschungsund Anwendungsbereiche.

12 Ausblick

Fazit

■ ■ ■

333

Literatur

[Ach94] A. Acharya, B. R. Badrinath. Checkpointing Distributed Applications on Mobile Computers. Proc. of the 3rd Intl. Conf. on Parallel and Distributed Information Systems (PDIS’94), Austin, Texas. IEEE Computer Society, pp. 73-80, 1994. [Ach95] S. Acharya, R. Alonso, M. Franklin, S. Zdonik. Broadcast Disks: Data Management for Asymmetric Communication Environments. Proc. of the ACM SIGMOD Intl. Conf. on Management of Data, San Jose, California. ACM Press, pp. 199-210, 1995. [Alo92] R. Alonso, S. Ganguly. Energy Efficient Query Optimization. Matsushita Information Technology Laboratory (MITL), Technical Report, pp. 33-92, 1992. [Bad92a] B. R. Badrinath, T. Imielinski, A. Virmani. Locating Strategies for Personal Communication Networks. Workshop on Networking of Personal Communications Applications, 1992. [Bad92b] B. R. Badrinath, T. Imielinski. Querying in Highly Mobile Distributed Environments. Proc. of the 18th Intl. Conf. on Very Large Databases (VLDB’92), Vancouver, British Columbia, 1992. [Bar94] D. Barbara, T. Imielinski. Sleepers and Workaholics: Caching Strategies in Mobile Environments. Proc. of the ACM SIGMOD Intl. Conf. on Management of Data, Minneapolis, Minnesota. SIGMOD RECORDS 23(2), pp. 1-12, 1994. [Bar99] D. Barbara. Mobile Computing and Databases - A Survey. IEEE Transactions on Knowledge and Data Engineering, 11(1), pp. 108-117. Information and Software Engineering Department, George Mason University, Fairfax., 1999.

Literatur

■ ■ ■

335

[Bha94] B. Bhargava, E. Pitoura. Revising Transaction Concepts for Mobile Computing. 1st IEEE Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, pp.164-168, 1994. [Bha99] P. Bhagwat, C. Bisdikian, I. Korpeoglu, A. Krishna, M. Naghshineh. System design issues for low-power, low-cost, short range wireless networking. IEEE International Conference on Personal Wireless Communications (ICPWC), 1999. [Bob00] C. Bobineau, L. Bouganim, P. Pucheral, P. Valduriez. PicoDBMS: Scaling down Database Techniques for Smartcard. Proc. of the 26th Intl. Conf. on Very Large Databases (VLDB’00), Cairo, Egypt, pp. 11-20, 2000. [Bob01] C. Bobineau, L. Bouganim, P. Pucheral, P. Valduriez. PicoDBMS: Validation and Experience. Proc. of the 27th Intl. Conf. on Very Large Databases (VLDB’01), Rome, Italy, pp. 11-20, 2001. [Borg95] U. M. Borghoff. Rechnergestützte Gruppenarbeit - Eine Einführung in verteilte Anwendungen. Springer-Verlag, 1995. [Chr93] P. K. Chrysanthis. Transaction Processing in Mobile Computing Environment. Proc. of the IEEE Workshop on Advances in Parallel and Distributed Systems, Princeton, New Jersey, pp.77-83, 1993. [Chr94] P. K. Chrysanthis, K. Ramamritham. Synthesis of Extended Transaction Models Using ACTA. ACM Transactions on Database Systems, 19(3), pp.450-491, 1994. [Chr95] P. K. Chrysanthis, G. D. Wilborn. Supporting SemanticsBased Transaction Processing in Mobile Database Applications. Proc. of the 14th Symposium on Reliable Distributed Systems (SRDS’95), 1995. [Con97] S. Conrad. Föderierte Datenbanksysteme. Springer-Verlag, 1997. [Dal97] J. Dale, D. C. DeRoure. A Mobile Agent Architecture for Distributed Information Management. University of Southampton, Department of Electronics and Computer Science, 1997.

336

■ ■ ■

Literatur

[Dad96] P. Dadam. Verteilte Datenbanken und Client/ServerSysteme: Grundlagen, Konzepte, Realisierungsformen. SpringerVerlag, 1996. [Dar96] S. Dar, M. J. Franklin, B. T. Jonsson, D. Srivastava, M. Tan. Semantic Data Caching and Replacement. VLDB Journal, pp.330-341, 1996. [Dat95] C. Date. An Introduction to Database Systems. AddisonWesley, 1995. [DB2e04] DB2 Everyplace-Dokumentation. IBM, April 2004. [Dem94] A. Demers, K. Petersen, M. Spreitzer, D. Terry, M. Theimer, B. Welch. The Bayou Architecture: Support for Data Sharing Among Mobile Users. Computer Science Laboratory, Xerox Palo Alto Research Center, Palo Alto, 1994. [Dir00] R. A. Dirckze, L. Gruenwald. A Pre-Serialization Transaction Management Technique for Mobile Multidatabases. Journal: Mobile Networks and Applications, 5(4), pp.311-321, 2000. [Dun95] M. Dunham, A.Helal. Mobile Computing and Databases: Anything New?. SIGMOD RECORDS, 4(4), pp. 5-9, 1995. [Dun97] M. Dunham, A. Helal, S. Balakrishnan. A Mobile Transaction Model that Captures Both the Data and Movement Behavior. Journal: Mobile Networks and Applications, 2(2), pp.149-162, 1997. [Elm95] Elmagarmid, J. Jing, O. Bukhres. An Efficient and Reliable Reservation Algorithm for Mobile Transactions. Proc. of the 4th Intl. Conf. on Information and Knowledge Management (CIKM’95), Baltimore, Maryland, pp. 90-95, ACM, 1995. [Elm02] R. Elmasri, S. B. Navathe. Grundlagen von Datenbanksystemen. Addison-Wesley (Pearson Studium), 3.Auflage, 2002. [Fan00] T. Fanghänel. Vergleich und Bewertung kommerzieller mobiler Datenbanksysteme. Diplomarbeit, Friedrich-SchillerUniversität Jena, Fakultät für Mathematik und Informatik, Institut für Informatik, 2000.

Literatur

■ ■ ■

337

[Fan03] T. Fanghänel, J. S. Karlsson, C. Leung. DB2 Everyplace Database Release 8.1: Architecture and Key Features. Datenbank Spektrum, Heft 5/2003. pp.9-15, 2003. [Gol92] R. A. Golding. Weak-Consistency Group Communication and Membership. Dissertation, University of California, Santa Cruz. 1992. [Gol95] R. Goldring. Update Replication: What Every Designer Should Know. Info DB (USA), 9(2), pp.17-24, 1995. [Gol00] C. Gollmick. Anwendungsklassen und Architektur mobiler Datenbanksysteme. Tagungsband des 12.GI-Workshop "Grundlagen von Datenbanken". Bericht Nr.2005, Institut für Informatik und praktische Mathematik, Christian-Albrechts-Universität Kiel, pp.3640, 2000. [Gol01] C. Gollmick. Unterstützung mobiler Clients durch erweiterte Client/Server-Datenbanksysteme. Tagungsband zum 13. GIWorkshop „Grundlagen von Datenbanken“, Gommern, SachsenAnhalt, 2001. [Gol03] C. Gollmick. Nutzerdefinierte Replikation zur Realisierung neuer mobiler Datenbankanwendungen. GI-Edition - Lecture Notes in Informatics, Band P-26, pp.453-462, 2003. [Gup03] M. Gupta, N. Tang, A. Pasos. Query Processing Issues in Mobile Databases. University of California, Department of Computer Science, 2003. [Gra96] J. Gray, P. Helland, P. O'Neil, D. Shasha. The Dangers of Replication and a Solution. Proceedings of the 1996 ACM SIGMOD International Conference on Management of Data, Montreal, Quebec, Canada, pp.173-182, ACM, 1996. [Här01] T. Härder, E. Rahm. Datenbanksysteme – Konzepte und Techniken der Implementierungen. Springer Verlag, 2001. [Hoe01] H. Höpfner. Grundlagen von Replikationstechniken für mobile Datenbanken. Tagungsband 13. GI-Workshop „Grundlagen von Datenbanken". Preprint Nr. 10, pp.68-72, 2001.

338

■ ■ ■

Literatur

[Hua01] Y. Huang, H. Garcia-Molina: Publish/Subscribe in a mobile Environment. Proc. of the 2nd ACM Intl. Workshop on Data Engineering and Wireless and Mobile Access (MobiDB’01), Santa Barbara, California, pp. 27-34, 2001. [Imi92] T. Imielinski, B. R. Badrinath. Mobile Wireless Computing: Solutions and Challenges in Data Management. Rutgers University, Department of Computer Science, New Brunswick, 1992. [Imi94] T. Imielinski, S. Viswanathan, B. R. Badrinath. Data on air: Organization and Access. Technical Report, Rutgers University Department of Computer Science, New Brunswick, 1994. [Jan96] J. Jannink, D. Lam, J. Widom, D. Cox, N. Shivkumar. Efficient and Flexible Location Management Algorithms for Wireless Communication Systems. Proc. of the 2nd ACM Intl. Conf. on Mobile Computing and Networking (MOBICOM’96), White Plains, New York, pp. 38-49, 1996. [JCa03] ISO7816. www.javacard.org, 2004. [Jin95] J. Jing, O. Bukhres, A. K. Elmagarmid. Distributed Lock Management for Mobile Transactions. Proc. of the 15th IEEE Intl. Conf. on Distributed Computing Systems (ICDCS'95), Vancouver, Canada, IEEE Press, pp. 118-125, 1995. [Koe03] B. König-Ries. MODIS-Vorlesung, Universität Karlsruhe, 2003. [Kra98] R. Kravets, P. Krishnan. Power Management Techniques for Mobile Communication. Proc. of the 4th ACM/IEEE Intl. Conf. on Mobile Computing and Networking (MOBICOM’98), Dallas, Texas, pp.157-168, 1998. [Kri96] P. Krishna, N. H. Vaidya, D. K. Pradhan. Static and Adaptive Location Management in Mobile Wireless Networks. Journal of Computer Communications (Special Issue on Mobile Computing) 19(4), 1996. [Kro03] M. Kroll, S. Haustein. J2ME Developers Guide – JavaAnwendungen für mobile Geräte. Markt und Technik, 2003.

Literatur

■ ■ ■

339

[Kub00] U. Kubach, K. Rothermel, A Context-Aware Hoarding Mechanism for Location-Dependent Information Systems, Technical Report 06/2000, Universität Stuttgart, 2000. [Kub01] U. Kubach, K. Rothermel. Exploiting Location Information for Infostation-Based Hoarding, Proc. of the 7th ACM Intl. Conf. on Mobile Computing and Networking (MOBICOM’01), Rome, Italy, pp. 15-27, 2001. [Kue94] G. Kuenning, G. Popek, P. Reiher. An Analysis of Trace Data for Predictive File Caching in Mobile Computing. Proc. of the 1994 Summer USENIX Conference, Boston, pp. 291-303, 1994. [Kue97] G. H. Kuenning, G. J. Popek, Automated hoarding for mobile computers. Proc. of the 16th Intl. Symposium on Operating Systems Principles, St. Malo, France, pp.264-275, 1997. [Kur02] K. Kuramitsu, K. Sakamura. Electronic Tickets on Contactless Smartcard Database. Proc. of the 13th Intl. Conf. on Database and Expert System Applications (DEXA’02), Aix-en-Provence, France, Springer-Verlag, LNCS 2453, pp. 392-402, 2002. [Leh03] F. Lehner. Mobile und drahtlose Informationssysteme: Technologien, Anwendungen, Märkte. Springer-Verlag, 2003. [Lei01] T. Leich, H. Höpfner. Konzeption eines Anfragesystems für leichtgewichtige, erweiterbare DBMS. Tagungsband zum GIWorkshop „Mobile Datenbanken und Informationssysteme - Datenbanktechnologie überall und jederzeit“, GI-Arbeitskreis Mobile Datenbanken und Informationssysteme, Magdeburg, 2001. [Li01] L. Li, B. König-Ries, N. Pissinou, K. Makki. Strategies for Semantic Caching, Proc. of the 12th Intl. Conf. on Database and Expert System Applications (DEXA’00), Munich, Germany, SpringerVerlag, LNCS 2113, pp. 284-298, 2001. [Liu95] G. Liu, G. Maguire, Efficient Mobility Management Support for Wireless Data Services, Proc. of the 45th IEEE Vehicular Technology Conference (VTC'95), Chicago, Illinois, USA, 1995. [Liu98] T. Liu, P. Bahl, I. Chlamtac. Mobility Modeling, Location Tracking, and Trajectory Prediction. in Wireless ATM Networks. IEEE Journal on Special Areas in Communications, Special Issue on Wireless Access Broadband Networks, 16(6), 1998.

340

■ ■ ■

Literatur

[Lub95] A. Lubinski. Datenbanksysteme in mobiler Umgebung. Hildesheimer Informatik-Berichte 12/95, Universität Rostock, Fachbereich Informatik, 1995. [Lub00] A. Lubinski. Replizieren und Reduzieren von Daten für ressourcenbegrenzte Umgebungen. 12ter GI-Workshop „Grundlagen von Datenbanken”, Technischer Bericht, Nr. 2005, Universität Kiel, pp. 66-70, 2000. [Mad01] S. K. Madria, B. Bhargava. A Transaction Model for Improving Data Availability in Mobile Computing. Journal: Distributed and Parallel Databases, 10(2), pp. 127-160, 2001. [Mat98] F. Mattern. Mobile Agenten. Informationstechnik und Technische Informatik, 4/98, pp. 12-17, Technische Universität Darmstadt, Fachbereich Informatik. 2000. [Mie01] N. Mielke. DB2 Everyplace: An Overview. IBM Research, Silicon Valley Lab, San Jose, 2001. [Moh94] S. Mohan, R. Jain. Two User Location Strategies for Personal Communication Services. IEEE Personal Communications, 1(1), 1994. [Mum94a] L. B. Mummert, M. Satyanarayanan, Variable Granularity Cache Coherence. Operating Systems Review, Jan 1994, 28(1), pp. 55-60, 1994. [Mum94b] L. B. Mummert, M. Satyanarayanan. Large Granularity Cache Coherence for Intermittent Connectivity. Proc. of the 1994 Summer USENIX Conference, Boston, pp. 279-289, 1994. [Mum95] L.B. Mummert, M. R. Ebling. M. Satyanarayanan. Exploiting Weak Connectivity for Mobile File Access. Proc. of the 15th ACM Symposium on Operating Systems Principles (SOSP’95), Copper Mountain Resort, pp. 143-155, 1995. [Mut03] B. Mutschler, G. Specht. Implementierungskonzepte und Anwendungsentwicklung kommerzieller mobiler Datenbanksysteme – Ein Vergleich. Workshop GI-Arbeitskreis „Mobile Datenbankenund Informationssysteme“, Zürich, Oktober 2003.

Literatur

■ ■ ■

341

[Nad01a] A. Nadamoto, H. Kondo, K. Tanaka. WebCarousel: Automatic Presentation and Semantic Restructuring of Web Search Result for Mobile Environments. Proc. of the 12th Intl. Conf. on Database and Expert Systems (DEXA’02), Springer-Verlag, LNCS 2113, pp. 712-722, 2001 [Nad01b] A. Nadamoto, H. Kondo, K. Tanaka. Dynamic Restructuring and Passive Viewing of Web Search Results for Mobile Environments. IPSJ Transactions on Databases, 15(2), 2001 [Nag00] K. Nagarajan, S. Arumugam. Survey of Small Footprint Databases. Technical Report, CIS 6930, Distributed Database Systems, 2000. [Nar94] V. R. Narasayya. Distributed Transactions in a Mobile Computing System. Proc. of the 1st IEEE Workshop on Mobile Computing Systems and Applications, Santa Cruz, CA, 1994. [Nic01] D. Nicklas, M. Großmann, T. Schwarz, S. Volz, B. Mitschang. A Model-Based, Open Architecture for Mobile, Spatially Aware Applications. Proc. of the 7th Intl. Symposium on Advances in Spatial and Temporal Databases (SSTD’01), Redondo Beach, California, Springer-Verlag, LNCS 2121, pp.117-135, 2001. [Noe02] A. Noether. Extending Enterprise Data to Mobile Devices. IBM White Paper, 2002. [Noe03] D. Nöldner. dpunkt.verlag, 2003.

Palm-OS-Programmierung

mit

GCC.

[OCS03] Opencard-Specification. www.opencard.com, 2004. [ORA04] Oracle 10g Lite Dokumentation. Oracle, 2004. [Pap01] M. Papadopouli and H. Schulzrinne. Effects of power conservation, wireless coverage and cooperation on data dissemination among mobile devices. Proc. of the 2nd Intl. Symposium on Mobile Ad Hoc Networking & Computing (MobiHoc’01), Long Beach, California, ACM, pp. 117-127, 2001. [PBM04] PointBase Micro-Dokumentation, 2004. [PCS03] PC-Smartcard-Specification, 2003.

342

■ ■ ■

Literatur

[Per99] F. Perich, S. Avancha, A. Joshi, Y. Yesha, K. Joshi. Query Routing in Mobile Ad-Hoc Environments. Technical Report TR-CS01-18, University of Maryland, 1999. [Pha00] S. Phatak und B. Badrinath. Transaction-centric Reconciliation in Disconnected Client Server Databases. Technical Report, Department of Computer Science, Rutgers University, New Jersey, 2000. [Pit94] E. Pitoura, B. Bhargava. Building Information Systems for Mobile Environments. Department of Computer Science, Purdue University, West Lafayette. 1994. [Pit95a] E. Pitoura, B. Bhargava. Maintaining Consistency of Data in Mobile Distributed Environment. Proc. of the 15th Intl. Conf. on Distributed Computer Systems, Vancouver, 1995. [Pit95b] E. Pitoura, B. Bhargava,. A Framework for Providing Consistent and Recoverable Agent-Based Access to Heterogeneous in Mobile Databases. SIGMOD RECORD 24(3), pp. 44-49, 1995. [Pit99a] E. Pitoura und P. K. Chrysanthis. Exploiting Versions for Handling Updates in Broadcast Disks. Proc. of the 25th Intl. Conf. on Very Large Databases (VLDB’99), pp.114-125, 1999. [Pit99b] E. Pitoura und P. K. Chrysanthis. Scalable Processing of Read-Only Transactions Broadcast Push. Proc. of the 19th IEEE Intl. Conf. on Distributed Computing System, pp.432-441, 1999. [Pit99c] E. Pitoura, B. Bhargava. Data Consistency in Intermittently Connected Distributed Systems. IEEE Transactions on Knowledge and Data Engineering, 11(6), pp. 896-915, 1999. [Pit01] E. Pitoura und G. Samaras. Locating Objects in Mobile Computing. IEEE Transactions on Knowledge and Data Engineering, 13(4), pp.571-592, 2001. [Rah94] E. Rahm. Mehrrechner-Datenbanksysteme – Grundlagen der verteilten und parallelen Datenverarbeitung. Addison-Wesley, 1994.

Literatur

■ ■ ■

343

[Ren99] Q. Ren und M. Dunham. Using Clustering for Effective Management of a Semantic Cache in Mobile Computing. Proceedings of the International Workshop on Data Engineering for Wireless and Mobile Access (MobiDE’99), Seattle, USA, pp. 94-101, 1999. [Ren00] Q. Ren, M. Dunham: Using Semantic Caching to Manage Location Dependent Data in Mobile Computing. Proc. of the 6th Intl. Conf. on Mobile Computing and Networking (MOBICOM’00), Boston, Massachusetts, ACM, pp. 210-221, 2000. [Ric94] T. Richardson, F. Bennett, G. Mapp, A. Hopper. Teleporting in an X Window System Environment. IEEE Personal Communications, 1(3), 1994. [Rot03] J. Roth. Mobile Computing - Grundlagen, Techniken, Konzepte. dpunkt.verlag, 2002. [Roy99] E. M. Royer and C. K. Toh. A Review of Current Routing Protocols for Ad-Hoc Mobile Wireless Networks. IEEE Personal Communications, 1999. [Sas02] A. Sasikanth, D. Chakraborty, H. Chen, L. Kagal, F. Perich, T. Finin, A. Joshi. Issues in Data Management for Pervasive Environments. NSF Workshop on Context Aware Mobile Database Management (CAMM’02), Providence, Rhode Island, 2002. [SAS04] SQL Anywhere Studio Dokumentation. iAnywhere. 2004. [Sat94] M. Satyanarayanan, O. Lu. Isolation-Only Transactions for Mobile Computing. Operating Systems Review, 28(2), pp.81-87, 1994. [Sat95] Q. Lu, M. Satyanarayanan. Improving Data Consistency in Mobile Computing Using Isolation Only Transactions. Technical Report CMU-CS-95-126, Carnegie-Mellon University, 1995. [Sat96] M. Satyanarayanan. Mobile Information Access. IEEE, 1996. [Say00] Y. Saygin, O. Ulusoy, A. Elmagarmid. Association Rules for Supporting Hoarding in Mobile Computing Environments. IEEE 10th International Workshop on Research Issues on Data Engineering (RIDE’00), San Diego, CA, USA, pp. 71-78, 2000.

344

■ ■ ■

Literatur

[Ser02] P. Serrano-Alvarado, C. Roncancio, M. Adiba. Mobile Transaction Supports for DBMS: An Overview. LSR-IMAG Laboratory, 2001. [Sey01] A. Y. Seydim, M. Dunham und V. Kumar. Location Dependent Query Processing. Proc. of the 2nd ACM Intl. Workshop on Data Engineering for Wireless and Mobile Access, Santa Barbara, California, USA, pp.47-53, 2001. [SQL04] SQL Server CE-Dokumentation. Microsoft. 2004. [Tai91] C. Tait and D. Duchamp. Detection and Exploitation of File Working Sets. Proc. of the 11th Intl. Conf. on Distributed Computing Systems, pp.2-9, 1991. [Tan03] A. Tanenbaum. M. van Steen. Verteilte Systeme - Grundlagen und Paradigmen. Prentice Hall, Pearson Studium, 2003. [TAM04] Tamino Mobile Suite-Dokumentation. Software AG, 2004. [Tue01] C. Türker. Mobile Transaction Coordination. GIArbeitskreis-Gründungstreffen "Mobile Datenbanken und Informationssysteme", ETH Zürich/Universität Konstanz, 2001. [Wal97] G. D. Walborn, P. K. Chrysanthis. PRO-MOTION: Management of Mobile Transactions. Proc. of the 11th ACM Annual Symposium on Applied Computing (SAC’97), San Jose, CA, USA, pp. 101-108, 1997. [Wal99] G. D. Walborn, P. K. Chrysanthis. Transaction Processing in PRO-MOTION. Proc. of the 14th ACM Annual Symposium on Applied Computing (SAC’99), San Antonio, Texas, pp. 389-398, 1999. [Wat96] J. Waterstraat. Definition und Nutzung von Kontexten in mobiler, verteilter Datenbankumgebung. Diplomarbeit, Universität Rostock, Fachbereich Informatik, 1996. [Wei91] M. Weiser. The Computer for the Twenty-First Century. Scientific American,1991. [Wol98] O. Wolfson, B. Xu, S. Chamberlain und L. Jiang. Moving Objects Databases: Issues and Solutions. Proc. of the 11th Intl. Conf. on Statistical and Scientific Database Management (SSDBM’98), Capri, Italy, IEEE Press, pp.111-122, 1998.

Literatur

■ ■ ■

345

[Wu98] K-L. Wu, P. S. Yu and M. S. Chen. Efficient Caching for Wireless Mobile Computing. Journal of Distributed and Parallel Databases, 6(4), pp.351-372, 1998. [XDB04] eXtremeDB User Guide V2.1. McObject. 2004. [Xu99] J. Xu, X. Tang, D. L. Lee, and Q. Hu. Cache Coherency in Location-Dependent Information Services for Mobile Environment, Proceedings 1st Conf. on Mobile Data Access (MDA'99), Hong Kong, Springer-Verlag, LNCS 1748, pp.182-193, 1999. [Xu00] J. Xu, D. L. Lee. Querying Location-Dependent Data in Wireless Cellular Environment. WAP Forum/W3C Workshop on Position Dependent Information Services, Sophia Antipolis, France, 2000. [Xu02] J. Xu, D. L. Lee, Q. Hu, and W. C. Lee. Data Broadcast. Handbook of Wireless Networks and Mobile Computing, Chapter 11, pp.243-265, 2002. [Ye02] D. Y. Ye, M. C. Lee, T. I. Wang. Mobile Agents for Distributed Transactions of a Distributed Heterogeneous Database System. Proc. of the 13th Intl. Conf. on Database and Expert Systems (DEXA’02), Springer-Verlag, LNCS, pp.404-412, 2002.

346

■ ■ ■

Literatur

Indexverzeichnis

. .NET Compact Framework 210

1 1-Kopie-Serialisierbarkeit 85

2 2-Phasen-Replikation 132

8 802.11a 34 802.11b 34 802.11h 35 802.11-Protokollfamilie 33 802.16 35

A Abbruchabhängigkeit 129 Abhängigkeitsmengen 134 Access Point 32 ACID-Transaktionen 112 ActiveSync 256 ActiveX Data Objects Extensions for Data Definition Language (DDL) and Security (ADOXCE) 260 Adam Osborne 17 Adaption durch Abstraktion 170 Adaption von Informationen 165 Adaption von Systemen 163

Adaptive Server Anywhere 196, 224 Ad-Hoc-Netze 32 Akzeptanzkriterium 134 Always-On 9

Ä Änderungsdynamik zugegriffener Daten 155

A A-Netz 25 Anfragekomplexität 155 Anfrageverarbeitung 153 Anwendungsereignisse 290 Anwendungsszenarien 5 Apache 214 AppForge MobileVB-Plug-In 212 Application-Awareness Adaption 164 Application-Transparent Adaption 164 Architekturen mobiler Informationssysteme 57 Atomizität 112 Ausführung von Anfragen 154 Ausführungsplan 153 AWT 285

B Basisstation 7 Batch-Betriebssysteme 74 Baumstruktur 154 Bayou-Transaktionsmodell 132

Indexverzeichnis

■ ■ ■

347

Benutzermobilität 21 berichtende Teiltransaktionen 128 Betriebszustände mobiler Clients 8 Beutel (Pouch) 120 Bluetooth 37, 38 Bluetooth Special Interest Group 38 B-Netz 25 Broadcast Disks 10 browserbasierte Anwendungen 223 Business-2-Business 6 Business-2-Consumer 6 Busy-Flag 295

C Calm Computing 19 CDC/Personal Java Profile 248 CDMA/IS-95 25 CDPD 31 Cellular Digital Packet Radio 31 CEPT 28 Chunks 287 CLDC/MIDP Profile 248 Client/Server-Architekturen 57 Client/Server-Ketten 62 Client/Server-Kooperation 61 Cloudscape 261 Cluster 141 C-Netz 25 Compact Agents 147 Compact Manager 147 Compacts 147 Compensating Mode 121 Composite Capability / Preference Profile 170 Concurrency Control 109 Conduit 278 Conduit Development Kit (CDK) 282, 303 Connected Device Configuration 311 Connected Mode 8, 115 Connection Pooling 326 Consistency 112 Co-Transactions 128 CreatorID 294

348

■ ■ ■

Indexverzeichnis

Cygwin 280, 305

D Data Caching 95 Data Hoarding 96 Data Manager 294 Data-Patch-Verfahren 94 Datenbankprogrammierung 297 Datenredundanz 79 Datentransport 174 Datenverteilung 45 Datenzugriffsagenten 118 Dauerhaftigkeit 113 DB2 Everyplace 195, 196, 304 DB2 Everyplace Database Edition 197 DB2 Everyplace Enterprise Edition 197 DB2 Everyplace Software Development Kit 278 DB2 Everyplace Software Development Kit (SDK) 305 Dead Lock 111 Delete-Flag 296 dichter Index 184 Dienstmobilität 22 Dienstvermittlung 23 Digital Advanced Mobile Phone Service 31 Digital Cellular System 31 digitale Akte 175 digitale Rundfunk- und TVSignale 329 Dirty Read 110 Dirty-Flag 295 Disappearing Computing 19 Disconnected Mode 8, 116, 132 Distributed Object Management System (DOMS) 72 Domain-Storage 182 Drahtlosigkeit 20 Drahtlostechnologien 9 duale Prozessorarchitektur 330 Dual-Speicherkonzept 183 Durability 113 Dynamic Heap 287, 294

E Eclipse 254 EDGE 31 Effizienz 45 einfache Abfragen 187 eingebettete (Java-SQL)Datenbanken 261 eMbedded Visual Tools 257, 260 Endgerätemobilität 21 Enhanced Data Rates for GSM Evolution 31 Entwurfsregeln 179 Epsilon-Serialisierbarkeit 95 Ereignisbehandlungsroutinen 289 Ereignisebenen 289 Ereignisgesteuerte Programmierung 289 Ereignishandler 289 Ereignistypen 289 Everyplace Software Development Kit 197 eXtremeDB 196, 261, 262

F feste Chunks 288 Firstclass-Transaktionen 145 Flags 295 Flat-Storage 181 Formularereignisse 291 Foundation Server 237 Fragmentierung 137 Frequency Division Multiplexing Access 27 Frequency Divison Multiplexing 27 Frequenzmultiplexing 27 Funkfeststation 7 Funkzellen 7

G gemeinsame Daten 12 General Packet Radio Service 31 Generic Connection Framework (GCF) 285 Geräteschutz 44 Global System for Mobile Communication 25

Globale Serialisierbarkeit (GSR) 146 GNU C-Compiler 280 GPRS 31 GPS-Navigation 53 Groupé Special Mobile 28 GSM 25 GSM-Architektur 28 GSM-Handover 29 GSM-Luftschnittstelle 28

H Handover 9, 29 Handys 51 High Speed Circuit Switched Data 31 HiperACCESS 41 HIPERLAN 40 HiperLINK 41 Home Location Server 159 HomeRF 41 Horizontale Anwendungen 11 HotSync 283, 322 HSCSD 31 hSQLDB 196, 263 hybride Endgeräten 329 Hypersonic SQL Database 261, 263

I Identifikation 174 Identifizierbarkeit 43 IEEE 802.11-Protokollfamilie 32 Informationsdarstellung 163 Infrarot (IrDA) 40 Infrastrukturnetze 32 inhaltszentrierte Anwendungen 6 Insignia Jeode Virtual Machine 235 InstantDB 196, 267 Integritätsbedingungen 46 Intercell-Handover 29 Inter-Cluster-Constraints 141 Internet Information Server (IIS) 257 Intracell-Handover 29 Intra-Cluster-Constraints 141 Invisible Computing 19

Indexverzeichnis

■ ■ ■

349

IrDA 37 iSeries 198 ISO 7816 178 Isolation 113 Isolation-Only-Transaktionen 116, 144 ISO-OSI-Referenzmodell 22 Iterator-Modell 189

J Java 2 Enterprise Edition 283 Java 2 Micro Edition 210, 247, 283, 325 Java 2 Standard Edition 247, 283 Java Community Process (JCP) 283 JavaCard 173 JavaCard Virtual Machine 177 JData Store 261 JDBC 325 JDBC Optional Package 325 Joey-Transaction-ID 121 Joey-Transaktion 120

K Kangaroo-Transaction-ID 119 Kangaroo-Transaktionen 116, 117 Karussellkomponenten 167 Kilobyte Virtual Machine (KVM) 283 Klassifikation mobiler Endgeräte 50 Klassifikation standortabhängiger Queries 156 kommerzielle mobile Datenbanksysteme 195 kommunikationszentrierte Anwendungen 6 Kommutativität von Datenbankoperationen 137 Kompaktheitsregel 179 Kompensationsmodus 121 komplexe Abfragen 191 Komplexität 187 Konfigurationen 284 Konsistenz 112

350

■ ■ ■

Indexverzeichnis

konsistenzerhaltende Verfahren 89 Kopie-Update-Strategien 83 kostenbasierte Optimierung 154

L Laissez-Faire Adaption 164 Lastverteilung 45 Leitfaden für mobile Projekte 331 Lese-Regel 180 Lesetransaktionen 84, 110 Location Aware Queries (LAQ) 157 Location Based Services 46 Location Dependant Queries (LDQ) 157 Location Dependent Service Manager 159 Location Related Attributes 156 Location Related Domain 157 Location Related Operator 157 Location Related Predicates 157 Location Server 159 logische Transformationsregeln 154 Log-Transformation 93 Lokale Serialisierbarkeit (LSR) 146 Lokationsserver 159 Lost Update 110

M Makrozelle 7 Master 133 Master-Replikationsschema 133 M-Commerce 6 Megazelle 7 Menüereignisse 290 MERGE-Methode 139 Metrowerks CodeWarrior 323 Micro Web Application Server 213 Microsoft Embedded Visual Tools 3.0 210 Microsoft SQL Server 2000 CE Edition 196, 256 Middleware-Architekturen 71

MIDlets 285 Migration 9 Mikroprozessorsystem 177 Mikrozelle 7 Missing-Update 90 mitwirkende Teiltransaktionen 128 Mobile Agenten 73 mobile Anwendungen 3 Mobile Anwendungen 41 Mobile Application Builder 198, 278 Mobile Application Builder (MAB) 304 mobile Client/ServerArchitekturen 64 mobile Computersysteme 18 Mobile Computing 18, 329 mobile Daten 13 Mobile Development Kit (MDK) 222 Mobile Device Administration Center (MDAC) 198, 305 Mobile Information Device Profile (MIDP) 284 Mobile Information Device Profile 2 (MIDP2) 332 mobile Knoten 8 mobile Multidatenbanksysteme 70 Mobile Object Database Queries 158 Mobile Object Server 72 Mobile Server Control Center (MSCC) 214 Mobile Server Environment 213 Mobile Support Station 9 mobile Transaktionen 109, 115 mobile verteilte Datenbanksysteme 69 mobiles Datenbanksystem 12 mobiles Informationssystem 13 Mobile-Server 214 Mobilfunk 24 Mobilfunknetze der dritten Generation 31 Mobilfunknetze der ersten Generation 25 Mobilfunknetze der zweiten Generation 25 MobiLink 226

Mobilität 20 Mobilität unterstützenden Informationssystemen 13 Mobilkommunikation 26 Mobilplattformen 332 Multiple-Server-Environment 257

N Nomadic Computing 19 Non-Location Related Attributes 157 Non-Repudiation 44 Notebooks 51 Notification Server 236 nutzerdefinierte Replikation 100 nutzerdefiniertes Typ-Mapping 326 Nutzerprofile 174

O Object Exchange Protocol (OBEX) 106 offen-geschachtelte Transaktionen 116, 127

Ö Öffentliche Daten 11

O Offline-Szenario 5, 79, 100 OLE DB Provider for SQL Server CE 260 Online-Szenario 4 on-the-fly 189 Opencard-Standard 178 Operatorbaum 154 optimistische Verfahren 93 Oracle 10g Application Server (Wireless) 213, 214, 221 Oracle HTTP Server 214 Oracle Lite 213 Ortsunabhängigkeit 42 Osborne-1-Rechnersystem 17

Indexverzeichnis

■ ■ ■

351

P Palm OS Developer Suite 282 Palm Software Development Kit 277, 280 Palm-Emulator 281 Palmgeräte 278 Palm-Simulator 281 Palmtops 278, 286 parametrisierte Ereignissen 289 Partitionen 159 PC-Smartcard 178 PDAs 51 PDC 26, 31 Personal Digital Cellular 31 Personal Information Management 10 Personal Profile 285, 311 Personalisierung 168 Pervasive Computing 19 Pessimistische Verfahren 89 Pico-Datenbanksysteme 173 Pikonetz 39 Pikozelle 8 Pilotprojekt 332 PilRC 280, 305 Pipelining 189 PointBase Embedded 248 PointBase Micro 196, 247, 279, 311 PointBase Server 248 PointBase UniSync 248 Positioning 47 Possible Location 159 PRC-Tools 280, 305 Presentation Server 236 Preserialization Transaction Management Technique 116, 123 Prewrite-Transaktionen 116, 130 Primary-Verfahren 90 Private Daten 11 Profile 284 Programmierung von Palmtops 286 Promotion-Transaktionen 116, 147 provisorische Transaktionen 116, 132, 133 PSTMT-Transaktionen 123 PS-Transaktionen 123

352

■ ■ ■

Indexverzeichnis

Publish&Subscribe 99, 250, 306 Push- und Pull-Szenarien 10

Q Quality of Service 27 Quasi-Copy-Verfahren 95 Query-by-Example 209 Query-Engine 153 Quorum-Verfahren 91

R RAM-Regel 180, 186 Referenzarchitektur 7 Reintegration 87 Remote Entry Job-Konzept 74 Replikat 83 Replikation 79, 81 Replikationsdefinition 84, 85 Replikationskorrektheit 86 Replikationsquelle 82 Replikationsschemadefinition 85 Replikationssenken 82 Replikationsumgebung 81 Reporting-Transactions 128 Ring-Storage 183 Roaming 30 ROWA 89 Rückübertragung 87

S Scatter-Netz 39 schreibenden Transaktion 110 Schreib-Regel 180, 187 schwache Transaktionen 142 schwache/strikte Transaktionen 116, 141 schwaches Lesen 143 schwaches Schreiben 143 schwach-verbunden 115 Schwach-Verbunden 8 Secondclass-Transaktionen 145 Secret-Flag 296 semantische Transaktionen 116, 136 Serialisierbarkeit 111, 146 serielle Ausführungspläne 114 Sicherheit 43, 330

Sicherheitsregel 180 Site-Transaction 119 SmartCard for Windows 173 Smartcards 54, 173, 176 Smartphones 51 Snapshot-Sites 99 Snapshot-Verfahren 99 Specification Request 169 325 Speicherzugriffsfunktionen 288 SPLIT-Methode 138 Splitmodus 121 SQL Anywhere Studio 224 SQL Remote 225 SQL Server CE 256 Standortermittlung 159 stark-verbunden 9 Static Location Related Queries 157 stationäre Knoten 8 Storage Heap 287, 294 Subscriber Identification Modules (SIM) 44, 174 Sun ONE Studio (Mobile Edition) 211, 254 Sun Wireless Toolkit 286 SWING 285 SyncClient 197 SyncClient API for C/C++ 211 SyncClient API for Java 211 SyncGUI 204 Synchronisation 79, 86 Synchronisation 83 Synchronization Markup Language 104 Synchronization Server & SyncModule 236 SyncML 104 SyncML Messages 107 SyncML Package 107 SyncML Representation Protocol 104 SyncML Sync Protocol 104 SyncML Synchronizer using WBXML 203 SyncML-Adapter 107 SyncML-Framework 106 SyncML-Interface 107 SyncServer 197, 305 Systemereignisse 290

T Tamino Mobile API 238 Tamino Mobile DB 235 Tamino Mobile Offline Solution 239 Tamino Mobile Run-Time Environment 235 Tamino Mobile Smart Client (TMSC) 239 Tamino Mobile Studio 237, 246 Tamino Mobile Suite 196, 235 TDMA/IS-136 25, 31 Tentative Transactions 133 Thick Clients 61 Thin Client 61 Time Division Multiplexing 27 Tracking 47 Transaction Scope 135 Transaktionen 109 Transaktionsmodelle 109 transaktionsorientierte Anwendungen 6 Transaktionsstatustabelle 119, 125 Transaktionsverarbeitungssystem 110 Transaktionszustände 111 Treuegrad 165 Tupel-To-Value-Prinzip 185 TV-Signale 329

U Ubiquitous Computing 19 UltraLite 196, 224, 225 Umsortierbarkeit 137 UMTS 32, 330 unkritische Objektfragmente 137 Unrepeatable Read 111 unverbunden 116

V Value-To-Tupel-Prinzip 186 Verarbeitungsmodus 297 verbindungslos 8 Verbindungsübergabe 9 Verfügbarkeit 45

Indexverzeichnis

■ ■ ■

353

Verfügbarkeitserhaltende Verfahren 94 Vermittlungsschicht 23 Verteilte Datenbanksysteme 64 Vertikale Anwendungen 10 Vertraulichkeit 43 Virtual-Primary-Copy 98 Visual Studio .NET 210, 257, 260, 303

W WAP/WML-Browser 166 Weak Read 143 Weak Write 143 Wearables 54 Webkarussell 166 WiMAX 35 Windows Scripting Host (WSH) 214 Wireless Application Protocol 166 Wireless Application Protocol (WAP) Binary encoded XML (WBXML) 204

354

■ ■ ■

Indexverzeichnis

Wireless Markup Language 166 Wireless Metropolitan Area Networks 35 Wireless Personal Area Networks 37 Wireless Toolkit 311 Wireless-LAN 32 Wireless-LAN-Roaming 36 WLAN 32 Write-All-Available 90

X XSL-Stylesheet 170 XSLT-Prozessor 170

Z Zeitmultiplexing 27 Zielkonflikt der Replikation 87 zSeries 198 Zugriffsregel 180