Synchronisation mobiler Anwendungen auf Basis der Java 2 Micro

Transcrição

Fakultät II – Informatik, Wirtschafts- und Rechtswissenschaften
Department für Informatik
Abteilung Systemsoftware und verteilte Systeme
Individuelles Projekt
Synchronisation mobiler Anwendungen auf Basis der
Java 2 Micro Edition
Jasper Mammen
Nadorster Str. 72
26123 Oldenburg
Erstprüfer: Prof. Dr.-Ing. Oliver Theel
Zweitprüfer: Dipl.-Inform. Philipp Hahn
Oldenburg, den 30. August 2005
Zusammenfassung
Die folgende Arbeit beschäftigt sich mit der Synchronisation von Anwendungen auf Basis der Java
2 Micro Edition (J2ME). Neben dem Aufbau und den grundlegenden Eigenschaften der J2ME werden gängige Verfahren des Datenaustauschs und der Datensynchronisation beschrieben. Die Verwendbarkeit dieser Verfahren im Rahmen der J2ME-Plattform wird mittels einiger Beispielanwendungen evaluiert. Die dabei gesammelten Erfahrungen werden dokumentiert und dienen als Basis
eines Resümees bezüglich der heutigen Möglichkeiten und Einschränkungen der J2ME-Plattform.
Abschließend wird ein Ausblick auf die zukünftige Entwicklung der J2ME gegeben.
Inhaltsverzeichnis
1 Einleitung
4
2 Die Java 2 Micro Edition
6
2.1
2.2
2.3
2.4
Konfigurationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.1.1
Die Connected, Limited Device Configuration (CLDC) . . . . . . . . . . . . . .
7
2.1.2
Die Connected Device Configuration (CDC) . . . . . . . . . . . . . . . . . . . .
9
Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.1
Das Mobile Information Device Profile (MIDP) . . . . . . . . . . . . . . . . . . .
9
2.2.2
Das Information Module Profile (IMP) . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.3
Die Profile der CDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Optionale Pakete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3.1
Das Personal Information Management und das FileConnection API . . . . . .
12
2.3.2
Das Wireless Messaging API . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3.3
Die Java APIs für Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.4
Das Remote Method Invocation Optional Package . . . . . . . . . . . . . . . . .
13
2.3.5
Die J2ME Web Services Specification . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.6
Das JDBC Optional Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3 Datensynchronisation und J2ME
3.1
3.2
16
Kommunikationsprotokolle in der J2ME:
Das Generic Connection Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2.1
Der Aufbau von Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.2.2
Webservices in der J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
INHALTSVERZEICHNIS
3.2.3
2
Einsatz von Webservices in mobilen Anwendungen . . . . . . . . . . . . . . . .
20
SyncML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.3.1
Systemarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.3.2
Protokolle und Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.3.3
Verwendung von SyncML auf Basis der J2ME . . . . . . . . . . . . . . . . . . .
23
3.4
Push Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.5
Lokale Verbindungen via Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.3
4 Praktische Evaluation
4.1
4.2
4.3
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1.1
Anwendung für Mensapläne . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1.2
Nutzung von Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1.3
Prototyp zur Datensynchronisation über SyncML . . . . . . . . . . . . . . . . .
27
Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.2.1
Architektur System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.2.2
Komponenten Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.2.3
Struktur der Mensaplan-Anwendung . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2.4
Desktop-Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2.5
SyncML-Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.3.1
Verwendete Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . .
32
4.3.2
Mensaplan Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.3.3
Mensaplan-Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.3.4
Desktop-Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.3.5
Mensaplan Webservice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.3.6
Mensaplan MIDlet mit Kommunikation via Webservice . . . . . . . . . . . . . .
43
4.3.7
SyncML-Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5 Resümee
5.1
25
54
Beurteilung der Anwendungsentwicklung auf Basis der CLDC . . . . . . . . . . . . .
54
5.1.1
Vorteile der Entwicklung auf Basis der CLDC . . . . . . . . . . . . . . . . . . .
54
5.1.2
Probleme aufgrund der geringen Leistungsfähigkeit der Geräte . . . . . . . . .
55
INHALTSVERZEICHNIS
3
5.1.3
Schwierigkeiten aufgrund zu offener Spezifikationen . . . . . . . . . . . . . . .
57
5.1.4
Aus den Restriktionen der CLDC resultierende Probleme . . . . . . . . . . . . .
57
5.1.5
Fragmentation der CLDC-Plattform . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.1.6
Konsequenzen für die Datensynchronisation mobiler Anwendungen . . . . . .
59
5.2
Die zukünftige Entwicklung der CDC . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.3
Fazit und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
Kapitel 1
Einleitung
Der gängige Einsatzbereich von Computeranwendungen war lange Zeit der stationäre DesktopComputer. Eine fortschreitende Miniaturisierung der technischen Komponenten des Computers
ermöglicht jedoch in zunehmendem Maße die Realisierung von kleinen, leistungsfähigen, mobilen Geräten. Klassische Computeranwendungen, wie Textverarbeitung oder E-Mail sind damit nicht
länger an einen festen Arbeitsplatz gebunden, sondern können auch unterwegs“ verwendet wer”
den.
Darüber hinaus entstehen durch den Einsatz mobiler Geräte auch völlig neue Anwendungsfelder.
Benutzer mobiler Anwendungen können wichtige Informationen an jedem Ort und zu jeder Zeit
abrufen. Zudem können den Benutzern relevante Informationen auch in Abhängigkeit von ihrem
derzeitigen Aufenthaltsort zur Verfügung gestellt werden (sogenannte Location-based Services). Über
Anwendungen für solche mobile Szenarien wird zur Zeit viel diskutiert. Dabei müssen sowohl die
Bedürfnisse der Nutzer, als auch die technische Machbarkeit berücksichtigt werden.
Ein erster Überblick hinsichtlich der Vielfalt an verfügbaren mobilen Geräten lässt sich durch deren Einordnung in grundlegende Klassen mit ähnlicher Leistungsfähigkeit gewinnen. Am geringsten sind die Unterschiede zu den Desktop-Computern in der Klasse der Notebooks. Diese tragbaren
Computer bieten eine den stationären Systemen zumeist ebenbürtige Leistung. Aus diesem Grund
können auf den Notebooks auch die ursprünglich für Desktop-Computer entwickelten Anwendungen genutzt werden. Größe und Gewicht der Notebooks führen allerdings dazu, dass die Benutzer
diese nicht ständig bei sich tragen, zudem wird die Mobilität durch einen vergleichsweise hohen
Stromverbrauch eingeschränkt.
Am anderen Ende der Leistungsfähigkeit findet sich die Geräteklasse der Mobiltelefone. Diese zeichnen sich vor allem durch geringe Größe und Stromverbrauch aus, und sind damit hinsichtlich der
Mobilität klar im Vorteil – die meisten Nutzer haben ihr Mobiltelefon ständig dabei. Dieser Vorteil wird jedoch mit geringer Rechen- und Speicherkapazität und einem kleinen Display erkauft,
Anwendungen für Mobiltelefone müssen diese Limitationen berücksichtigen. Als Plattform für die
Entwicklung von Anwendungen für diese Geräte hat sich die Java 2 Micro Edition (J2ME) etabliert,
deren Möglichkeiten im Rahmen dieser Arbeit untersucht werden sollen.
Zwischen den Notebooks und Mobiltelefonen findet sich eine weitere Klasse von mobilen Geräten,
5
die der Smartphones und PDAs. Ein PDA (Persönlicher Digitaler Assistent) ist ein tragbarer, kleiner
Computer, der speziell der Verwaltung von Adressen und Terminen dient. Darüber hinaus können
zusätzliche Anwendungen installiert werden. Die Hardware der PDAs stellt einen Kompromiss zwischen Leistungsfähigkeit und Mobilität dar: Rechen- und Speicherkapazität ermöglichen auch umfangreichere Anwendungen, auch die Größe des Displays ist zur Darstellung komplexerer Oberflächen geeignet. Zugleich sind die Geräte klein genug, um vom Benutzer ständig mitgeführt werden
zu können, der relativ geringe Stromverbrauch bietet eine ausreichende Nutzungsdauer im mobilen
Einsatz.
Die Smartphones zeichnen sich durch ähnliche Eigenschaften aus, zusätzlich haben sie ein integriertes
Mobiltelefon. Die Benutzer eines Smartphones können somit die Funktionalität von PDA und Mobiltelefon nutzen, ohne gleich zwei Geräte mit auf Reisen nehmen zu müssen. Aus diesem Grund
haben auch die Hersteller klassischer PDAs damit begonnen, ihre Geräte um die Fähigkeit zum mobilen Telefonieren zu erweitern. Eine weitere Konvergenz der beiden Gerätearten ist zu erwarten.
Auch für viele Smartphones und PDAs steht die Java 2 Micro Edition als Plattform zur Anwicklung
mobiler Anwendungen zu Verfügung. Daneben können Anwendungen für diese Geräte auch nativ
für das jeweilige Betriebssystem entwickelt werden. Die heute gängigen Plattformen sind Embedded
Linux, PalmOS, SymbianOS und Windows Mobile.
Anwendungen auf mobilen Geräten sind häufig Bestandteil umfangreicherer Informationssysteme.
Sie stehen in Interaktion mit stationären Desktop-Rechnern oder Servern, von denen sie spezifische
Daten beziehen, oder an die sie im mobilen Einsatz entstandene Modifikationen zurückliefern. Es stehen einige standardisierte Verfahren zur Verfügung, Daten zwischen Computersystemen auszutauschen und abzugleichen. Inwieweit durch die Limitationen der mobilen Geräte die Verwendbarkeit
dieser Verfahren eingeschränkt wird, soll im Rahmen der folgenden Arbeit in Erfahrung gebracht
werden.
Dabei wird als Grundlage der Entwicklung mobiler Anwendungen die Java 2 Micro Edition Gegenstand der Untersuchung sein. Sie ist plattformübergreifend auf einer Vielzahl an Geräten verfügbar.
Laut Herstellerangaben wurden bis Mitte 2005 über 700 Millionen Geräte mit einer Unterstützung
für die J2ME ausgeliefert [c’t05b]. Bislang wurden allerdings hauptsächlich kleinere Spiele auf Basis der J2ME erstellt. Ob der Entwicklungsstand der Plattform mittlerweile auch die Realisierung
komplexerer mobiler Anwendungen erlaubt, soll anhand der Implementierung einiger Beispielanwendungen und Prototypen überprüft werden.
Im folgenden Kapitel werden die Struktur, die Möglichkeiten und die Einschränkungen der J2ME
Plattform erläutert. Kapitel 3 beinhaltet eine nähere Betrachtung von Konzepten und Anforderungen, die die Datensynchronisation von Anwendungen mit sich bringen. Dabei wird auch auf die
Möglichkeiten der Realisierung im Rahmen der Entwicklung mit der J2ME eingegangen. In Kapitel
4 werden die Ergebnisse einer praktischen Evaluation, bestehend aus Konzeption und Implementierung von Beispielanwendungen und Prototypen dokumentiert.
Abschließend wird im letzten Kapitel aus den vorangegangenen Überlegungen und den gesammelten Erfahrungen bei der Umsetzung ein Resümee bezüglich der momentanen Möglichkeiten der
J2ME Plattform gezogen, sowie ein Ausblick auf die zukünftige Entwicklung in diesem Bereich zu
geben versucht.
Kapitel 2
Die Java 2 Micro Edition
Die Java 2 Micro Edition ist eine Java Plattform für ressourcenbeschränkte Geräte wie Mobiltelefone, PDAs, Smartphones, Auto-Navigationssysteme oder Settop-Boxen. Es handelt sich analog zur
Java 2 Standard Edition um eine interpretierte Sprache, deren Bytecode auf einer Virtuellen Maschine
ausgeführt wird, die auf den jeweiligen proprietären Betriebssystemen der Geräte aufsetzt. Es gibt
jedoch eine Reihe von Unterschieden zur Standard Edition, die im folgenden erläutert werden.
Die Java 2 Micro Edition existiert seit 1999, als Sun Microsystems beschloss, die im Laufe der Jahre
sehr umfangreich gewordene Java Plattform in drei Editionen aufzuteilen: die Java 2 Enterprise Edition (J2EE) für serverseitige Lösungen, die Java 2 Standard Edition (J2SE) für Desktop-Applikationen
und die Java 2 Micro Edition (J2ME) für ressourcenbeschränkte Geräte [SUN99].
Zu diesem Zeitpunkt gab es eine steigende Nachfrage nach Java basierten Lösungen für kleine
Geräte, und es entstanden für diese Zwecke einige von Java 1.1 abgeleitete Plattformen mit reduzierter Funktionalität (bspw. EmbeddedJava [SUNa] oder PersonalJava [SUNd]). Die J2ME sollte hier
eine Vereinheitlichung der Entwicklung für kleine Geräte ermöglichen. Bedingt durch die differenzierten Eigenschaften der Vielzahl ressourcenbeschränkter Geräte mussten jedoch, im Gegensatz zu
den Desktop- und Servereditionen, heterogenere Anforderungen erfüllt werden. Aus diesem Grund
besteht die J2ME nicht aus einer einzelnen, sondern aus einer Sammlung von Spezifikationen. Die
Eigenschaften eines Gerätes werden dabei durch ein oder mehrere Profile spezifiziert, die jeweils auf
den Grundfunktionen einer Konfiguration basieren. Zusätzlich können optionale Pakete für spezielle
oder neue Leistungsmerkmale eines Gerätes hinzukommen.
Eine Herausforderung bei der Entwicklung der J2ME bedeutet die Gewährleistung der Plattformunabhängigkeit auf den unterschiedlichen Geräten. Sämtliche Spezifikationen der J2ME entstehen
aus diesem Grund im Rahmen des Java Community Process [JCPa] unter Beteiligung verschiedenster Firmen der Informationstechnologie- und Telekommunikationsbranche. Der JCP wurde Ende
1998 von Sun Microsystems initiiert, um einen formalen aber schnellen Weg der kooperativen Entwicklung und Aktualisierung von Java Spezifikationen zu ermöglichen. Vorschläge zu neuen JavaTechnologien oder Bibliotheken heißen Java Specification Requests (JSR) und durchlaufen einen partizipativen, durch Meilensteine bestimmten Prozess [JCPb], an dessen Ende in der Regel neben der
Spezifikation auch eine Referenzimplementierung sowie eine umfangreiche Testsuite zur Zertifizierung spezifikationskonformer Implementierungen stehen.
2.1 KONFIGURATIONEN
7
Abbildung 2.1: Konfigurationen, Profile und optionale Pakete (aus [Sch04])
Es obliegt dann den Hardwareherstellern, die Spezifikationen für ihre Geräte zu implementieren.
Das Bestehen der Kompatibilitätstests wird durch Sun überprüft und zertifiziert. Die enge Kooperation der beteiligten Unternehmen sichert die standardisierte Umsetzung und größtmögliche Verbreitung auf einer Vielzahl von Geräten unterschiedlicher Hersteller. Sämtliche Spezifikationen der
J2ME sind im Rahmen des JCP erarbeitet worden, auf dessen Webseiten detailierte Informationen zu
den einzelnen JSRs zugänglich sind [JSRa]. Insbesondere finden sich dort die Informationen zu allen, im Folgenden näher betrachteten JSRs. Auf die jeweilige explizite Angabe der Quelle wird daher
verzichtet.
2.1 Konfigurationen
Eine Konfiguration stellt die unterste Schicht der J2ME-Architektur dar. Es wird jeweils eine virtuelle
Maschine und eine Klassenbibliothek mit grundlegender Funktionalität für die darauf aufbauenden
Profile und optionalen Pakete zur Verfügung gestellt. Eine Konfiguration beschreibt somit eine allgemeinere Klasse von Geräten, während die Profile stärker auf spezielle Gerätetypen zugeschnitten
sind. Momentan sind zwei verschiedene Konfigurationen spezifiziert: Die Connected Device Configuration (CDC) im JSR-36 und die Connected, Limited Device Configuration (CLDC) im JSR-30. Sie unterscheiden sich hinsichtlich ihres Funktionsumfanges und den daraus resultierenden Anforderungen
an die Hardware der Geräte. Bedingt durch die Abhängigkeit der Profile von den Eigenschaften der
zu Grunde liegenden Konfiguration ergeben sich innerhalb der J2ME zwei getrennte Säulen.
2.1.1 Die Connected, Limited Device Configuration (CLDC)
Die CLDC wurde für kleinste Geräte, wie Mobiltelefone, Smartphones und PDAs entworfen, die
eine begrenzte Rechenleistung, geringe Speicherkapazität und niedrige Bandbreite der Netzverbindung aufweisen. Von der benötigten Speicherkapazität (160 bis 512 Kilobyte) leitet sich auch der
2.1 KONFIGURATIONEN
8
Name der verwendeten virtuellen Maschine ab – KVM steht für Kilobyte Virtual Machine. Um eine Java-Laufzeitumgebung trotz dieser begrenzter Ressourcen zu realisieren, mussten einige Einschränkungen bezüglich der Sprache selbst, der virtuellen Maschine und der Kernbibliotheken vorgenommen werden.
Unter anderem
• bietet die KVM keine Fließkomma-Arithmetik, da die Hardware vieler Geräte dies nicht unterstützt und eine Implementation in Software relativ rechen- und speicherintensiv wäre.
• fehlt der KVM die Fähigkeit zur Introspektion aus java.lang.reflect. Damit sind auch
darauf aufbauende Technologien wie Objekt-Serialisierung und Remote Method Invokation nicht
einsetzbar. (Siehe Kapitel 3)
• fehlen im Vergleich zur J2SE in Paketen einige Klassen (bspw. in java.util das Collection Framework), oder die Methoden der Klassen wurden reduziert (bspw. fehlt in
java.util.Date u.a. die toString() Methode).
• wurde das Sicherheitsmodell gegenüber der J2SE vereinfacht. Dies hat zur Folge, daß der Aufruf nativer Funktionen via Java Native Interface (JNI) nicht möglich ist, ebensowenig erlaubt die
KVM benutzerdefinierte Class Loader (Siehe Kapitel 2.4).
• musste das Verfahren zur Verifizierung des Bytecodes geändert werden. Die KVM übernimmt
nur einen Teil dieses Prozesses – der rechen- und speicherintensive Part, Preverification genannt,
wird schon bei der Erstellung der Anwendung vorgenommen (Siehe Kapitel 2.4).
• unterstützt die KVM zwar nebenläufige Threads, allerdings keine ausgefeilteren Funktionen,
wie Thread-Groups oder Daemon-Threads.
• ist die Größe von Anwendungen auf maximal 64 Kilobyte beschränkt. Die parallele
Ausführung mehrerer Anwendungen ist nicht möglich.
• wurde die Speicherverwaltung (Garbage Collection) den Einschränkungen angepasst. Entfernt
wurden dabei auch alle Möglichkeiten der Anwendung, auf die Speicherverwaltung Einfluss
zu nehmen.
Trotz dieser Einschränkungen wurde die Konsistenz zur Klassenbibliothek der J2SE in weiten Teilen
erreicht. Die CLDC besteht aus den Paketen java.lang (Fundamentale Klassen), java.util (Kollektionen, Datum und Uhrzeit, Zufallszahlengenerator) und java.io (Stream- und Readerklassen
für Ein- und Ausgaben), welche eine echte Teilmenge der gleichnamigen Klassen der J2SE darstellen. Änderungen sind durch die oben angeführten Limitationen der KVM, sowie die Bereinigung
von veralteten Methoden und Klassen bedingt.
Die Verwaltung von Netzwerkverbindungen, die sich bei der Standard Edition im Paket java.net
findet, wurde umstrukturiert: Die CLDC bringt einen einheitlichen Ansatz zum Behandeln von Verbindungen, das Generic Connection Framework (GCF), das im Paket javax.microedition.io untergebracht ist. Die CLDC selbst spezifiziert jedoch nur allgemeine Schnittstellen, während die konkreten Verbindungsprotokolle in den Profilen implementiert werden.
Anfang 2003 wurde die Version 1.1 der CLDC-Spezifikation fertiggestellt (JSR-139), die hauptsächlich
die Unterstützung von Fließkommaoperationen festschreibt. Die Verbreitung kompatibler Geräte ist
momentan recht gering. Zudem gibt es noch kein Profil, welches diese Version explizit erfordern
2.2 P ROFILE
9
würde.
2.1.2 Die Connected Device Configuration (CDC)
Bezüglich Rechenleistung und Speicher findet sich zwischen den kleinsten mobilen Geräten und der
Desktop Welt, eine weitere Klasse von Geräten, für die die Connected Device Configuration (CDC) gedacht ist. Dazu gehören größere PDAs, Navigations- bzw. Multimediasysteme für das Auto oder TVSettop Boxen. Die typische Hardware dieser Klasse von Geräten besteht aus einem 32-bit Prozessor,
mindestens zwei Megabyte Speicher sowie einer oft dauerhaften Netzverbindung mit vergleichsweise hoher Bandbreite.
Somit ist in der CDC eine vollständige virtuelle Maschine vorgesehen, die auf geringen Speicherbedarf optimiert wurde, die Compact Virtual Machine (CVM). Im Vergleich zur VM der Standard Edition
ist die Garbage Collection der geringeren Speicherausstattung angepasst, und es fehlen die Hotspot
Techniken zur Laufzeitoptimierung – funktional sind beide jedoch identisch.
Die Klassenbibliothek der CDC bildet nur eine minimale Basis. Zusammen mit den darauf aufbauenden Profilen ergibt sich jedoch ein relativ vollständiges Abbild des Kerns der J2SE API in Version
1.3 (Siehe Kapitel 2.2.3). Im Zuge der Weiterentwicklung der CDC Plattform (JSRs 216 bis 219) soll
weitestgehende Kompatibilität zur Version 1.4 der J2SE erreicht werden. Möglich scheint dies nicht
zuletzt durch die steigende Leistungsfähigkeit der Hardware dieser Geräteklasse.
2.2 Profile
Die Profile bauen auf den Basisfunktionalitäten der Konfigurationen auf und sind stärker auf einen
bestimmten Gerätetyp zugeschnitten. Sie beinhalten beispielsweise Schnittstellen zur Ein-/Ausgabe
oder zur persistenten Datenhaltung.
Oberhalb der CLDC sind zwei Profile spezifiziert: das Mobile Information Device Profile (MIDP), welches sich den Möglichkeiten und Einschränkungen von Mobiltelefonen und Smartphones widmet,
und das Information Module Profile (IMP) für per Mobilfunk vernetzte Systeme, beispielsweise in Getränkeautomaten. Die Arbeit an einem weiteren auf der CLDC basierenden Profil, dem PDA Profile
(PDAP), wurde mittlerweile eingestellt. Stattdessen soll die für PDAs benötigte Funktionalität durch
zwei optionale Pakete für das MIDP realisiert werden (Siehe Kapitel 2.3.1).
Auf der Seite der CDC existieren drei Profile, die aufeinander aufbauen und sich im Wesentlichen
durch den Umfang der Unterstützung graphischer Oberflächen unterscheiden.
2.2.1 Das Mobile Information Device Profile (MIDP)
Das am weitesten verbreitete Profil der J2ME ist das Mobile Information Device Profile (MIDP). Die
große Mehrzahl an Mobiltelefonen oder Smartphones wird heute mit Unterstützung für Java und
damit dem MIDP ausgeliefert.
Anwendungen für das MIDP, sogenannte Midlets, durchlaufen während der Ausführung einen Lebenszyklus ähnlich dem der Java Applets. Gesteuert wird dieser von einer speziellen, in jedem MIDP
2.2 P ROFILE
10
Paket
Inhalt
java.microedition.io
Das Generic Connection Framework ist im MIDP um
Deklarationen für die Protokolle UDP, HTTP, HTTPS
und SSL sowie für die Kommunikation über serielle
Schnittstellen erweitert.
java.microedition.midlet
Grundfunktionalität für Applikationen, unter anderem
Steuerung des Lebenszyklus.
java.microedition.lcdui
Das Lowest Common Denominator Interface (LCDUI)
unterstützt die Implementierung von Bedienoberflächen.
javax.microedition.game
Das Game API vereinfacht die Programmierung von
2D-Spielen.
javax.microedition.media
Das MIDP 2.0 Media API (M2MAPI) dient der Wiedergabe und Aufzeichnung von Medien.
javax.microedition.pki
Dieses Paket repräsentiert Zertifikate einer Pubic Key
Infrastructure. Die Zertifikate werden unter anderem
bei sicheren Verbindungen über SSL und HTTPS eingesetzt.
javax.microedition.rms
Das Record-Management-System (RMS) ist eine einfache, satzorientierte Datenbankschnittstelle, über die
sich persistente Daten im Endgerät verwalten lassen.
Tabelle 2.1: Pakete des MIDP 2.0 Profils
kompatiblen Gerät vorhandenen Komponente, der Application Management Software (AMS), die auch
für Installation, Updates und die Einhaltung des Sicherheitskontextes verantwortlich ist. Die AMS
steuert immer nur eine Anwendung, die gleichzeitige Ausführung mehrerer Anwendungen (Multitasking) ist nicht möglich.
Das MIDP beinhaltet eine eigene, nicht zum AWT oder Swing kompatible Benutzungsschnittstelle (javax.microedition.lcdui). Diese gliedert sich in einen Low-Level Teil, der einen vollen
Zugriff auf das Display des Gerätes bietet, und eine High-Level API, die eine einfache Verwendung gängiger Elemente wie Dialoge, Formulare oder Listen ermöglicht. Die konkrete Ausgestaltung und Anordnung dieser Elemente geschieht entsprechend des gerätespezifischen Look-and-Feel
weitgehend automatisch. Mit dem Record-Management-System (RMS) wird eine Schnittstelle für die
persistente Datenhaltung integriert, und das Generic Connection Framework wird im MIDP um die
Protokolle UDP und HTTP erweitert.
Aufbauend auf der in JSR-37 spezifizierten ersten Version des MIDP gibt es seit Ende 2002 das MIDP
in Version 2.0 (JSR-118). Es bringt ein neues, feiner abgestuftes Sicherheitsmodell inklusive der
Möglichkeit zur automatischen Aktivierung von Programmen über das Netz mittels Push Registry
(siehe Kapitel 3.4). Die Fähigkeiten der Benutzeroberfläche wurden erweitert, sowie eigene Schnitt-
2.2 P ROFILE
11
stellen für Multimedia- und Spielfunktionalitäten hinzugefügt. MIDP 2.0 ist ungefähr seit Mitte 2004
das gängige Profil neuer Mobiltelefone. Einen guten Anhaltspunkt bieten die Grafikfähigkeiten des
Gerätes: Ist ein Farbdisplay vorhanden, wurde in den meisten Fällen auch die Version 2.0 des MIDP
implementiert.
Angesichts der hohen Verbreitung dieses Profils und der umfassenden Beteiligung von
Geräteherstellern und Mobilfunkprovidern am Spezifikationsprozess scheint die Weiterentwicklung gesichert zu sein. Die Arbeiten an der nächsten Version (JSR-271) laufen momentan und sollen
im Laufe des Jahres 2006 abgeschlossen werden.
2.2.2 Das Information Module Profile (IMP)
Das Einsatzgebiet des Information Module Profile (IMP) sind Module im Bereich der Machine-toMachine-Kommunikation, die Mobilfunknetze nur zur Datenübertragung verwenden und keine Benutzungsoberfläche benötigen. Diese Module finden sich als Komponenten beispielsweise in Automaten oder Ortungseinheiten. So könnte ein Getränkeautomat mit dem IMP selbständig Nachschub
ordern, oder ein Nutzer könnte die aktuelle Position eines IMP-Gerätes mit angeschlossenem GPSEmpfänger feststellen.
Das IMP in Version 1.0 (JSR-195) stellt eine echte Teilmenge des MIDP 1.0 dar. Version 2.0 (JSR228) basiert auf dem MIDP 2.0 und erbt damit auch dessen Sicherheitsfunktionalitäten und die
Möglichkeit der Aktivierung über das Netz. Via GCF können auch serielle Schnittstellen genutzt
werden, um Leuchtanzeigen oder kleine LCDs anzusteuern.
2.2.3 Die Profile der CDC
Die CDC-basierten Profile sind durchweg an die J2SE in Version 1.3 angelehnt, um die Erstellung
von mobilen Anwendungen für Entwickler mit Java Kenntnissen zu erleichtern. Das Foundation Profile (JSR-46) erweitert die CDC nahezu vollständig um den Kern der J2SE API, ergänzt um das Paket
javax.microedition.io, zur leichteren Portierung von CLDC-Anwendungen, bietet aber keinerlei Funktionalität im Bezug auf graphische Oberflächen. Das Personal Basis Profile (JSR-129) beinhaltet das Foundation Profile und stellt zusätzlich einen Teil des Abstract Window Toolkit (AWT) für
einfache graphische Oberflächen zur Verfügung. Das Personal Profile (JSR-62) beinhaltet beide vorigen Profile und bietet neben der vollständigen AWT-API auch die Verwendung von Applets. Es ist
zudem zur Migration von Anwendungen des JDK 1.1 basierten J2ME-Vorgängers PersonalJava vorgesehen.
Durch diese Abstufung der graphischen Darstellungsmöglichkeiten eignen sich die Profile der CDC
für relativ unterschiedliche Geräte. Je nach Eigenschaften der Benutzungsoberfläche muss nur der
hierfür nötige Teil der Profile zur Verfügung gestellt werden. Zukünftig soll die J2SE API auch in
Version 1.4 umgesetzt werden, die Weiterentwicklung der CDC und der zugehörigen Profile findet
sich in den JSRs 216 bis 219. Zusätzlich ist zur Gestaltung anspruchsvoller grafischer Oberflächen
mit dem Advanced Graphics and User Interface Optional Package (JSR-209) eine Implementierung des
Swing-Frameworks geplant, die auf der nächsten Version des Personal Profile aufbauen soll.
2.3 O PTIONALE PAKETE
12
2.3 Optionale Pakete
Optionale Pakete stellen Funktionalitäten bereit, die nur für spezielle Anwendungen relevant sind
oder von Hardwaremerkmalen abhängen, die nicht unbedingt in allen Geräten einer Klasse vorhanden sind. Die optionalen Pakete ermöglichen eine verbesserte Nutzung der Eigenschaften der
Ablaufumgebung durch die J2ME-Anwendungen und schließen damit die Lücke zu den nativen
Anwendungen.
Andererseits sinkt die Portabilität von Anwendungen, die optionale Pakete voraussetzen, und es
entsteht die Gefahr einer weiteren Fragmentierung der J2ME-Plattform. Ein Versuch, dieser Problematik entgegenzuwirken, stellt die aus dem JSR-185 hervorgegangene Spezifikation Java Technology
for the Wireless Industrie (JTWI) dar. Sie ergänzt das MIDP um die optionalen Pakete Wireless Messaging und Mobile Media API und fordert zusätzlich ein Farbdisplay mit höherer Auflösung. Damit
sollen die Grundfunktionalitäten momentan gängiger Mobiltelefone für J2ME-Anwendungen bereitgestellt, und das Ganze mit einem prägnanten Label versehen werden.
Im Folgenden werden einige optionalen Pakete kurz vorgestellt, die im Kontext der Personalisierung
und der Datenübertragung und -synchronisation von besonderem Interesse sind.
2.3.1 Das Personal Information Management und das FileConnection API
Die Spezifikation zum Personal Information Management (PIM) API findet sich im JSR-75. Ursprünglich vorgesehen war die Definition eines eigenständigen Profils für PDAs auf Basis der CLDC,
dieser Plan wurde jedoch verworfen. Stattdessen sollen zwei separate, optionale Pakete für das MIDP
die für PDAs benötigte Funktionalität realisieren: Das FileConnection API für den Zugriff auf das
Dateisystem des Gerätes bzw. von Speicherkarten, sowie das PIM API als Schnittstelle zu den internen Datenbanken für Kalender, Telefonbuch und To-Do-Listen.
Beide Funktionen werfen Fragen der Sicherheit auf, die erst auf Basis des MIDP 2 Profils zufriedenstellend gelöst werden konnten. Die Spezifikationen wurden im Juni 2004 verabschiedet, erste
Geräte, die diese APIs implementieren, sind seit dem Frühjahr 2005 verfügbar.
2.3.2 Das Wireless Messaging API
Das im JSR-120 spezifizierte Wireless Messaging API (WMA) ermöglicht J2ME-Anwendungen den Zugriff auf die Sende- bzw. Empfangsschnittstelle für Kurzmitteilungen (SMS). Dies können neben normalen Textmitteilungen auch Binärnachrichten sein. Die Verbindung wird wie bei der CLDC üblich
über das Generic Connection Framework abgewickelt – die URL besteht dabei aus dem Protokollnamen
sms:// gefolgt von der Telefonummer des Empfängers.
Der Empfang von Kurznachrichten erfolgt durch eine laufende Anwendung oder per Aktivierung
über die Push Registry, wozu eine Portnummer zur Identifikation an die URL angehängt werden
muss. Version 2.0 der WMA (JSR-205) unterstützt zusätzlich auch den Multimedia Message Service
MMS, über den verschiedene Formate (Texte, Bilder, Audio oder Video) mit einer Nachricht verschickt werden können.
2.3 O PTIONALE PAKETE
13
2.3.3 Die Java APIs für Bluetooth
Bluetooth ist eine Technologie zur drahtlosen Datenübertragung auf kurzen Distanzen. Für die J2ME
steht ein in JSR-82 spezifiziertes optionales Paket zur Verfügung, welches Schnittstellen zur Kommunikation über Bluetooth-Verbindungen bietet.
Das API fällt recht umfangreich aus, da neben verschiedenen, aufeinander aufbauenden Protokollen auch die Suche nach Diensten bzw. Geräten, sowie Sende- und Empfangsschnittstellen enthalten
sind (mehr dazu in Kapitel 3.5).
2.3.4 Das Remote Method Invocation Optional Package
Die Remote Method Invocation (RMI) [RMI] ermöglicht innerhalb der Java Plattform den Aufruf von
Methoden entfernter Objekte, sogenannte Remote Procedure Calls (RPC). Für den Entwickler geschieht
der Vorgang recht transparent, ein entfernter Methodenaufruf unterscheidet sich kaum von einem lokalen – die Kommunikationsfunktionen sind in einer automatisch generierbaren Klasse, dem Stub,
gekapselt.
Die RMI API (JSR-66) steht als optionales Paket ausschließlich für die CDC zur Verfügung. Es beinhaltet nur die für Clients benötigte Funktionalität, Serverdienste können auf mobilen Geräten nicht
angeboten werden.
2.3.5 Die J2ME Web Services Specification
Die Web Services ermöglichen es, ähnlich den RPCs, auf die Funktionalität entfernter Komponenten
zuzugreifen. Im Gegensatz zur auf die Java Welt beschränkten RMI verwenden Web Services jedoch
eine auf der Extensible Markup Language (XML) basierende standardisierte Kodierung, welche einen
hohen Grad an Interoperabilität gewährleisten soll.
JSR-172 spezifiziert eine Schnittstelle zur Nutzung von Web Services mit der J2ME – die serverseitige Bereitstellung von Diensten entfällt auch hier. Da die Profile der CLDC den Umgang mit XMLDokumenten nicht beherrschen, bringt das Paket neben der Unterstützung des zur Kommunikation
verwendeten Simple Object Access Protocols (SOAP) auch einen XML Parser mit (mehr dazu in Kapitel
3.2).
2.3.6 Das JDBC Optional Package
Java Database Connectivity (JDBC) bezeichnet eine einheitliche Schnittstelle zu relationalen Datenbanken verschiedener Hersteller auf der Java-Plattform. Die API beinhaltet den Aufbau von Datenbankverbindungen, die Übermittlung von SQL-Abfragen und die Transformation und Bereitstellung der
gelieferten Ergebnisse für das Java Programm.
Das optionale JDBC Paket (JSR-169) ermöglicht einen direkten Datenbankzugriff für mobile Anwendungen, ist allerdings nur auf Basis der CDC spezifiziert. Das API stellt eine echte Teilmenge des
java.sql Paketes aus der Standard Edition dar.
2.4 S ICHERHEIT
14
2.4 Sicherheit
Die Nutzung von Anwendungen auf mobilen Geräten stellt an die Ablaufumgebung hohe Anforderungen bezüglich der Sicherheit. Diese muss einerseits gewährleisten, dass eine fehlerhafte
Anwendung nicht zu einem Absturz des Gerätes führen oder Systemdaten (beispielsweise die des
Adressbuchs) korrumpieren kann, andererseits muss auch der Zugriff auf bestimmte Ressourcen
des Systems überwacht werden. So sollte zum Beispiel eine Netzverbindung nur dann aufgebaut
werden können, wenn der Benutzer dies auch wünscht.
Die Java 2 Standard Edition verfügt über ein umfangreiches Sicherheitsmodell, mit dessen Hilfe Code
aus unterschiedlichen Quellen ein differenzierter Zugriff auf Systemressourcen gewährt werden
kann. In der CDC sind diese Sicherheitsfunktionen ebenfalls vorhanden, die CLDC muss wegen
der Ressourcenbeschränkungen darauf verzichten. Aus diesem Grund ist die virtuelle Maschine
der CLDC sehr restriktiv konzipiert. Sie erlaubt keine Aufrufe nativer Funktionen, ebensowenig
benutzerdefinierte Class Loader.
Die einzige Möglichkeit, diese Beschränkungen zu umgehen, besteht in der Modifizierung der KVM
selbst – dies ist jedoch im Allgemeinen nur den Herstellern der Geräte möglich. Als Konsequenz
daraus können auf die CLDC gründende Profile und optionale Pakete nicht nachträglich installiert
werden. Eigene Erweiterungen zur Nutzung nativer Komponenten sind ebenfalls nicht realisierbar.
Auch das Verfahren zur Verifizierung des Bytecodes einer Anwendung musste modifiziert werden.
In der J2SE werden alle aus externen Quellen geladenen Klassen einem Integritätscheck unterzogen,
um die Sicherheit des Systems zu gewährleisten. Dieser Algorithmus hätte die begrenzten Ressourcen mobiler Geräte überfordert; so kommt für die CLDC stattdessen ein zweistufiges Verfahren zum
Einsatz, bei dem der rechen- und speicherintensive Teil, die sogenannte Preverification, schon bei der
Erstellung der Anwendung vorgenommen wird. Dabei werden spezielle StackMap-Attribute in die
.class Datei eingefügt, welche die Verifikation zur Laufzeit wesentlich vereinfachen.
Für den Zugriff auf Sicherheitskritische Ressourcen über die APIs der J2ME wurde in Version 2.0
der MIDP-Spezifikation ein neues Berechtigungsmodell eingeführt. Nötig wurde dies nicht zuletzt
durch eine steigende Anzahl von Paketen, die auf native Ressourcen zugreifen, beispielsweise auf
das Dateisystem der Geräte, interne Datenbanken oder spezielle Funkverbindungen, wie Bluetooth,
Push-Dienste oder SMS. Anwendungen, deren Integrität durch ein Zertifikat überprüft werden kann,
werden als vertrauenswürdig (trusted) eingestuft. Allen anderen (also auch allen MIDP 1.0 kompatiblen) verwehrt die Laufzeitumgebung den Zugriff auf bestimmte Schnittstellen gänzlich, während
sie für andere jeweils den Nutzer um Erlaubnis fragen müssen.
Die vertrauenswürdigen Anwendungen werden bei der Installation je nach Herkunft ihrer Zertifikate verschiedenen Sicherheitsdomänen (Security Domain) zugeordnet. Eine Sicherheitsdomäne definiert eine Reihe von Berechtigungen (Permissions), die jeweils eine bestimmte Funktionalität regeln. Der Name der Berechtigung leitet sich dabei von dem Paket oder der Klasse ab, welche die
gewünschte Funktionalität ermöglichen. Beispielsweise wird die Erlaubnis, HTTP-Verbindungen
aufzubauen, anhand der Berechtigung java.microedition.io.Connector.http überprüft. Es
gibt Allowed Permissions, die in einer bestimmten Sicherheitsdomäne grundsätzlich zur Verfügung
stehen, und User Permissions, bei denen eine Rückfrage an den Benutzer gestellt wird. Hier wird
2.4 S ICHERHEIT
15
zusätzlich festgehalten, ob die Erlaubnis dauerhaft (blanket) oder nur für eine Sitzung (session) bzw.
den aktuellen Aufruf (oneshot) erteilt wird.
Das Zertifizierungsverfahren nutzt asymmetrische Verschlüsselungsalgorithmen und kann mehrstufig erfolgen (Bildung von Zertifikatketten, einer sogenannten Chain of Thrust). Der Anbieter einer
Anwendung bildet eine Prüfsumme über das zu installierende Archiv (der .jar-Datei) und verschlüsselt diese mit seinem privaten Schlüssel. Die Prüfsumme und der öffentliche Schlüssel (das
Zertifikat) werden dann im Applikatonsdeskriptor (der .jad-Datei) mitgeliefert. Dadurch kann eine Manipulation des Archivs erkannt werden, allerdings nur, wenn der Applikationsdeskriptor aus
einer vertrauenswürdigen Quelle stammt. Um dies zu gewährleisten kann ein Zertifikat selbst noch
einmal signiert werden, und zwar letzten Endes von einer anerkannten Certificate Authority, deren
öffentlicher Schlüssel im Endgerät fest gespeichert wurde. Der Grund für dieses Vorgehen liegt in der
begrenzten Speicherkapazität der Geräte, die Schlüssel sämtlicher relevanter Anbieter zu speichern
wäre nicht praktikabel. Es ist für den Benutzer allerdings auch nicht möglich, zusätzliche Schlüssel
hinzuzufügen. Anwendungen, die nur mit einem Schlüssel des Entwicklers signiert wurden (sogenannte Self-Signed Certificates) können nicht installiert werden!
Anwendungen für die CLDC laufen also grundsätzlich innerhalb einer sehr beschränkten SandboxUmgebung, der Zugriff auf kritische, native Schnittstellen ist reglementiert. Allerdings ist die Sicherheit des Systems auch nur gewährleistet, solange keine Möglichkeit besteht, aus der Sandbox
auszubrechen. Eine Methode, dies zu erreichen, wurde Ende 2004 veröffentlicht [c’t04a]. Dabei wurde unter anderem eine Lücke in der Preverification ausgenutzt, die dazu führt, dass eine speziell
präparierte Anwendung die Überprüfung zur Laufzeit passieren und auf Speicherbereiche außerhalb der Sandbox zugreifen kann. Auch in den Bluetooth-Implementierungen vieler aktueller Mobiltelefone wurden Schwachstellen gefunden, die den Zugriff auf sensible Funktionen von außerhalb
ermöglichen [c’t04c].
Da ein Update der KVM bislang nur über das Einspielen einer neuen Firmware des Gerätes möglich
ist, sind derartige Sicherheitslücken als sehr kritisch anzusehen: Die Hersteller erlauben den Austausch der Firmware nur durch ihre Servicepartner, sodass die Geräte der allermeisten Nutzer wohl
anfällig bleiben werden.
Abhilfe scheint aber in Sicht zu kommen: Die Spezifikationen zum Mobile Operational Management
(JSR-232) sollen bis Ende 2005 fertiggestellt werden. Systemadministratoren und Mobilfunkbetreiber sollen hierdurch in die Lage versetzt werden, veröffentlichte Softwareupdates und Modulergänzungen einfacher an die mobilen Geräte zu verteilen [c’t05b]. Der Verlauf der weiteren Entwicklung bleibt allerdings abzuwarten. Die Gerätehersteller sehen eine mögliche Lösung dieses Problems
wohl auch in der Kontrolle der Installation von Anwendungen mithilfe der Signierung. Anstatt die
Software ihrer Geräte erst in einem ausgereifteren Zustand auf den Markt zu bringen, stellen sie ge”
prüfte“ Anwendungen bereit und können sich so zusätzlich als Zwischenhändler für mobile Downloads etablieren. Aus dem für das Jahr 2008 prognostizierten Marktvolumenen von MultimediaContent auf Mobiltelefonen in Höhe von 70 Milliarden Euro [c’t04b] ergibt sich eine verlockende
Perspektive für die Gerätehersteller.
Kapitel 3
Datensynchronisation und J2ME
Anwendungen auf mobilen Geräten stehen als Teil umfangreicherer Informationssysteme häufig in
Interaktion mit stationären Computern, von denen sie spezifische Daten beziehen, oder an die sie im
mobilen Einsatz entstandene Modifikationen zurückliefern. Oftmals ist dabei eine dauerhafte Verbindung zum stationären Teil des Systems nicht möglich oder zu langsam bzw. kostspielig, sodass
ein kontinuierlicher Abgleich der Daten nicht praktikabel ist. In diesen Fällen muss später ein Austausch in beide Richtungen erfolgen, bei dem die Aktualität der Daten wieder hergestellt wird. Die
Limitationen der Geräte erfordern in vielen Fällen den Einsatz spezieller Proxy-Lösungen, bei denen
Informationen für die mobilen Anwendungen eigens aufbereitet werden.
Im Folgenden werden standardisierte Verfahren beschrieben, Daten zwischen Computersystemen
auszutauschen und abzugleichen, die im Rahmen der anschließenden Evaluation auf ihre Verwendbarkeit in Anwendungen auf Basis der J2ME untersucht werden.
Zunächst werden Besonderheiten im Hinblick auf die grundlegenden Kommunikationsmöglichkeiten
der J2ME gezeigt. Sollen mobile Anwendungen ausschließlich diese einfachen Kommunikationsprotokolle nutzen, müssen geeignete Datenformate und Synchronisationsprotokolle eigens entworfen
werden. Der Vorteil dieser Vorgehensweise liegt in einer effizienten Nutzung der Geräteressourcen,
Nachteile sind die mangelnde Kompatibilität zu anderen Anwendungen und die erforderliche Implementierung geeigneter Methoden für die Kommunikation.
Webservices ermöglichen die plattformunabhängige Übertragung strukturierter Daten, stellen aber
durch die Verwendung XML-basierter Nachrichten erhöhte Anforderungen an die Bandbreite der
Verbindung und die Leistungsfähigkeit der Geräte. Geeignete Verfahren zur Datensychronisation
müssen jedoch auch bei der Verwendung von Webservices entworfen werden.
Noch höhere Anforderungen an die Hardware der Geräte stellt das ebenfalls auf dem Austausch
von XML-Nachrichten basierende SyncML-Protokoll. Dafür bietet es ein sehr ausgereiftes und standardisiertes Konzept zur Datensynchronisation.
Ein direkter Datenaustausch zwischen mobilen Anwendungen kann durch die Verwendung von lokalen Bluetooth-Funkverbindungen durchgeführt werden. Damit eröffnen sich neue Möglichkeiten;
es ergeben sich aber auch Probleme hinsichtlich der Synchronisation der Daten.
3.1 KOMMUNIKATIONSPROTOKOLLE IN DER J2ME:
DAS G ENERIC C ONNECTION F RAMEWORK
17
CLDC
<<creates>>
Connector
<<Interface>>
(Connection Factory)
<<exception>>
Connection
Profile /
optionale Pakete
ConnectionNotFoundException
<<Interface>>
<<Interface>>
<<Interface>>
<<Interface>>
Datagram Connection
Input Connection
Output Connection
StreamConnectionNotifier
beispielsweise
<<Interface>>
MessageConnection
(WMA)
L2CAP (Bluetooth)
<<Interface>>
Stream Connection
<<Interface>>
beispielsweise
<<Interface>>
FileConnection
RFComm (Bluetooth)
Content Connection
MIDP 2.0
<<Interface>>
UDPDatagram Connection
Push Registry
<<Interface>>
Comm Connection
<<Interface>>
Socket Connection
<<Interface>>
Secure Connection
<<Interface>>
HTTP Connection
<<Interface>>
ServerSocket Connection
<<Interface>>
HTTPS Connection
Abbildung 3.1: Das Generic Connection Framework
3.1 Kommunikationsprotokolle in der J2ME:
Das Generic Connection Framework
Bei der Entwicklung der J2ME wurde der Bereich Netzwerkkommunikation im Vergleich zur J2SEAPI neu strukturiert, hauptsächlich weil der Umfang des java.net Paketes den Speicherbedarf der
mobilen Geräte zu sehr erhöht hätte. Daneben stand auch der Wunsch, einen konsistenteren Umgang mit den verschiedenen Kommunikationsprotokollen und eine höhere Flexibilität hinsichtlich
des Austauschs der herstellerspezifischen Implementierungen zu ermöglichen. Es entstand das Generic Connection Framework (GCF), ein überwiegend auf Interfaces aufgebautes API.
Alle Arten von Verbindungen werden über die statische Methode Connector.open() der Connection Factory geöffnet. Dabei wird ein String übergeben, dessen Anfang das jeweilige Protokoll definiert,
gefolgt von einer Netzwerkadresse in einem protokollabhängigen Format. Beispielsweise initialisiert
• http://host:port/file eine HTTP-Verbindung,
• socket://host:port einen Socket für ausgehende TCP-Verbindungen,
• socket://:port einen Socket für eingehende TCP-Verbindungen (keine Hostangabe),
• btspp://deviceID:ServiceUID eine Bluetooth RFComm-Verbindung,
• sms://telefonnummer[:port] eine MessageConnection für Kurzmitteilungen,
• file:///<wurzel>/<verzeichnis> den Zugriff auf das Dateisystem.
Zurückgeliefert wird ein Connection-Objekt, welches je nach ausgewähltem Protokoll ein entsprechend von Connection abgeleitetes Interface implementiert. Dieser Ansatz erlaubt die Un-
3.2 W EBSERVICES
18
terstützung verschiedener Verbindungsarten unter Beibehaltung eines großen Teils des Codes der
Anwendung.
Im MIDP 2.0 ist nur die Unterstützung der Protokolle HTTP und HTTPS zwingend vorgeschrieben,
alle anderen sind als optional ausgewiesen. Dies scheint zunächst etwas verwunderlich, da HTTP zumeist auf TCP als Transportprotokoll aufsetzt. In Mobilfunknetzen arbeitet TCP jedoch relativ ineffizient: Protokollseitige Mechanismen, wie Flusskontrolle oder Quittungen, die für eine zuverlässige
Datenübertragung sorgen, vertragen sich relativ schlecht mit der vergleichsweise hohen Fehlerrate
und Latenzzeit in diesen Netzen. Deshalb wird auf einigen Mobiltelefonen HTTP nicht per TCP/IP,
sondern über das Wireless Session Protocol (WSP) [WSP] transportiert. Dieses wurde speziell auf die
Eigenschaften von Mobilfunknetzen abgestimmt und bietet darüber hinaus einige neue Funktionen,
beispielsweise eine Unterstützung für Sessions. Analog kann als sicheres Transportprotokoll statt Secure Sockets Layer (SSL) bzw. Transport Layer Security (TLS), Wireless Transport Layer Security (WTLS)
[WTL] verwendet werden. In diesen Fällen läuft die Kommunikation über ein WAP-Gateway, das
die Umsetzung der WAP-spezifischen Protokolle auf TCP bzw. TLS/SSL vornimmt.
Bidirektionale Kommunikation, beispielsweise zur Realisierung des Datenaustausches zwischen
zwei mobilen Geräten, setzt die Verwendung von Protokollen der Transportschicht voraus. Um
einen TCP-Serverdienst zu registrieren wird Connector.open() mit einem Parameter der Form
socket://:port aufgerufen. Das Interface StreamConnectionNotifier bietet für einen solchen ServerSocket die Methode acceptAndOpen(), die wartet, bis ein Client eine Verbindung
zum lokalen Endpunkt aufbaut und anschließend eine SocketConnection-Instanz zurückliefert.
Die Möglichkeiten von Serverdiensten werden durch die Aktivierung der Anwendung via Push Registry noch erweitert (siehe Kapitel 3.4).
Einige, bei der Kommunikation über HTTP mitunter benötigte Funktionen müssen weiterhin in
die Anwendung selbst integriert werden. Werden beispielsweise vom Server Cookies zum SessionTracking vorausgesetzt, muss die Anwendung dies explizit implementieren, ebenso fehlt im GCF
die automatische Behandlung von HTTP-Redirects. Davon abgesehen bietet das GCF aber einen
Komfort im Umgang mit Netzverbindungen, der die Berücksichtigung von Low-Level Eigenarten
der Protokolle in vielen Fällen überflüssig macht.
3.2 Webservices
Webservices dienen dem Datenaustausch und entfernten Funktionsaufrufen zwischen heterogenen
Informationssystemen bzw. Anwendungen über Netzwerke. Für diesen Zweck wurden eine Reihe von offenen Protokollen und Standards definiert, deren Einhaltung eine weitgehende Interoperabilität zwischen verschiedenen Programmiersprachen und Betriebssystemen sicherstellen soll
[Ngh02]. Die Entwicklung wird von herstellerübergreifenden Organisationen, namentlich dem World
Wide Web Consortium (W3C) [W3Ca] und der Organization for the Advancement of Structured Information
Standards (OASIS) [OAS] koordiniert.
3.2 W EBSERVICES
19
3.2.1 Der Aufbau von Webservices
Das Format sämtlicher Protokolle und Standards im Rahmen der Webservices basiert auf der Extensible Markup Language (XML). Die Verwendung von stardardisierten XML-Formaten ermöglicht die
Plattform- und Sprachunabhängigkeit der Webservices und führt zu mensch- und maschinenlesbaren
Nachrichten.
Als Kommunikationsprotokoll und zur Serialisierung der Daten wird zumeist das Simple Object Access Protocol (SOAP) [SOA] genutzt. Ein Client sendet einen Request mittels SOAP an einen Server,
der die gewünschte Funktion einer Anwendung aufruft und das Ergebnis wieder per SOAP an den
Client zurück sendet. In der Regel wird SOAP mittels HTTP transportiert, um z.B. Probleme mit Firewalls zu vermeiden. Alternativ können aber auch andere Transportprotokolle verwendet werden,
beispielsweise das Simple Mail Transfer Protocol (SMTP), das Wireless Session Protocol (WSP) oder das
Object Exchange Protocol (OBEX siehe Kapitel 3.5),.
Zur Beschreibung der Funktionalität eines Webservices dient die Web Services Description Language
(WSDL) [W3Cc]. Ein WSDL-Dokument beinhaltet die Datenstrukturen und Schnittstellen der angebotenen Funktionen eines Webservies. Da diese recht komplex werden können ermöglichen viele
Frameworks die automatische Generierung von WSDL-Dokumenten und Serverklassen (sogenannten Skeletons) anhand des Codes der Anwendung, die als Webservice bereitgestellt werden soll.
Analog dazu wird oft auch der clientseitige Code zur Nutzung eines Webservices anhand des vom
Server bezogenen WSDL-Dokuments automatisch generiert. Ein sogenannter Stub sorgt für die Komposition des Request und die Analyse der Response. Der Entwickler muss den Stub nur noch in die
Anwendung integrieren und kann über diesen die Funktionalität des Webservices nutzen:
MensaWebService stub=new MensaWebService(url);
WeekData thisWeek = stub.getThisWeek();
WeekData nextWeek = stub.getNextWeek();
Bis auf die Notwendigkeit der Behandlung von Ausnahmen, die im Zusammenhang mit Fehlern bei
der Kommunikation mit dem Server entstehen können, unterscheiden sich somit entfernte Aufrufe
syntaktisch nicht von lokalen.
3.2.2 Webservices in der J2ME
Zur Nutzung von Webservices im Rahmen der J2ME wurde im JSR-172 ein optionales Paket für CDC
und CLDC spezifiziert. Das WS-API beinhaltet Funktionen zum Parsen von XML-Dokumenten und
ermöglicht die Nutzung entfernter Dienste mittels SOAP. Die serverseitige Bereitstellung von Diensten ist dagegen nicht Bestandteil der Spezifikation.
Zur Analyse von XML-Dokumenten haben sich in der Java-Welt die Java APIs for XML Processing
(JAXP) [JAXb] etabliert. Diese stellen zwei unterschiedliche Methoden des Umgangs mit XML-Daten
zur Verfügung: Die erste besteht in einer ereignisgesteuerten, sequentiellen Verarbeitung, während
bei der zweiten Methode das gesamte Dokument analysiert und in Form eines hierarchischen Objektbaums zugänglich gemacht wird. Das WS-API beinhaltet mit dem Simple API for XML Parsing (SAX)
3.2 W EBSERVICES
20
zur sequentiellen Verarbeitung von XML-Daten nur einen Teil des JAXP; das umfangreichere Document Object Model (DOM) wird wegen des ungleich höheren Ressourcenbedarfs nicht unterstützt.
Der Aufruf von Webservices via SOAP wird durch eine Teilmenge der Java APIs for XML based Remote
Procedure Calls (JAX-RPC) [JAXa] realisiert. Sun liefert im Wireless Toolkit ab Version 2.1 auch einen
Stub-Generator für das WS-API mit.
Die endgültige Spezifikation des WS-API datiert auf den März 2004. Geräte, auf denen dieses optionale Paket implementieren wird, sind zur Zeit noch recht selten. Aufgrund des relativ grossen
Umfangs des Paketes zeichnet sich ab, dass es zunächst eher auf leistungsfähigeren Geräten wie
Smartphones und PDAs Verwendung findet.
Die zur Nutzung von Webservices nötige Funktionalität kann allerdings auch über Bibliotheken anderer Anbieter in eine Anwendung integriert werden, da hierzu keine nativen Komponenten der
Geräte angesprochen werden müssen. Im Open Source Bereich finden sich dazu eine Reihe von Projekten, die sich vor allem im Umfang der unterstützten Funktionalität und damit auch im Speicherbedarf der Bibliothek unterscheiden. Am ausgereiftesten scheinen zur Zeit zwei Projekte: kXML/kSOAP
[kOb] bietet eine umfangreiche Unterstützung von XML-Technologien für die CLDC, während sich
das unter dem Dach der Apache Foundation entwickelte Mirae [Mir] auf eine offene Implementierung des WS-APIs beschränkt. Mirae bietet im Gegensatz zu kSOAP auch einen Stub-Generator.
Aufgrund der momentan noch geringen Verbreitung des optionalen WS-Paketes ist bei Anwendungen, die auf möglichst vielen Geräten lauffähig sein sollen, die Integration einer dieser Bibliotheken
vorzuziehen.
3.2.3 Einsatz von Webservices in mobilen Anwendungen
Webservices ermöglichen eine komfortable Integration mobiler Anwendungen in bestehende Systeme unabhängig von deren Plattform oder Programmiersprache. Die Werkzeuge zur automatischen
Codegenerierung der Webservice-Frameworks können dem Entwickler die Arbeit stark erleichtern eigene Protokolle und Kodierungen zur Datenübertragung erübrigen sich in vielen Fällen.
Demgegenüber steht vor allem ein nicht unerheblicher Overhead der textbasierten Protokolle. Dies
ist gerade bei Anwendungen auf mobilen Geräten aufgrund der geringeren Rechenleistung und
Bandbreite der Netzverbindung problematisch. Um dem entgegenzuwirken, werden für mobile
Systeme auch modifizierte Verfahren entwickelt. So verwendet beispielsweise das JXME-Projekt
[JXM], eine Portierung des plattformunabhängigen Peer-to-Peer Netzwerks JXTA“ [JXT] auf mobile
”
Geräte, ein eigenes binäres XML-Format. Dies führt zu einem erheblich geringeren Ressourcenbedarf
- unabdingbar angesichts des regen Nachrichtenaustausches zwischen den Teilnehmern eines solchen Netzes [RS03]. Ein weiteres binäres XML-Format speziell für den Einsatz in Mobilfunknetzen
ist WAP Binary XML [WBX].
Weitere Probleme ergeben sich trotz aller theoretischen Interoperabilität auch aus vielen kleinen
Inkompatibilitäten zwischen den diversen Frameworks unterschiedlicher Anbieter. Die im Rahmen
der CDC mögliche, direktere Anbindung einer mobilen Anwendung an Java-Systeme mittels RMI
funktioniert wesentlich reibungsloser und effizienter, ist aber nicht so universell einsetzbar wie die
Webservices.
3.3 S YNC ML
21
3.3 SyncML
SyncML ist ein plattformunabhängiger, offener Standard zur Datensynchronisation. Die Entwicklung läuft seit Anfang 2000 und wird unter dem Dach der Open Mobile Alliance [OMA] koordiniert.
Beteiligt sind zahlreiche Unternehmen der Mobilfunk- und IT-Branche, unter anderem Sony Ericsson, IBM, Palm, Motorola, Symbian, Nokia und Siemens. Ziel dieser Kooperation ist es, die bestehenden, untereinander inkompatiblen Lösungen zur Datensynchronisation durch einen einheitlichen
Standard zu ersetzen. Neben der Datensynchronisation soll SyncML auch zur Administration mobiler Geräte und Anwendungen (dem sogenannten Over-The-Air Provisioning) verwendet werden. Eine
separate Expertengruppe widmet sich diesem Anwendungsfeld.
Mittels SyncML können Daten unterschiedlicher Anwendungen auf verschiedenen Geräten ausgetauscht und im Gesamtkontext konsistent gehalten werden. Dies ermöglicht eine Integration mobiler
Anwendungen in bestehende Informationssysteme. Grundsätzlich eignet sich SyncML für die Synchronisation verschiedenster Daten. Zur Zeit verfügbare SyncML-Anwendungen dienen meist dem
Abgleich persönlicher Daten, wie Adressbücher, Terminkalender, Aufgabenlisten oder Emails. Die
Kommunikation erfolgt mittels XML-basierter Nachrichten und kann über unterschiedliche Verbindungen durchgeführt werden. Neben der gängigen Kommunikation via HTTP sind weitere Verbindungsarten, beispielsweise über serielle Kabel, Bluetooth, oder das Wireless Session Protocol, spezifiziert. Dabei wurden die Restriktionen mobiler Verbindungen, insbesondere die geringe Bandbreite
und die Unzuverlässigkeit der Kommunikation berücksichtigt, z.B. durch die optionale Verwendung
eines binären XML-Formats.
3.3.1 Systemarchitekturen
SyncML-Lösungen basieren in der Regel auf einer Client/Server-Architektur: Auf dem Server werden die relevanten Daten zentral verwaltet, die Clients verfügen über lokale Kopien dieser Daten.
Auf den Clients vorgenommene Änderungen werden in unregelmäßigen Abständen an den Server
übermittelt und in die zentrale Datenbasis aufgenommen. Wenn zwei Clients an denselben Daten
Änderungen vornehmen kommt es beim Übernehmen dieser Änderungen auf dem Server zu Konflikten. Der Server hat dafür Sorge zu tragen, das diese Konflikte erkannt und adäquat gelöst werden;
die Clients brauchen sich nicht darum zu kümmern.
Ein System mit einer solchen zentralen Verwaltung der Daten erlaubt keinen direkten Datenaustausch zwischen den Clients. Alternativ wären auch Peer-to-Peer-Systeme unter Verwendung von
SyncML realisierbar. Die Clients müssen dabei die Verbreitung von Änderungen der gemeinsam
genutzten Datenbasis an alle Teilnehmer des Systems sicherstellen und dabei auftretende Konflikte
eigenständig lösen. Dies stellt erhöhte Anforderungen an die Anwendung, die besonders im mobilen
Kontext ins Gewicht fallen. Wegen der ungleich höheren Komplexität werden Peer-to-Peer-Systeme
im Rahmen der Datensynchronisation zur Zeit noch recht selten genutzt. SyncML wurde daher auf
die Verwendung in Client/Server-Architekturen optimiert.
3.3 S YNC ML
22
3.3.2 Protokolle und Verfahren
Die elementaren Bestandteile des SyncML-Standards sind das Representation Protocol und das Synchronisation Protocol. Die Art der Identifikation der einzelnen Daten und der darauf auszuführenden
Operationen sind im Representation Protocol spezifiziert. Zur Identifikation erhält jeder Datensatz
des Systems eine eindeutige Nummer, den Unique Identifier (UID). Operationen sind beispielsweise das Hinzufügen, Löschen oder Modifizieren von Daten. Um komplexere Transaktionen zu erlauben, kann eine Gruppe von Anweisungen auch mithilfe der Atomic-Kommandos zusammengefasst
werden.
Das Synchronisation Protocol spezifiziert den Ablauf der Kommunikation zwischen Client und Server und die Struktur der dabei ausgetauschten Nachrichten. In der Regel beginnt der Client den
Synchronisationsprozess, die Initiative kann aber auch vom Server ausgehen (Siehe Kapitel 3.4 zu
Push-Diensten im Rahmen der J2ME). Zunächst werden sogenannte Initialization Messages ausgetauscht. Diese Phase kann eine Authentifizierung beinhalten. Zudem können Informationen über
das verwendete Datenformat oder zu berücksichtigende Limitationen des Clients (z.B. die maximale Größe der Datenpakete aufgrund einer geringen Kapazität des Nachrichtenpuffers) übermittelt
werden.
Im Zuge der Initialisierung wird auch der Typ der durchzuführenden Synchronisation ermittelt. Dazu sendet der Client den genauen Zeitpunkt der letzten Synchronisation mit dem Server. Anhand
dieser Information kann festgestellt werden, welche Daten seit diesem Zeitpunkt hinzugefügt, modifiziert oder gelöscht wurden. Diese Daten werden im Folgenden ausgetauscht: Bidirektional, wenn
beide Seiten geänderte Daten übermitteln müssen (Two-way Sync) oder unidirektional, wenn nur auf
client- bzw. serverseite Modifikationen zu verzeichnen sind. Eine Besonderheit stellt der sogenannte
Slow Sync dar, bei dem sämtliche Daten ausgetauscht werden müssen. Dies ist bei der ersten Synchronisation zwischen Client und Server nötig und kann darüber hinaus beim Auftreten von Problemen
erforderlich werden.
Im Anschluss an die Initialisation kann der eigentliche Datenaustausch erfolgen. Dabei werden die
mit auszuführenden Operationen und UID versehenen Datensätze übermittelt. Das Format der Daten ist prinzipiell beliebig. Für den Austausch von Adressen und Terminen sind vCard sowie vCalendar gängige Formate [vCa].
In der letzte Phase der Synchronisation sendet der Client Informationen über erfolgreich
übernommene Änderungen, sowie die UIDs neu hinzugefügter Datensätze an den Server. Dieses Data Mapping ist nötig, da die Clients im Allgemeinen kürzere UIDs zur Identifizierung der
Datensätze verwenden, als der Server. Dieser speichert sogenannte globale UIDs, mit denen eine
größere Menge an Datensätzen verwaltet werden kann. Der Server kann anhand der Informationen
der Mapping-Nachricht die lokalen UIDs der Clients den korrespondierenden globalen zuordnen.
Diese Abbildungen werden für jeden Client auf dem Server gespeichert – zukünftige Änderungen an
den Daten der Clients können so vom Server mit deren lokalen UIDs versehen übermittelt werden.
Dieses Vorgehen wurde aufgrund der Limitationen der mobilen Clients gewählt, denn so brauchen
sie keine Umsetzung der UIDs durchführen.
3.4 P USH D IENSTE
23
3.3.3 Verwendung von SyncML auf Basis der J2ME
Ein optionales Paket zur Integration der Datensynchronisation mittels SyncML in die J2ME ist geplant (JSR-230); die Arbeiten befinden sich allerdings noch in einem recht frühen Stadium. Eine Alternative bietet das Sync4j-Framework [Syn]. Dieses beinhaltet neben einem in Java implementiertem
SyncML-Server auch einen rudimentären Client für die J2ME. Dieser kann als Basis für eine Integration des SyncML-Protokolls in mobile Anwendungen dienen.
Einen Zugriff auf die internen Adress- und Termindatenbanken mobiler Geräte ermöglicht das in
JSR-75 spezifizierte PIM-API, dessen Funktionalität im Rahmen der praktischen Evaluation näher
erläutert wird.
3.4 Push Dienste
Mit der Push Registry erweitert das MIDP 2.0 mobile Anwendungen um die Fähigkeit, in Reaktion
auf asynchrone Ereignisse selbständig zu starten. Die Push Registry ist Bestandteil der Application
Management Software, welche die Installation und Verwaltung der J2ME-Anwendungen steuert. Es
gibt zwei Arten der Registrierung: Eine dynamische zur Laufzeit und eine statische, über spezielle
Attribute im Applikationsdeskriptor, bei der Installation.
Auslösende Ereignisse für die Aktivierung einer Anwendung können entweder zeitgesteuerte Alarme oder eingehende Netzverbindungen sein. Die zeitgesteuerte Aktivierung lässt sich für Terminplaner oder periodisch auszuführende Routinetätigkeiten nutzen. Mithilfe der Aktivierung über das
Netzwerk kann ein externes Informationssystem die mobile Anwendung direkt über Änderungen
wichtiger Daten informieren oder auch eine Standortlokalisierung des Gerätes einleiten.
Ein netzwerkaktivierendes Ereignis wird durch eine URL beschrieben, die einen Serverdienst auf
dem lokalen Endgerät definiert (Syntax analog zum GCF). Zur Differenzierung verschiedener Dienste bzw. Anwendungen dient die Portnummer. Die Push Registry nimmt ankommende Daten stellvertretend entgegen, beispielsweise den Aufbau einer TCP-Verbindung oder die Pufferung einer eingehenden Kurzmitteilung. Im Zuge der Aktivierung werden diese Daten an die Anwendung weitergegeben, die zu deren Verarbeitung einen entsprechenden Serverdienst starten muss.
Die Behandlung von eingehenden Verbindungen auf mobilen Geräten wird durch die Push Registry
sehr vereinfacht, ein Problem besteht jedoch auf der Gegenseite: Um eine mobile Anwendung per
TCP oder UDP von außen ansprechen zu können, muss die IP-Adresse des Gerätes bekannt sein
– die meisten Mobilfunkbetreiber verwenden aber eine dynamische Adressvergabe. Die Abbildung
unveränderlicher Merkmale, wie Telefonnummer oder Subscriber Identity (Kennung der SIM-Karte)
auf die IP-Adresse ist nur in der Domäne des Mobilfunkbetreibers möglich, da hierfür der Zugriff
auf die Infrastruktur des Netzes nötig ist.
Auch die Möglichkeit, Kurzmitteilungen zur Aktivierung zu verwenden, ist nicht ohne Schwierigkeiten durchführbar. Hier kann zwar anhand der Telefonnummer ein Gerät direkt adressiert werden,
doch viele SMS-Gateways unterstützen keine Binärnachrichten mit Portangabe.
3.5 L OKALE V ERBINDUNGEN VIA B LUETOOTH
24
3.5 Lokale Verbindungen via Bluetooth
Bluetooth ist eine Technologie zur drahtlosen Kommunikation mit einer Reichweite von bis zu 100
Metern und einer vergleichsweise geringen Bandbreite von maximal 2,2 Megabit pro Sekunde. Die
Entwicklung wurde von der Firma Ericsson begonnen. Seit 1999 werden die Spezifikationen unter
Beteiligung diverser Hersteller der Computer- und Mobilfunkbranche innerhalb der Bluetooth Special Interest Group [SIG] entwickelt. Ziel ist die Schaffung eines allgemeinen Standards für die drahtlose
Verbindung von Geräten über kurze Distanzen. Heute finden sich Bluetooth-Module in DesktopComputern, PDAs, Mobiltelefonen, Multimediasystemen im Auto und in Peripheriegeräten wie
Druckern, Modems, Tastaturen oder Telefon-Headsets. Die Bluetooth-Module zeichnen sich durch
einen geringen Stromverbrauch aus, der durch eine Begrenzung der Reichweite auf 10 Meter noch
weiter reduziert werden kann. Damit eignet sich Bluetooth sehr gut für die Verwendung in mobilen
Geräten.
Den Nutzern soll die Verwendung einer Bluetooth-Verbindung möglichst einfach gemacht werden. Zu diesem Zweck werden für einzelne Einsatzbereiche sogenannte Profile spezifiziert, welche die Kopplung von Geräten vereinfachen sollen. Beispielsweise das Basic Printing Profile für eine Übermittlung von Druckeraufträgen, das Dial-up Networking Profile für InternetEinwahlverbindungen, das Headset-Profile für Sprachübertragung, oder das Serial Port Profile für
eine serielle Datenübertragung. Die Profile können zur Datenübertragung auf verschiedene Protokolle zurückgreifen. Die für die Entwicklung mobiler Anwendungen relevanten höheren Protokolle
der Transport- und Anwendungsebene werden im Folgenden kurz erläutert; auf die physische Datenübertragung (Baseband- bzw. Radio-Layer) wird dabei nicht näher eingegangen.
Dem Aufbau einer Verbindung dient das Service Discovery Protocol (SDP), welches die Suche nach
Geräten und Diensten ermöglicht. Als Basisprotokoll dient das Logical Link Control and Adaptation
Protocol (L2CAP). Mittels L2CAP können Daten über eine paketorientierte Verbindung übertragen
werden. Das RFComm-Protokoll (Radio Frequency Communication nutzt das L2CAP und bietet darauf
aufbauend stromorientierte Verbindungen.
Auf der Ebene der Anwendungschicht befindet sich das sitzungsorientierte Object Exchange Protocol
(OBEX). Es bietet eine mit HTTP vergleichbare Funktionalität. OBEX erhält eine besondere Bedeutung im Kontext der Datensynchronisation, da eine Reihe weiterer Protokolle der Anwendungsschicht unter Verwendung von OBEX spezifiziert wurden, unter anderem auch SyncML.
Um Anwendungen auf Basis der J2ME die Nutzung von Bluetooth-Verbindungen zu ermöglichen
wurde für diesen Zweck ein optionales Paket spezifiziert (JSR-82). Auf einem Großteil der mobilen
Geräte mit integriertem Bluetooth-Modul ist diese Schnittstelle implementiert. Damit eröffnet sich
eine zusätzliche Möglichkeit der Kommunikation bei der Entwicklung mobiler Anwendungen auf
Basis der J2ME.
Von den oben erwähnten Protokollen stellt das Bluetooth-API SDP, L2CAP und RFComm zur
Verfügung. Eine Unterstützung des OBEX-Protokolls wurde dagegen nur als optional spezifiziert.
Kapitel 4
Praktische Evaluation
Die Möglichkeiten der Datenübertragung und -synchronisation im Rahmen der J2ME-Plattform sollen anhand von Beispielanwendungen und Prototypen evaluiert werden. Dabei sollen die im vorigen
Kapitel vorgestellten Technologien eingesetzt und auftretende Probleme dokumentiert werden.
Der Fokus der Evaluation liegt dabei auf der Connected, Limited Device Configuration in Verbindung mit dem Mobile Information Device Profile. Dieser Schwerpunkt wurde gewählt, da in einem
überwiegenden Teil der heute verfügbaren mobilen Geräte dieses Profil Verwendung findet. Die
Verbreitung der Connected Device Configuration ist dagegen momentan recht gering, auch auf den
leistungsfähigeren PDAs und Smartphones.
Die CLDC wird in der Regel von den Herstellern auf ihre jeweiligen Geräte portiert, und vor der
Auslieferung fest in deren Firmware integriert. Im Gegensatz dazu werden virtuelle Maschinen für
die CDC durchgängig von Drittanbietern für verschiedene Betriebsysteme mobiler Geräte entwickelt. Von Sun wird zwar eine Referenzimplementation der CDC bereitgestellt, allerdings nur für
Linux/x86-Systeme. Sie ist nicht für den Endnutzer gedacht, sondern soll als Basis für Portierungen
der CDC auf die verschiedenen Plattformen der Geräte dienen. Einzig für den Zaurus, einem Linuxbasierten PDA von Sharp, ist von Sun eine CDC-Implementation erhältlich [SUNb].
Auf der weit verbreiteten Pocket PC-Plattform existieren einige virtuelle Maschinen für Java von Drittanbietern [Ber]. Für Endnutzer verfügbar sind jedoch nur Implementationen von PersonalJava, einer
auf Java Version 1.1.8 basierenden Plattform, die seit Ende 1999 nicht mehr weiterentwickelt wird.
Vollständige Implementationen der CDC für PocketPCs bieten die JBed-VM der Firma Esmertec [Jbe]
und die J9-JVM von IBM [J9]. Diese müssen jedoch von den Geräteherstellern lizensiert werden. Wegen der zusätzlichen Kosten finden sie sich nur in einigen Geräten der gehobenen Preisklasse.
Die J9-VM steht auch für einige Geräte mit PalmOS-Betriebssystem zur Verfügung, allerdings nur
eine CLDC-Implementation. Verbreiteter ist auch auf dem Palm noch das ältere PersonalJava. Geräte
mit SymbianOS [Sym] bieten zwar durchgängig die CLDC-Konfiguration, die CDC wird bisher jedoch nicht unterstützt.
Es erscheint somit wünschenswert, mobile Anwendungen auf Basis der CLDC zu entwickeln, um
den Einsatz auf möglichst vielen mobilen Geräten zu erreichen. Im Gegensatz zur CDC Plattform,
die sich im Wesentlichen nur in den Möglichkeiten der graphischen Oberfläche von der Java Standard
4.1 A NFORDERUNGEN
26
Edition unterscheidet, sind die Limitationen der CLDC jedoch erheblich umfangreicher und betreffen
auch in viel stärkerem Maße die Datensynchronisation.
Die Evaluation soll klären, welche Verfahren zur Synchronisation mobiler Anwendungen auf Basis
der CLDC sinnvoll zu verwenden sind, beziehungsweise die Grenzen des Einsatzes der CLDC aufzeigen. Im Folgenden werden die Anforderungen an die Evaluation, der Entwurf der Anwendungen
sowie deren Implementierung dargestellt. Eine abschließende eine Zusammenfassung der dabei gesammelten Ergebnisse folgt im nächsten Kapitel.
4.1 Anforderungen
Die Anforderungen an die zu entwickelnden Anwendungen gründen sich primär auf die Technologien, die dabei untersucht werden sollen. Vorzugsweise soll auf die Verwendung optionaler Pakete verzichtet werden, um die Anwendungen auf möglichst vielen mobilen Geräten einsetzen zu können.
Dem Einstieg in die Entwicklung mit der J2ME dient dabei eine Anwendung zur Darstellung von
Speiseplänen der Mensa des Studentenwerks der Universität Oldenburg auf mobilen Endgeräten
wie Mobiltelefonen oder Organizern. Dabei sollen zunächst grundlegende Erfahrungen mit den
Fähigkeiten des MIDPs im Bezug auf die graphische Oberfläche, die persistente Datenhaltung und
den Datentransfer über Mobilfunknetze gemacht werden. Die Datenübertragung per HTTP wird
mithilfe des Generic Connection Frameworks der J2ME realisiert. Die Daten werden vorher aus Effizienzgründen von einer Serveranwendung aufbereitet und in einer eigenen Kodierung übertragen.
Anschließend soll die Anwendung durch eine Komponente zum lokalen Datenaustausch zwischen
zwei Geräten via Bluetooth erweitert werden.
Darauf aufbauend sollen fortgeschrittenere Möglichkeiten des Datenaustausches erprobt werden:
Zunächst soll mittels einer modifizierten Version der Mensaplan-Anwendung die Kodierung der
Daten in XML und die Übertragung über das Simple Object Access Protocol realisiert werden. Abschließend soll anhand eines Prototypen der Zugriff auf die internen Datenbanken zur Verwaltung
von Adressen und Terminen der mobilen Geräte und die Synchronisation der Daten mit einem entsprechenden Server mittels Synchronization Markup Language realisiert werden. Bei der Kommunikation mittels SOAP und SyncML soll auch untersucht werden, inwiefern sich diese Technologien auch
über Bluetooth-Verbindungen nutzen lassen.
4.1.1 Anwendung für Mensapläne
Das Studentenwerk Oldenburg stellt die jeweils aktuellen Mensapläne auf ihren Webseiten zur
Verfügung, ein Abruf dieser Daten von mobilen Geräten gestaltet sich jedoch problematisch: Das
Layout dieser Seiten ist für mobile Geräte nicht optimal gestaltet. Gerade bei relativ kleinen Displays, wie sie bei Mobiltelephonen die Regel sind, lassen sich die Informationen kaum sinnvoll ablesen. Darüber hinaus erhöht die Darstellung in HTML das benötigte Übertragungsvolumen nicht
unwesentlich – das Verhältnis der eigentlichen Nutzdaten zu den gesamten HTML-Seiten beträgt
insgesamt ungefähr 5 Kilobyte, gegenüber mehr als 200 KiB.
Die Mensaplan-Anwendung soll ihre Daten von einem hierfür zu implementierenden Proxy-Server
4.1 A NFORDERUNGEN
27
beziehen, der die relevanten Daten aus den Webseiten des Studentenwerks extrahiert und für mobile Geräte aufbereitet. Dadurch kann das Volumen der zu übertragenden Daten verringert und das
aufwendige Parsen der HTML-Seiten auf den Server ausgelagert werden. Die Darstellung auf dem
Endgerät erfordert eine eigene graphische Oberfläche.
Im Vergleich zu standardisierten Verfahren, Internetseiten für die Darstellung auf mobilen Endgeräten zu optimieren [WAP], ermöglicht diese Vorgehensweise die Datenspeicherung und eine Personalisierung der Darstellung direkt auf dem Gerät. Darüber hinaus kann ein direkter Datenaustausch zwischen mobilen Geräten via Bluetooth realisiert werden. Analog kann eine direkte Kommunikation über Bluetooth auch mit einem Desktop-Computer stattfinden. Diese Möglichkeit soll
mittels einer kleinen Anwendung genutzt werden, welche die Mensapläne aus dem Internet abruft
und via Bluetooth an die Mensaplan-Anwendung überträgt. Dadurch kann der Abruf der Daten
über das kostenpflichtige Mobilfunknetz gespart werden. Es wäre auch denkbar, auf diese Weise
einen kleinen Server zu realisieren, über den sich beispielsweise am Aufgang zur Mensa die neue
Pläne via Bluetooth übertragen ließen.
4.1.2 Nutzung von Webservices
Zunächst soll grundsätzlich untersucht werden, inwiefern sich vorhandene Webservices aus dem
Internet in Anwendungen auf Basis der J2ME aufrufen lassen. Dazu wird jeweils ein kleiner Prototyp benötigt, der einen Webservice aufruft, und die empfangenen Daten auf dem Display ausgibt.
Anschließend soll die Datenübertragung der Mensaplan-Anwendung per Webservice realisiert werden. Dazu müssen sowohl Server als auch mobile Anwendung entsprechend modifiziert werden.
Über die Bluetooth Verbindung sollen ebenfalls XML-kodierte Daten übertragen werden. Hierzu
soll das Object Exchange Protocol Verwendung finden, da bei aufwendigeren Protokollen (beispielsweise SyncML) zumeist OBEX als Transportprotokoll über Bluetooth vorgesehen ist, und so erste
Erfahrungen hiermit gesammelt werden können.
4.1.3 Prototyp zur Datensynchronisation über SyncML
Die Kommunikation unter Nutzung der Synchronization Markup Language soll anhand eines weiteren Prototypen betrachtet werden. Dieser soll auf die internen Datenbanken zur Verwaltung von
Adressen des mobilen Gerätes zugreifen, diese Daten innerhalb der Anwendung modifizieren und
schließlich mit einem Server mittels SyncML synchronisieren können. Aufbauend auf einem solchen Prototyp könnten personalisierbare Anwendungen entwickelt werden, die es dem Benutzer
ermöglichen, für spezielle Anwendungen eine partielle Sicht auf die vorhandenen Daten zu bekommen und diese Teile mit anderen Benutzern oder Anwendungen abzugleichen.
Eine Beispielanwendung im Bereich der Adressenverwaltung wäre der Austausch von Adressen unter den Studenten eines Seminares oder einer Projektgruppe. In diesem Kontext wäre es
wünschenswert, persönliche Daten nur teilweise zur Verfügung stellen zu können, beispielsweise
nur den Namen und die Email-Adresse. Darüber hinaus sollten diese Adressen noch einer eigenen
Kategorie ( Seminar XY“) zugeordnet werden können. Der Austausch bzw. die Aktualisierung der
”
4.2 E NTWURF
28
Daten könnten dann über einen zentralen Server oder direkt zwischen den mobilen Geräten der Teilnehmer erfolgen.
Anhand des Prototypen soll erprobt werden, inwieweit sich solche Anwendungen auf Basis der
J2ME realisieren lassen. Zunächst wird die Synchronisation der Daten mittels eines zentralen Servers
untersucht. Anschließend soll geprüft werden, ob ein Datenabgleich auch lokal mit einem weiteren
mobilen Gerät oder einer Desktop-Anwendung über die Bluetooth-Schnittstelle realisiert werden
kann.
4.2 Entwurf
In der Entwurfsphase wurde zunächst die Systemarchitektur gewählt und eine grobe Struktur der zu
implementierenden Programme entworfen. Zudem wurden geeignete Bibliotheken zur Realisierung
der geplanten Funktionen gesichtet und ausgewählt.
4.2.1 Architektur System
Für die Mensaplan-Anwendung wird eine Client/Server-Architektur realisiert, mit optionalem, direktem Datenaustausch der Clients untereinander. Der Server dient dabei als Proxy, der die Daten
der Mensapläne aus den Internetseiten des Studentenwerks extrahiert und für die mobile Anwendung aufbereitet zur Verfügung stellt. Der Einfachheit halber wird bei der Desktop-Anwendung auf
die Integration eines Parsers verzichtet. Die Desktop-Anwendung fungiert als Relay, das die Mensadaten über das Internet vom Server bezieht, und dann lokal per Bluetooth an den Client überträgt.
Für den SyncML Prototypen wird ein entsprechender SyncML-Server genutzt. Dieser kann die Daten auch mit weiteren Servern oder Desktop Anwendungen synchronisieren, primär ist allerdings
die Kommunikation zwischen mobiler Anwendung und SyncML-Server von Interesse.
4.2.2 Komponenten Server
Der Server ist ebenfalls in Java geschrieben und nutzt Apache Tomcat [Tom] als Servlet-Container.
Ein Servlet stellt für die Mensaplan-Anwendung aufbereitete Daten der Mensapläne der Universität
Oldenburg zur Verfügung. Zum Parsen der HTML-Seiten des Studentenwerks werden der HTMLScanner/Tag-Balancer NekoHTML [Nek] und der XML-Parser Xerces [Xer] verwendet. Die Daten
werden zunächst sehr einfach kodiert und als Text im UTF-8 Format (ermöglicht die Verwendung
von Sonderzeichen) per HTTP verschickt. Anschließend wird der Server modifiziert: Als Framework
für Webservices wird Apache Axis [Axi] genutzt, für die Daten eine entsprechende XML-Kodierung
gewählt.
Als Server zur Datensynchronisation mittels SyncML wird zunächst der Sync4j-Server [Syn] genutzt, da der Client ebenfalls der Sync4j-Plattform entstammt. Darüber hinaus wird die Kompatiblität der Kommunikation über SyncML mit einem weiteren SyncML-fähigen Server getestet. Hierfür
erscheint unter Linux Multisync [mul] am geeignetsten. Diese Anwendung wurde zunächst zur Syn-
4.2 E NTWURF
29
Abbildung 4.1: Architektur Mensaplan
chronisation von Geräten der Palm-Plattform mit Desktop-Anwendungen entwickelt und mittlerweile um eine eigenständige SyncML-Komponente erweitert.
4.2.3 Struktur der Mensaplan-Anwendung
Der Programmcode der Mensaplan-Anwendung wird in drei Pakete unterteilt: Das Paket
mensaplan.connection beinhaltet die Klassen für die HTTP- und Bluetooth-Verbindungen,
im Paket mensaplan.data finden sich die Datenhaltungsklassen und im Paket mensaplan.ui
befinden sich die Klassen der graphischen Oberfläche mit den dazugehörigen Command-Listenern.
Abbildung 4.2 gibt einen Überblick über die Klassen und Pakete, die blau eingezeichneten Klassen gehören zur ersten Version mit einfacher Datenübertragung über HTTP, die roten Klassen
realisieren stattdessen die Datenübertragung via Webservice. Die modifizierte Anwendung zur
Nutzung von Webservices benötigt zwei zusätzliche Bibliotheken. Da die im JSR-172 standardisierte Webservice-API bisher kaum verbreitet ist, findet hierzu die Open Source Implementation
Mirae [Mir] Verwendung, die mit in das Midlet integriert wird. Die Entscheidung für Mirae wurde aufgrund des ausgereiften Eindrucks und des mitgelieferten Stub-Generators getroffen, der bei
alternativen Webservice-Bibliotheken für die J2ME (beispielsweise kSOAP [kOb]) leider fehlt. Die
WS-API wird während der Implementierungsphase ebenfalls einer näheren Betrachtung unterzogen, da diese in Zukunft bei stärkerer Verbreitung den Einsatz einer separaten Bibliothek für die
Nutzung von Webservices überflüssig machen könnte.
Die zweite Bibliothek, die dem Midlet hinzugefügt wird, ist AvetanaOBEX [aveb], welche die
Fähigkeiten JSR-82 kompatibler J2ME-Geräte um eine Unterstützung für das OBEX-Protokoll erwei-
MainUI
Abbildung 4.2: Klassendiagramm Midlet
BLUElet
public void commandAction()
<<ThisWeek>>
Week
Model
<<NextWeek>>
<<Tue>>
<<Wed>>
Day
<<Thu>>
<<Fri>>
Dates
<<Data>>
ProcessInput
MensaDataStub
public Week getNextWeek()
public Week getThisWeek()
public Dates getCurrentDate()
public void run()
public BluetoothClient(Model data)
BluetoothClient
public void run()
public BluetoothServer(Model data)
BluetoothServer
MensaDataIF
<<Interface>>
public Week getNextWeek()
public Week getThisWeek()
public Dates getCurrentDate()
public MensaDataStub(String enduri)
private String enduri;
static public boolean parse(byte[] input, int length, Model data)
public void run()
public IPConnection(Model data)
IPConnection
public void setServiceRecord()
<<Data>>
<<Data>>
<<Data>>
public void run()
public WSConnection(Model data)
WSConnection
mensaplan.connection
public void serviceSearchCompleted(int transId, int complete)
public void serialize(StringBuffer buffer)
public void decode(String uri, String localName, String qName, Attributes attributes, String value)
public Dates(long thisWeek, long nextWeek)
private long nextWeek;
private long thisWeek;
public Day(String ausw, String wloy, String alt, String menu)
private String wloy;
private String ausw;
private String alt;
private String menu;
<<Mon>>
public void setBytes(byte[] recordStoreData)
public byte[] getBytes()
public Week(long date, Day mon, Day tue, Day wed, Day thu, Day fri)
private long date;
private void checkDates()
public Model(String url)
private String url = "http://server.url";
static public void save(Model data)
static public void load(Model data)
DataStore
mensaplan.data
protected void destroyApp(boolean arg0)
protected void pauseApp()
protected void startApp()
public Mensaplan()
Mensaplan
public void servicesDiscovered(int transId, ServiceRecord[] records)
public void inquiryCompleted(int complete)
public void deviceDiscovered()
Listener
public void startInquiry(int mode, UUID[] serviceUUIDs)
public getSelectedDevice()
public getFirstDiscoveredService()
public ServiceRecord[] getDiscoveredServices()
public BLUElet()
BlueToothUI
<<Day>>
<<Data>>
<<Data>>
<<Week>>
public BlueToothUI(Model data)
public static int selectedDevice = -1;
public RemoteDeviceUI()
RemoteDeviceUI
static public String toString(Long date)
Date2String
public DayUI(Day day, String title)
DayUI
public WeekUI(Week week, String title)
private String weekTitle;
WeekUI
public MainUI(Model data, boolean btSupport)
private boolean btSupport;
mensaplan.ui
4.2 E NTWURF
30
4.2 E NTWURF
31
tert. Die erste Version der Datenübertragung per Bluetooth nutzt das einfachere RFComm-Protokoll.
Die Übertragung von XML-Objekten und insbesondere SyncML sind jedoch mit OBEX als zugrundeliegendem Transportprotokoll spezifiziert.
4.2.4 Desktop-Relay
Diese Anwendung für Desktop PCs bietet die Möglichkeit, die Daten für die Mensaplan-Anwendung
via Bluetooth auf das mobile Gerät zu übertragen. Dazu werden die Daten über das Internet vom
MensaServlet bezogen und dann ein BT-Serverdienst eröffnet. Auf diese Weise könnte auch ein
lokaler Servicepoint realisiert werden, an dem mobile Geräte über eine Bluetooth Verbindung mit
aktuellen Daten versorgt werden.
Um diesen Dienst auf Desktop-Systemen zu ermöglichen wird die Bibliothek AvetanaBluetooth [avea] genutzt. Diese implementiert die JSR-82 Pakete javax.bluetooth und
javax.microedition.io für die J2SE. Dadurch kann der Code der mobilen Anwendung nahezu unverändert übernommen werden. Die Bibliothek ist plattformübergreifend für Linux, MacOS X und Windows verfügbar, die nativen Komponenten sind Teil des avetanaBluetooth-Archivs
[GCH04].
4.2.5 SyncML-Prototyp
Der Prototyp wird auf Basis des Sync4j-Frameworks [Syn] realisiert. Dieses beinhaltet einen auf Java basierenden SyncML-Server und Unterstützung für diverse Clienten und Datenformate. Darunter findet sich auch eine Beispielanwendung für die J2ME, mittels derer Daten über eine HTTPVerbindung mit dem Server synchronisiert werden können. Diese soll als Basis des SyncMLPrototyps dienen. Die Schnittstellen zu internen Datenbanken der Adressverwaltung des mobilen
Gerätes stellt das optionale Personal Information Management-Paket (JSR-75) zur Verfügung.
Zu Beginn des Entwurfs des Prototypen stand die Entscheidung, auf welche Weise der Zugriff auf
die Adressdatenbanken erfolgen soll. Erste Versuche auf dem zum Testen des PIM-APIs verwendeten Palm Treo ergaben, dass kein Zugriff auf das für eine Datensychronisation immanent wichtige
Revision-Feld möglich ist. In diesem Feld wird das Datum der letzten Änderung der Datenbankeinträge von Adressbuch und Kalender festgehalten, eine direkte Synchronisation kann ohne diese
Information nicht durchgeführt werden. Um Veränderungen der Daten durch die nativen Anwendungen des Gerätes zu erkennen, sind also innerhalb der Java-Anwendung persistent gespeicherte
Prüfsummen von allen Datenbankeinträgen nötig.
Die Sync4j-Beispielanwendung speichert alle notwendigen Daten komplett mithilfe des Record Management Systems (RMS) des MIDPs innerhalb der Anwendung. Um möglichst schnell zu Ergebnissen zu kommen, wurde dieses Vorgehen bei der Entwicklung des Prototypens beibehalten. Statt
Prüfsummen zu verwenden, werden sämtliche relevante Daten mittels RMS innerhalb der Anwendung gespeichert. Dadurch kann die Struktur der Beispielanwendung weitestgehend beibehalten
werden: Die Methoden zum Zugriff auf die internen Datenbanken werden in einer eigenen Klasse
gekapselt und jeweils aufgerufen, bevor ein Zugriff auf die im RMS gespeicherten Daten erfolgt. Abbildung 4.3 zeigt die relevanten Klassen der Anwendung, die modifizierten Methoden sind in blau
4.3 I MPLEMENTIERUNG
32
kennzeichnet. Neu hinzugekommen ist das Paket syncclient.pim, in dem sich neben der angesprochenen PIM-Klasse zwei Klassen zur Realisierung einer beispielhaften graphischen Oberfläche
zur Betrachtung und Modifikation von Adressbucheinträgen des Gerätes finden.
4.3 Implementierung
Im Folgenden werden Besonderheiten beschrieben, die sich bei der Implementierung im Rahmen der
J2ME gezeigt haben, insbesondere die dabei aufgetretenen Probleme. Zunächst wird die verwendete
Entwicklungsumgebung beschrieben, anschließend die Implementierung der einzelnen Anwendungen.
4.3.1 Verwendete Entwicklungsumgebung
Als Entwicklungsumgebung wurde die Ecplise Plattform [Ecla] Version 3.0 unter Linux verwendet.
Die Besonderheiten der Entwicklung mit der J2ME vereinfacht dabei das EclipseME-Plugin [Eclb].
Es bietet die Integration des J2ME Wireless Toolkits (WTK) [SUNc], der Referenzplattform von Sun,
und anderer herstellerspezifischer Entwicklungsumgebungen. Dies ermöglicht einen komfortablen
Wechsel zwischen Bibliotheken und Emulatoren verschiedener Hersteller und erleichtert somit das
Testen auf verschiedenen Plattformen. Das standardisierte Unified Emulator Interface soll diese Flexibilität fördern und eine einheitliche Anbindung an Laufzeitumgebung und Debugger schaffen. Die
Mehrzahl der großen Hersteller hat ihre Entwicklungswerkzeuge mittlerweile dahingehend angepasst. Ein Problem stellt allerdings die Verfügbarkeit der Werkzeuge unter Linux dar. Neben Suns
Referenzplattform läuft nur die Entwicklungsumgebung von Nokia weitgehend problemlos unter
Linux, wobei auch diese beiden Anbieter neue Versionen ihrer Werkzeuge zunächst nur für Windows veröffentlichen. Immerhin unterscheiden sich Linux- und Windows-Versionen nicht hinsichtlich ihrer Funktionalität; beispielsweise finden sich im WTK neben den Bibliotheken und dem Emulator auch Werkzeuge zur Betrachtung von Speicherverbrauch und Netzverbindungen der emulierten Anwendungen oder ein Stub-Generator zur Vereinfachung der Nutzung von Webservices.
Andere zur Entwicklung von J2ME Anwendungen nützliche Werkzeuge stehen dagegen betriebssystemübergreifend zur Verfügung. Der ProGuard Obfuscator [Pro] reduziert den Umfang des Codes
der Anwendung durch die Entfernung nicht benötigter Methoden und Klassen und eine Verkürzung
von Klassen-, Methoden- und Variablennamen auf ein oder zwei Zeichen. Antenna [Ant] bietet J2ME
spezifische Ant-Tasks, beispielsweise preverification, obfuscation oder Signierung. Zur Erstellung von
.jar-Archiven integriert das EclipseME-Plugin auch diese Werkzeuge. Darüberhinaus kann ein dazugehöriger Application Descriptor (die .jad-Datei) generiert und bearbeitet werden.
Die Entwicklung von J2ME Anwendungen ist auf dieser Basis mit frei verfügbaren Programmen
unter Linux komfortabel möglich, einziges Manko bleibt die relativ geringe Auswahl an Emulatoren verschiedener Hersteller. Eine kostenpflichtige alternative Entwicklungsumgebung für die J2ME
unter Linux bietet IBM mit dem WebSphere Studio Device Developer (WSDD). IBM hat das WSDD insbesondere auf die eigene J9-VM abgestimmt, sodass sie sich bei der Entwicklung von Anwendungen
für Geräte mit dieser VM anbietet. So wird beispielsweise ein sehr leistungsfähiger Stub-Generator
private void syncMapping()
private String postRequest(String request)
private void checkStatus(String msg, String statusOf)
public void removeMapping(String UID)
public Hashtable getReverseMapping()
PIMStore
private String sendAlertMessage()
public void addMapping(String UID, String pimUID)
Abbildung 4.3: Klassendiagramm SyncML-Client (nur relevante Klassen)
public void startDSOperations()
public void commitDSOperations()
public Record(String key, char state, String content)
public getters/setters()
public byte[] getBytes()
public Vector getRecords(char state)
public Record(byte[] recordStoreData)
public Vector getNoDeletedRecords()
public void storeRecord(Record record)
private String content;
public void deleteRecord(String key)
public long getLastTimestamp()
public void setLastTimestamp(long lastTimestamp)
public DataStore(String recordStoreName)
DataStore
private retrievePIMContact(String UID)
protected String toSerialFormat(Contact contact)
protected fromSerialFormat(String vCard)
protected Record modifyPIMContact(String UID, Contact modContact)
protected Record addPIMContact(Contact contact2add)
public Hashtable getReverseMapping()
public boolean deletePIMContact(String UID)
public Record modifyPIMContact(Record modifiedRecord)
private String getContent(Record record)
private int getSourceAlertCode(String sourceURI)
private String prepareSyncTag(Vector records, String sourceURI)
private Vector filterRecordsForSlowSync()
private Vector filterRecordsForFastSync()
private String createAlerts(String sourceUri)
private void loadResources()
private void prepareMappingMessage()
private void prepareAlertMessage()
private void prepareModificationMessage()
private boolean processModifications(String modifications)
private void prepareInizializationMessage()
private void checkServerAlerts(String msg)
private String syncModifications()
private String syncInitialization()
public void sync()
public String getPimUID(String UID)
UIDMap
SyncManagerImpl
protected SyncManagerImpl(DataStore dataStore, PIMStore pimStore)
syncclient.spds
public UIDMap()
public Record addPIMContact(Record record2add)
public PIMStore()
public DataList(PIMStore pimStore)
DataList
public Record saveContact()
private char state;
Record
ContactForm
public ContactForm(Record record, PIMStore pimStore)
syncclient.pim
private String key;
syncclient.sps
private void deleteRecord(Record record)
private void synchronize()
private void initializePIMData()
public List displayDB()
public genMainScr()
protected void destroyApp()
protected void pauseApp()
protected void startApp()
public SyncClientMIDlet()
SyncClientMIDlet
syncclient.midlet
33
34
für die Verwendung von Webservices mitgeliefert und Anwendungen können direkt auf einem J9Emulator getestet werden. Ohne das WSDD muss hierzu die J9-VM auf einem Palm-Emulator installiert werden, um dann eine Anwendung auf der emulierten VM zu installieren – die Fehlersuche
wird dadurch sehr erschwert.
Zum Testen der Anwendungen wurden neben den Emulatoren im Wesentlichen drei Geräte verwendet, welche die Palette an unterschiedlichen Plattformen recht gut abdecken: In die Klasse der einfachen Mobiltelefone mit Unterstützung für Java und Bluetooth fällt das Nokia 6230. Das Nokia 7650 ist
dagegen ein Smartphone auf SymbianOS Basis und bietet neben Java und Bluetooth vor allem einen
größeren Bildschirm. Aus der Geräteklasse der PDAs mit J2ME Unterstützung steht ein Palm Treo
650 Smartphone zur Verfügung, welches als einziges dieser Geräte die PIM und Webservices API
implementiert, aber leider keinen Zugriff auf Bluetooth unter Java ermöglicht. Die Kommunikation
über Bluetooth konnte somit nur anhand der beiden Nokia Geräte getestet werden.
4.3.2 Mensaplan Servlet
Der Server nutzt einen XML-Parser, um die Daten der Mensapläne aus den Webseiten des Studentenwerks zu extrahieren. Dieser erzeugt aus einer HTML-Seite eine Baumstruktur, aus der die
relevanten Informationen ausgewählt werden können. Eine graphische Ausgabe dieses DOM-Baums
ermöglicht es, die hierzu nötigen Befehle einfach abzulesen. Der Einsatz eines DOM-Parsers wurde
gewählt, da auf den Webseiten des Studentenwerks keinerlei Trennung zwischen Layout und Inhalt
vorgenommen wurde: Sie bestehen aus tief verschachtelten HTML-Tabellen, in deren Zellen sich die
verschiedenen Gerichte für die einzelnen Wochentage wiederfinden. Zudem kann der DOM-Parser
bei eventuellen Änderungen am Layout der Seiten des Studentenwerks unkompliziert angepasst
werden.
org.w3c.dom.traversal.TreeWalker walker=dom.createTreeWalker(doc,nodeFilter);
for(int i=0;i<9;i++){
walker.firstChild();walker.nextSibling();//TD
walker.firstChild();//FONT
if (walker.firstChild()!=null){
//TEXT:the dish
dataString+=walker.getCurrentNode().getNodeValue();
walker.parentNode();
}
walker.parentNode();walker.nextSibling();walker.nextSibling();//TD
walker.firstChild();//FONT
if (walker.firstChild()!=null){
//TEXT:price
dataString+="\n"+walker.getCurrentNode().getNodeValue()+",-\n";
}
walker.nextNode();walker.nextNode();walker.nextSibling();//next TR with DATA
}
Die Kodierung der Daten ist sehr einfach gewählt, um das zu Datenvolumen möglichst gering zu
halten: Die Daten werden per HTTP als Zeichenkette im UTF-8 Format übertragen, wobei die bei-
35
den Wochen mit einem Pipe-Symbol getrennt werden. Innerhalb der Daten einer Woche wird das
Dollarzeichen zur Trennung verwendet. Als erstes wird der long-Wert des Datums geschrieben (Vergangene Zeit in Millisekunden nach der standard base time 01.01.1970, 00:00:00 GMT). Dieses Datumsformat wurde gewählt, da Java intern ohnehin mit diesem Wert arbeitet. Eine bestimmte Woche wird
von der Server-Anwendung mit diesem Zeitstempel versehen, der Wert ist danach im gesamten System gültig. Dadurch kann es auch bei einem Datenaustausch zwischen zwei mobilen Anwendungen
nicht zu Inkonsistenzen aufgrund geringfügig unterschiedlicher Uhrzeiten auf den Geräten kommen. Im Anschluss an das Datum folgen die Wochentage von Montag bis Freitag. Jeder Tag beinhaltet eine Zeichenkette für Menü, Alternativ, Auswahl und Wechloy in dieser Reihenfolge.
$1122854400000$Shop Suey mit Huhnfleisch, Gemüse und Sojakeimen, Reis
Joghurt mit Aprikosen
$Chinakohlsalat
Vollkornnudeln überbacken, Tomaten-Basilikumsauce
Frisches Obst
$ ...
Ab Freitag 15 Uhr werden die Seiten des Studentenwerks auf aktualisierte Daten überprüft, um diese
dann gegebenenfalls zu übernehmen.
4.3.3 Mensaplan-Anwendung
Eine Anwendung für das MIDP wird grundsätzlich von der abstrakten Klasse
javax.microedition.midlet.MIDlet abgeleitet, die den Lebenszyklus der Anwendung verwaltet. Der Aufbau eines MIDlets ist vergleichbar mit dem eines Applets aus der J2SE. Es gibt definierte Zustände und Methoden, die bei einem Zustandswechsel aufgerufen werden. Nach dem
Initieren eines MIDlets wird die Methode startApp() aufgerufen, in der die Darstellung auf
dem Bildschirm gestartet wird (display.setCurrent(mainMenu)). Eine Unterbrechung der Programmausführung, beispielsweise zur der Annahme eines Telefonanrufs kann über pauseApp()
geregelt werden. Beim Fortsetzen wird wieder startApp() aufgerufen. Der Lebenszyklus eines
MIDlets endet mit dem Aufruf von destroyApp().
Der Konstruktor des Mensaplan-Midlets erzeugt die Objekte zur Datenhaltung, dabei werden gegebenenfalls auf dem Gerät gespeicherte Daten geladen. Wenn das Gerät Bluetooth nach JSR-82
unterstützt, werden die entsprechenden Klassen instanziiert. Anschließend wird das Hauptmenü
erstellt.
4.3.3.1 Datenklassen und persistente Datenhaltung mit dem RMS
Im Paket mensaplan.data finden sich die Datenhaltungsklassen: ein Day-Objekt speichert die Tagesgerichte für Menü, Alternativ, Auswahl und Wechloy jeweils als Zeichenkette. Ein Week-Objekt
beinhaltet neben den fünf Wochentagen das Anfangsdatum der Woche als long-Wert.
Die Haupt-Datenklasse lädt bei der Initialisierung die Daten der betrachteten zwei Wochen aus dem
persistenten Speicher des Geräts und überprüft diese auf Aktualität. Die Klasse DataStore bietet
hierzu Methoden zum Zugriff auf das Record-Management-System (RMS).
36
Das RMS API ist eine einfache satzorientierte Datenbankschnittstelle, über die sich persistente Daten im Gerät verwalten lassen. Ein Record-Store besteht aus einer Anzahl Records mit variabler
Länge, ein Record selbst ist ein einfaches Byte-Array ohne vorgegebene Struktur. Die Daten einer
ganzen Woche werden jeweils in einem Record gespeichert, die Klasse Week stellt dazu die Methoden getBytes() bzw. setBytes(Byte[]rsData) bereit.
Der Zugriff auf einen Record erfolgt anhand einer ID, die beim Erstellen des Records vom RMS
vergeben wird. Wird ein Record gelöscht erlaubt das RMS keine erneute Vergabe derselben ID.
Der gängige Weg zum Wiederauffinden von Records besteht darin, einen speziellen Filter zu erstellen und diesen an das RMS zu übergeben. Zurückgeliefert wird eine RecordEnumeration in der
dann der gewünschte Record gesucht werden muss. Um dies zu vermeiden erstellt die MensaplanAnwendung nur einmal beim Anlegen des Record-Stores neue Records, danach werden diese einfach mit neuen Daten überschrieben. Die Daten der aktuellen Woche finden sich damit immer unter
der RecordID 1, die Daten der nächsten unter der RecordID 2.
//openRecordStore(name,true) erzeugt einen RS,
//wenn noch keiner unter diesem Namen vorhanden ist
if (RecordStore.listRecordStores()==null){
RecordStore store=RecordStore.openRecordStore("Mensa",true);
byte [] tmp;
tmp=data.getThisWeek().getBytes();
store.addRecord(tmp,0,tmp.length);
tmp=data.getNextWeek().getBytes();
store.addRecord(tmp,0,tmp.length);
store.closeRecordStore();
}
//Daten laden:
data.getThisWeek().setBytes(store.getRecord(1));
//Daten speichern:
byte [] tmp=data.getThisWeek().getBytes();|
store.setRecord(1,tmp,0,tmp.length);
Die Daten werden bei Beendigung des MIDlets in der Record-Store geschrieben.
protected void destroyApp(boolean arg0){
DataStore.save(data);
}
4.3.3.2 Graphische Oberfläche
Die Schnittstelle für graphische Oberflächen des MIDP gliedert sich in Low- und High-Level APIs
auf. Das Low-Level API ermöglicht den vollen Zugriff auf den Bildschirm des Gerätes auf Pixelebene. Das High-Level API bietet vordefinierte Dialogelemente, wie Formulare, Listen, Text- und
Grafikboxen, Eingabefelder oder Popupfenster. Das genaue Aussehen dieser Elemente ist dabei von
der Implementierung des jeweiligen Geräts abhängig. Eine gleichzeitige Mischung aus High- und
Low-Level Elementen auf dem Bildschirm ist nicht möglich.
37
Abbildung 4.4: Graphische Oberfläche der Mensaplan-Anwendung
Für die Mensaplan-Anwendung reichen die Möglichkeiten aus, die das High-Level API bietet, da
nur textuelle Informationen angezeigt werden sollen. Neben der einfacheren Benutzung liegt ein
weiterer Vorteil der Verwendung des High-Level APIs auch in der Anpassung der Darstellung an
die Fähigkeiten des Geräts – auf einem größeren Display werden die Informationen automatisch
entsprechend vorteilhafter dargestellt (siehe Abbildung 4.4). Bei der Gestaltung der Menüführung
wurde allerdings auf kleinere Displays Rücksicht genommen, es werden maximal fünf Menüpunkte
gleichzeitig dargestellt. Es wäre möglich, auch hier eine dynamische Anpassung vorzunehmen, indem bei der Initialisierung die Größe des Displays abgefragt würde. Da die Anwendung keine komplexe Menüführung benötigt wird darauf verzichtet.
Die Klassen für die graphische Oberfläche inklusive der dazugehörigen Command-Listener finden sich im Paket mensaplan.ui. Den Untermenüs für Tag bzw. Woche wird jeweils ein Datenobjekt vom Typ Day oder Week übergeben, der Titel dieser Menüs wird durch die Hilfsklasse
Date2String erzeugt, da die CLDC 1.0 eine date.toString() Methode leider nicht anbietet.
Der Menüpunkt der Bluetooth Komponente wird nur angezeigt, wenn das Gerät auch das Bluetooth API für Java unterstützt. Beim Aufbau einer Verbindung über Bluetooth muss zunächst nach
Geräten und den von diesen angebotenen Diensten gesucht werden. Für diese Device und Service
Discovery des Bluetooth Clients wird Bluelet [Blu] verwendet, eine frei verfügbare Komponente, die
hierzu eine graphische Oberfläche für die J2ME erstellt.
4.3.3.3 Netzverbindung
Die Klassen für die Kommunikation über Internet bzw. Bluetooth Verbindungen finden sich im Paket mensaplan.connection. Die Kommunikation findet dabei stets in eigenen Threads statt, um
38
die weitere Programmausführung nicht zu blockieren.
Die URL des Servers, der die aufbereiteten Daten der Mensapläne anbietet, wird aus dem Applikations Deskriptor ausgelesen und kann somit modifiziert werden, ohne die Anwendung neu kompilieren zu müssen. Das Auslesen erfolgt bei der Initialisierung der Anwendung durch den Aufruf von
getAppProperty(" Server-URL "). Durch diese Properties im Applikations Descriptor können
einem MIDlet beliebige Parameter übergeben werden.
Über eine Instanz der Klasse IPConnection kann eine HTTP-Verbindung zum Server hergestellt werden. Die Kommunikation läuft über das Generic Connection Framework des MIDPs.
Wenn die Übertragung erfolgreich war, werden die empfangene Daten der statischen Methode
ProcessInput.parse() zur Verarbeitung übergeben.
//Http-Verbindung zum Server (read-only,timeout enabled)
HttpConnection hc = (HttpConnection)Connector.open(url,Connector.READ,true);
InputStream in = hc.openInputStream();
int contentLength = (int)hc.getLength();
byte[] raw = new byte[contentLength];
//Daten lesen
in.read(raw);
in.close();
hc.close();
ProcessInput.parse(raw,length,data);
4.3.3.4 Verbindungen über Bluetooth
Bei der Initialisierung der Anwendung wird zunächst überprüft, ob das Gerät Bluetooth unterstützt,
und die entsprechenden Java Schnittstellen nach JSR-82 anbietet. Leider gibt es keinen einheitlichen
Mechanismus, mittels dessen Anwendungen feststellen können, ob ein bestimmtes Paket in der Ablaufumgebung implementiert ist. Einige Spezifikationen schreiben vor, dass die Versionsnummer des
Pakets als System-Property abrufbar sein muss. Wenn die Versionsnummer nicht definiert ist kann
die Anwendung davon ausgehen, dass das betreffende Paket nicht vorhanden ist. Für das optionale
Bluetooth-Paket ist diese Anforderung nicht spezifiziert. Hier schafft die Suche nach einer Instanz
der LocalDevice-Klasse Abhilfe – nur wenn sie gefunden wird, ist eine Unterstützung für Bluetooth gegeben.
try{
Class.forName("javax.bluetooth.LocalDevice");
btSupport=true;
}catch (ClassNotFoundException e){
btSupport=false;
}
Ein jeder Bluetooth-Dienst wird mittels einer eindeutigen UUID (Universally Unique Identifier, 2,4 oder 16 Byte) definiert, für den Austausch der Mensapläne wird willkürlich
0x0102030405060708090A0B0C0D0E0F10 gewählt. Anhand dieser UUID kann der Bluetooth
Client bei der Gerätesuche einen passenden Server finden. Als Transportprotokoll für den Datenaustausch wird das stromorientierte RFComm-Protokoll genutzt.
39
Server
Zu Beginn jeder Kommunikation muss der Bluetooth Stack initialisiert werden, dies gilt für Client
und Server gleichermaßen. Der Server macht sich zusätzlich für andere Geräte auffindbar. Durch
die Übergabe von DiscoveryAgent.LIAC könnte hier die Kommunikation auch auf Clienten beschränkt werden, mit denen zuvor ein Pairing (Authentifizierung anhand von PINs) durchgeführt
wurde. Dies müsste allerdings ausserhalb der Java-Anwendung stattfinden, das Bluetooth-API bietet
hierzu keine Möglichkeit.
LocalDevice device = LocalDevice.getLocalDevice();
device.setDiscoverable(DiscoveryAgent.GIAC);
Das Bereitstellen eines Serverdienstes verläuft nach dem gängigen Schema des Generic Connection
Frameworks: Es wird eine Server-URL gebildet, die sich aus der UUID und dem verwendeten Protokoll zusammensetzt. Mit dieser wird über die Connection-Factory ein Connection Notifier erzeugt,
und schließlich dessen Methode acceptAndOpen() aufgerufen. Diese blockiert nun den Thread
solange, bis sich ein Client verbindet.
String url = "btspp://localhost:0102030405060708090A0B0C0D0E0F10;name=Mensaplan";
StreamConnectionNotifier notifier =(StreamConnectionNotifier)Connector.open(url);
StreamConnection client = notifier.acceptAndOpen();
Bei erfolgreichem Aufbau einer Verbindung liefert acceptAndOpen() eine StreamConnection
zurück. An dieser Stelle könnte ein weiterer Thread speziell für diese Verbindung eröffnet werden,
damit der Server auf weitere Verbindungen warten kann. Da die Hardware der meisten mobilen
Geräte jedoch typischerweise nicht mehr als eine gleichzeitige Bluetooth Verbindung beherrscht,
wird die Kommunikation mit dem Client in dem selben Thread durchgeführt.
Client
Auf der Seite des Clients muss zur Herstellung einer Verbindung zunächst ein Gerät gefunden
werden, welches den Mensaplan-Dienst anbietet. Zur Device und Service Discovery dient die Klasse DiscoveryAgent des Java Bluetooth APIs. Nach Initialisierung des Bluetooth Stacks kann über
Discovery Agent.startInquiry() eine Gerätesuche gestartet werden.
LocalDevice device = LocalDevice.getLocalDevice();
DiscoveryAgent agent = device.getDiscoveryAgent();
agent.startInquiry( DiscoveryAgent.GIAC, new DiscoveryListener() );
Wurde ein Gerät gefunden wird die Methode deviceDiscovered() des Listeners aufgerufen. Ob
das Gerät gewünschte Dienste anbietet, kann mittels der Methode DiscoveryAgent.searchServices()
festgestellt werden. Dazu wird dieser eine Liste mit UUIDs zur Identifizierung der gewünschten
Dienste übergeben – In diesem Fall die eine, für den Austausch der Mensapläne definierte, UUID.
public void deviceDiscovered(RemoteDevice remoteDevice, DeviceClass deviceClass){
UUID [] serviceUUIDs={ mensaplanUUID };
agent.searchServices(attributeSet, serviceUUIDs,
remoteDevice, new DiscoveryListener() );
}
40
Nach Beendigung der Abfrage wird die Methode servicesDiscovered() des Listeners aufgerufen. Dabei wird eine Liste mit ServiceRecords übergeben. Ein solcher Record enthält eine Reihe
von Informationen zu dem gefundenen Dienst, insbesondere eine URL, mit der eine Verbindung
zu diesem Dienst aufgebaut werden kann. Da searchServices() hier nur eine UUID übergeben
wurde, wird entweder eine leere Liste, oder im Erfolgsfall genau ein Record zurückgeliefert.
public void servicesDiscovered(int transId, ServiceRecord[] records){
if(records.length==1) validRecords.addElement(records[0]);
}
Der Benutzer hat nach Abschluss von Device und Service Discovery die Möglichkeit, aus einer Liste
den gewünschten Kommunikationspartner zu wählen. Dessen URL wird aus dem dazugehörigen
ServiceRecord bezogen, anschließend kann über das Generic Connection Framework die Verbindung hergestellt werden.
String url =service.getConnectionURL(ServiceRecord.NOAUTHENTICATE_NOENCRYPT,false);
StreamConnection con = (StreamConnection) Connector.open( url );
Kommunikation
Für die Kommunikation werden DataOutput- bzw. DataInpustreams verwendet, über die einfache
Datentypen und Strings versendet werden können. Dieses Verfahren eignet sich nicht für beliebige
Daten – der Empfänger muss die Abfolge der Datentypen in seinem DataInputStream kennen, um die
Daten korrekt zu interpretieren. Beispielsweise muss folgenden DataOutputStream zur Übertragung
der Daten einer Woche, ein korrespondierender DataInputStream auf der Empfängerseite entgegen
nehmen.
Sender:
DataOutputStream out = connection.openDataOutputStream();
out.writeLong(week.getDate());
for (int i=0;i<5;i++){
out.writeUTF(week.getDay(i).getMenu());
out.writeUTF(week.getDay(i).getAlt());
out.writeUTF(week.getDay(i).getAusw());
out.writeUTF(week.getDay(i).getWloy());
}
out.flush();//um ggf. gepufferte Daten zu senden
Empfänger:
DataInputStream in = c.openDataInputStream();
week.setDate(in.readLong());
for (int i=0;i<5;i++){
week.getDay(i).setMenu(in.readUTF());
week.getDay(i).setAlt(in.readUTF());
week.getDay(i).setAusw(in.readUTF());
week.getDay(i).setWloy(in.readUTF());
}
41
Abbildung 4.5: Datenaustausch zwischen Server und Client via Bluetooth
Der Austausch der Mensadaten erfolgt nach einem einfachen Protokoll, bei dem zunächst die Anfangstermine der vorhandenen Daten zwischen Client und Server ausgetauscht werden. An dieser
Stelle wissen somit beide Teilnehmer, wessen Daten aktueller sind und damit auch über die Struktur
des nun folgenden Datenaustauschs Bescheid. Wenn der Server über aktuellere Daten verfügt, sendet er sie im Anschluss an die Anfangstermine. Sind dagegen die Daten des Clients aktueller, sendet
er diese, und der Server aktualisiert seine Daten. Am Ende des Austauschs verfügen somit beide
Teilnehmer über identische Daten.
4.3.4 Desktop-Relay
Durch die Verwendung avetanaBluetooth Bibliothek konnte der Code der mobilen Anwendung nahezu unverändert übernommen werden. Die Daten werden über das Internet vom Mensaplan-Server
bezogen, und mit dem Parser der mobilen Anwendung verarbeitet. Anschließend wird der BT-Server
gestartet; auch hier wird die entsprechende Klasse aus der mobilen Anwendung verwendet. Einziger
Unterschied: Durch die Eingabe von ’x’ kann der Benutzer die Anwendung vorzeitig beenden.
4.3.5 Mensaplan Webservice
Zur Realisierung des Mensaplan Dienstes als Webservice wird das Framework Apache Axis verwendet. Dieses bietet neben einem auf Servlets basierenden Server für Webservices auch Werkzeuge, die
eine einfache Transformation bestehender Webanwendungen ermöglichen.
Zunächst läßt sich mittels Java2WSDL aus einem Interface der gewünschten Dienste in Verbindung
mit den dazugehörigen Datenhaltungsklassen eine WSDL-Datei generieren. Diese beinhaltet die Datenstrukturen und Schnittstellen der angebotenen Funktionen, sowie die verwendete Kodierung der
SOAP Nachrichten. Die für den mobilen Client verwendete Mirae-Bibliothek unterstützt zwar mehrere Kodierungen, das optionale WS-Paket für die J2ME allerdings ausschließlich das mittlerweile
gebräuchlichste Document Literal Encoding. Aus Kompatibilitätsgründen wurde somit diese
Kodierung gewählt. Der Overhead bei der Kommunikation mittels SOAP ist im Vergleich zur vorher
verwendeten eigenen Kodierung zwar gestiegen, bleibt aber noch vertretbar.
<?xml version="1.0" encoding=" UTF-8"?>
42
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instanceÀ
<soapenv:Body>
<getThisWeekReturn xmlns=" urn:MensaDataÀ
<date>1122854400000</date>
<mon>
<menu>
Shop Suey mit Huhnfleisch, Gemüse und Sojakeimen, Reis
Joghurt mit Aprikosen
</menu>
<alt>
Chinakohlsalat
Vollkornnudeln überbacken, Tomaten-Basilikumsauce
Frisches Obst
</alt>
...
</fri>
</getThisWeekReturn>
</soapenv:Body>
</soapenv:Envelope>
Aus der WSDL-Datei lassen sich anschließend mittels WSDL2Java Skeleton-Klassen zur Anbindung
der Serveranwendung und Methoden zur De-/Serialisierung der Datenstrukturen in das gewählte
XML-Format generieren. Auf dieser Basis kann die bislang als Servlet realisierte Anwendung relativ
einfach angepasst werden:
Beim Start des Webservices durch den Axis-Server, wird ein neues Datenobjekt erzeugt. Dieses ruft
im Konstruktor den Parser auf, der die Daten aus den Seiten des Studentenwerks extrahiert.
public class MensaDataSoapBindingImpl implements mensaData.MensaData{
public Model data=new Model();
public mensaData.Week getThisWeek() throws java.rmi.RemoteException {
return data.getThisWeek();
}
...
Die Installation des Webservices auf dem Axis-Server erfolgt mittels einer Konfigurationsdatei
(deploy.wsdd), die sich ebenfalls durch WSDL2Java generieren läßt. Sie ist vergleichbar mit einer
web.xml-Datei zur Installation von Servlets, es lassen sich beispielsweise Einstellungen bezüglich
des Session-Handlings etc. festlegen.
43
4.3.6 Mensaplan MIDlet mit Kommunikation via Webservice
Das Mensaplan MIDlet wird mittels der Mirae-Bibliothek um die Fähigkeit der Nutzung von
Webservices erweitert. Ein Werkzeug zur Generierung von Stub-Klassen und Methoden zur De/Serialisierung der Daten anhand der WSDL-Beschreibung des Webservices ist Bestandteil des Mirae-Pakets. Die notwendigen Erweiterungen des Codes können also teilweise automatisch erstellt
werden.
Auch für die Kommunikation via Bluetooth werden XML-kodierte Daten verwendet, indem dieselben Methoden zur De-/Serialisierung der Daten wie beim Webservice genutzt werden. Zusätzlich
wird die Verwendung des Object Exchange Protocols zum Datenaustausch nötig. Diese Funktionalität
wird dem MIDlet über die AvetanaOBEX-Bibliothek hinzugefügt.
Für diese Version des Mensaplan MIDlets werden somit die Klassen des Connection-Paketes angepasst, die Datenhaltungsklassen um die entsprechenden Methoden zur XML-Kodierung ergänzt
und die beiden Bibliotheken eingebunden.
4.3.6.1 Aufruf des Webservices
Der Abruf der Daten per Webservice gestaltet sich recht transparent, die Kommunikation mit dem
Server ist in der Klasse MensaDataStub gekapselt. Hier werden die jeweiligen SOAP-Aufrufe zusammengestellt und die eintreffenden Nachrichten mittels XML-Parser verarbeitet. Zu Beginn der
Kommunikation werden die Anfangstermine der Daten des Servers abgerufen, die eigentlichen Daten werden nur übertragen, wenn sie aktueller sind als die vorhandenen.
MensaDataStub stub=new MensaDataStub(data.getURL());
Dates checkDates=stub.getCurrentDate();
if (checkDates.getThisWeek() > data.getThisWeek().getDate()){
data.setThisWeek(stub.getThisWeek());
}
if (checkDates.getNextWeek()>data.getNextWeek().getDate()){
data.setNextWeek(stub.getNextWeek());
}
Bei der Implementierung ergaben sich allerdings Probleme: Der Aufruf des Webservices funktionierte zunächst nicht. Letztlich waren diese auf kleinere Unstimmigkeiten bei der Behandlung
von XML-Namespaces, zwischen dem serverseitigen Axis-Framework und dem Mirae-Stubgenerator
zurückzuführen. Auch der Aufruf von Webservices anderer Anbieter aus dem Internet zu Testzwecken ergab ein ähnliches Bild, nur wenige funktionierten auf Anhieb. Der Abruf komplexerer
Daten war immer mit einer Nachbearbeitung der automatisch generierten Stubs verbunden. Dies ist
nicht unbedingt dem Stubgenerator des Mirae-Paketes anzulasten, eine komfortable Nutzung von
Webservices ist wohl in den meisten Fällen nur möglich, wenn der Client mit demselben Framework
erstellt wird, wie der Server. Eine problemlose plattform- und programmiersprachenunabhängige
Kommunikation über Webservices bleibt zum heutigen Zeitpunkt leider noch Fiktion.
Der Stubgenerator im Wireless Toolkit 2.2, der Stubs für das optionale WS-Paket erstellen
44
soll, ist in dieser Hinsicht noch eingeschränkter, da er nur Webservices akzeptiert, die im
Document Literal Encoding angeboten werden. Auch wenn sich dieses Format mittlerweile durchzusetzen scheint, gibt es immer noch viele Webservices, die im ursprünglichen
SOAP RPC Encoding angeboten werden [enc].
4.3.6.2 OBEX-Verbindungen über Bluetooth
Für die Kommunikation über Bluetooth wurde dieselbe XML-Kodierung für die Daten verwendet,
wie bei der Übertragung per Webservice. Dies bot sich an, da die Methoden zu De-/Serialisierung
der Daten schon vorhanden waren. Als Kommunikationsprotokoll wurde das Object Exchange
Protocol gewählt, da es eine dem HTTP äquivalente Funktionalität bietet. Die bisher verwendete
Übertragung per RFComm-Protokolls hätte wenig Sinn ergeben, da die De-/Encoder-Methoden in
diesem Fall nicht direkt mit dem Output-/Inputstream der Verbindung arbeiten können.
Server
Der Bluetooth-Server stellt einen OBEX-Push Dienst für die Datenübertragung der XML-kodierten
Mensapläne bereit. Für OBEX-Push Dienste ist die UUID 0x1105 definiert. Das Paket mit den
OBEX-Klassen findet sich bei Benutzung der avetanaOBEX-Bibliothek nicht, wie man von der JSR82 Spezifikation ableiten könnte, unter javax.obex.*, weil der Namensraum javax von keiner Anwendung für eigene Klassen benutzt werden darf. Aus diesem Grund läuft der Aufbau
einer Verbindung auch nicht über das Generic Connection Framework ab, sondern über die Klasse
de.avetana.obexsolo.OBEXConnector. Eine nachträgliche Integration neuer Verbindungstypen in das GFC ist leider nur den Geräteherstellern möglich [Gme05].
Unterschiede finden sich auch im weiteren Ablauf: Nach dem Connect eines Clients wird die folgende Kommunikation über einen Request-Handler abgewickelt, der hierfür entsprechende Methoden
anbietet.
notifier = (de.avetana.javax.obex.SessionNotifier)
OBEXConnector.open("btgoep://localhost:0x1105");
ServerRequestHandler srh=new RequestHandler(this);
notifier.acceptAndOpen(srh);
Die Methode onConnect() des Request-Handlers dient dem Initialisieren der Kommunikation,
onGet() der Datenübertragung und onDisconnect() dem Abbau der Verbindung. Zur Bestimmung der zu liefernden Daten wird in onGet() das Feld HeaderSet.NAME des RequestHeaders
ausgewertet.
Je nach geforderten Daten werden der Methode zur Serialisierung aus der Mirae-Bibliothek
(Encoder.serialize) die entsprechenden Parameter und der OutputStream übergeben.
public int onGet(Operation op){
HeaderSet hs = op.getReceivedHeaders();
String type=(String)hs.getHeader(HeaderSet.NAME);
OutputStream out=op.openOutputStream();
45
if (type.equals("thisWeek.xml")){
methodName = new javax.xml.namespace.QName(" urn:MensaData","getThisWeekReturn");
paramName = new javax.xml.namespace.QName(" urn:MensaData","Week");
inInfo[0]=new InputParameterInfo(data.getThisWeek(),"thisWeek",paramName);
}
...
Encoder.serialize(methodName, inInfo, Constants.STYLE_DOCUMENT, out);
}
Client
Die Device und Service Discovery des Clients wird mit der geänderten UUID durchgeführt. Mit der
erhaltenen URL wird mittels OBEXConnector.open() eine ClientSession eröffnet. Über diese
können die OBEX-Requests gestellt werden.
Zunächst wird ein HeaderSet erstellt, dann die Kommunikation mit dem Server mittels
connect() initialisiert. Ein Aufruf von get() liefert ein Operation-Objekt zurück, über das
auf Header und InputStream der Antwort des Servers zugegriffen werden kann. Welche Daten
beim get() jeweils abgerufen werden sollen wird dem Server über das Feld HeaderSet.NAME des
Headers der OBEX-Nachrichten mitgeteilt. Die Dekodierung des erhaltenen Inputstreams erfolgt
mithilfe der Mirae-Bibliothek.
ClientSession cs=(ClientSession) OBEXConnector.open(url);
HeaderSet hs=cs.createHeaderSet();
hs.setHeader(HeaderSet.TYPE, "text/xml");
hs.setHeader(HeaderSet.NAME, Ïnitialize");
HeaderSet serverResponse=cs.connect(hs);
if (serverResponse.getResponseCode()==OBEX_HTTP_OK){
hs.setHeader(HeaderSet.NAME, "dates.xml");
Operation op=cs.get(hs);
InputStream is=op.openInputStream();
Decoder decoder= new Decoder(new Dates(),Constants.TYPE_DOCLIT,"getCurrentDateReturn");
decoder.decode(is);
Dates serverDates=((Dates)decoder.getParam());
is.close(); op.close();
}
Dem Verbindungsaufbau folgt zunächst ein Abruf der Anfangstermine der beiden Wochen. Im Anschluss daran werden die Wochendaten bezogen, wenn diese aktueller als die vorhandenen des Clients sind.
4.3.7 SyncML-Prototyp
Zur Erläuterung der Funktionsweise des SyncML-Prototypen wird zunächst die verwendete interne Datenstruktur für die Adressbucheinträge beschrieben. Die eigentliche Synchronisation mit dem
46
Abbildung 4.6: Sequenzdiagramm SycnML-Client
Server erfolgt anhand eines speziellen, für jeden Eintrag vorhandenen Statusfeldes. Beim Start der
Anwendung muss zunächst ein Abgleich der Adressbucheinträge des Gerätes mit den innnerhalb
der Anwendung gespeicherten Daten vorgenommen werden. Aufgetretene Veränderungen müssen
dabei registriert, und in die internen Daten der Anwendung übernommen werden. Dabei müssen
auch die Statusfelder zur Synchronisation entsprechend gesetzt werden. Zur Bearbeitung der Daten
innerhalb der Anwendung kommt eine entsprechende graphische Oberfläche hinzu. Den Ablauf der
nötigen Funktionen beschreibt das Sequenzdiagramm in Abbildung 4.6.
4.3.7.1 Interne Datenstruktur
Zentrales Element des SyncML-Prototypen sind die im Record Management System gespeicherten internen Daten. In einem Record sind jeweils die Daten eines einzelnen Kontaktes aus dem Adressbuch
des Gerätes gespeichert. Ein solcher Record besteht aus drei Teilen: Zunächst ist einem jeden Kontakt
eine systemweit gültige, eindeutige Nummer zur Identifizierung (UID) zugeordnet.
Desweiteren wird der aktuelle Synchronisationsstatus gespeichert. ’N’ zeigt an, dass dieser Kontakt
47
neu auf dem Gerät erstellt und noch nicht an den Server übermittelt wurde. Lokale Änderungen an
vormals mit dem Server synchronisierten Kontakten werden durch ein ’U’ als gesetztem Status festgehalten. Ein lokal gelöschter Kontakt, dessen Entfernung noch an den Server übermittelt werden
muss, wird mit einem ’D’ markiert. Wenn keine lokalen Veränderungen an einem Kontakt vorgenommen wurden, wird dies durch einen ungesetzen Status ’ ’ angezeigt.
Im Anschluss an den Status folgen die eigentlichen Daten des Kontaktes, kodiert im zum Austausch
von Adressbucheinträgen gängigen vCard-Format [vCa].
Der Zugriff auf die Records des RMS erfolgt über die Methoden storeRecord(record) und
deleteRecord(key) der Klasse syncclient.sps.DataStore. Ob ein zu speichernder Record
neu hinzugefügt werden soll, oder eine Änderung eines bestehenden Records darstellt, wird in
storeRecord(record) ermittelt.
4.3.7.2 Initialisierung
Bei der Initialisierung der Anwendung werden alle Einträge der Adressdatenbank des Gerätes
eingelesen und mit den intern gespeicherten Daten verglichen. Innerhalb der Methode
storeRecord(record) des DataStore wird bei neuen Kontakten ein entsprechender Record
erstellt, bei modifizierten Kontakten werden die geänderten Werte übernommen und der Status auf
’U’ gesetzt.
Um festzustellen, ob Kontakte auf dem Gerät gelöscht wurden, wird die UID eines jeden eingelesenen Kontaktes temporär gespeichert. Nach Beendigung des Einlesens werden alle internen Records
daraufhin überprüft, ob ein entsprechender Kontakt gerade eingelesen wurde. Ist dies nicht der
Fall, wurde der dazugehörige Kontakt auf dem Gerät gelöscht, und der Record wird mit einem ’D’
markiert.
ContactList myContacts = (ContactList) PIM.getInstance().openPIMList
(PIM.CONTACT_LIST, PIM.READ_ONLY);
pimEnumeration=myContacts.items();
Hashtable importedRecords=new Hashtable();
while (pimEnumeration.hasMoreElements()){
contact = (Contact)pimEnumeration.nextElement();
key=contact.getString(Contact.UID,0);
record=new Record(key,’N’, pimStore.toSerialFormat(contact));
dataStore.storeRecord(record);
importedRecords.put(key,"true");
}
while (recordEnumeration.hasNextElement()) {
record = new Record(recordEnumeration.nextRecord());
if (importedRecords.get(record.getKey())==null)
deleteRecord(record);
}
48
Abbildung 4.7: Graphische Oberfläche des SyncML-Clients
4.3.7.3 Bearbeiten von Kontakten
Der Benutzer kann im Rahmen der Anwendung neue Kontakte hinzufügen und bestehende verändern oder löschen. Hierzu wurde eine aus zwei Teilen bestehende graphische Oberfläche implementiert (siehe Abbildung 4.7). Die Klasse syncclient.pim.DataList erzeugt eine Liste aller vorhandenen Kontakte, die gelöscht oder ausgewählt werden können. Die Klasse
syncclient.pim.ContactForm erstellt ein Formular, mittels dessen Kontakte modifiziert, oder
neu angelegt werden können.
In der Spezifikation zur PIM-API finden sich keine Datenfelder, die verpflichtend implementiert
werden müssen. Vor Benutzung eines Feldes muss immer überprüft werden, ob es von der jeweiligen Implementierung unterstützt wird. Diese Überprüfung findet hier im Konstruktor der Klasse
syncclient.pim.PIMStore statt, in der sich alle Methoden zum Zugriff auf die Adressdatenbank des Gerätes finden. Die getestete Implementation der PIM-API auf dem Palm ermöglicht leider
nur den Zugriff auf sehr wenige Felder der Datenbank.
ContactList myContacts = (ContactList) PIM.getInstance().openPIMList
(PIM.CONTACT_LIST, PIM.READ_ONLY);
int sup_NameSize=myContacts.stringArraySize(Contact.NAME);
boolean sup_NameFamily=myContacts.isSupportedArrayElement
(Contact.NAME, Contact.NAME_FAMILY);
boolean sup_NameGiven=myContacts.isSupportedArrayElement
(Contact.NAME, Contact.NAME_GIVEN);
boolean sup_TelNR=myContacts.isSupportedField(Contact.TEL);
boolean sup_Home=myContacts.isSupportedAttribute(Contact.TEL,Contact.ATTR_HOME);
49
Je nachdem, welche Datenfelder unterstützt werden, blendet ContactForm entsprechende Texteingabefelder ein. Wenn der Benutzer die Änderungen abspeichern möchte, wird zunächst der Kontakt
der Adressdatenbank des Gerätes geändert, anschließend der Record im RMS.
Contact workContact=myContacts.createContact();
String[]name=new String[pim.sup_NameSize];
name[Contact.NAME_GIVEN]=nameGiven.getString();
name[Contact.NAME_FAMILY]=nameFamily.getString();
workContact.addStringArray(Contact.NAME, Contact.ATTR_NONE, name);
workContact.addString(Contact.TEL, Contact.ATTR_HOME, tel.getString());
Record modRecord=pimStore.modifyPIMContact(UID,workContact);
modRecord.setState(’U’);
dataStore.storeRecord(modRecord);
Beim Löschen von Kontakten können zwei Fälle unterschieden werden: Im Normalfall wird nur der
Kontakt auf dem Gerät gelöscht und der Record im RMS mit dem Status ’D’ versehen. Sollte der
zu löschende Kontakt aber noch nicht mit dem Server synchronisiert worden sein (Status ’N’) kann
auch der Record sofort gelöscht werden.
4.3.7.4 Synchronisation
Wird vom Benutzer die Synchronisation gewünscht, muss zunächt eine Instanz der Klasse
syncclient.spds.SyncManagerImpl erzeugt werden. Dabei wird der im RMS gespeicherte
Zeitstempel der letzten Synchronisation abgerufen und zugleich ein Neuer angelegt, der am Ende
einer erfolgreichen Synchronisation wieder ins RMS geschrieben werden kann. Als Erstes wird jetzt
eine Initialization-Nachricht zusammengestellt. Aus Gründen der Effizienz werden die zu sendenden Nachrichten zu einem großen Teil aus Textbausteinen zusammengefügt. Zum Parsen der XMLkodierten Antworten findet ein sogenannter Pull-Parser Verwendung, der relativ wenig Ressourcen
benötigt.
Als Antwort sendet der Server in seiner Initialization-Nachricht die Art der durchzuführenden Datensynchronisation oder eine Fehlermeldung. Wenn zuvor noch keine Synchronisation zwischen
Client und Server stattgefunden hat, muss ein Slow-Sync durchgeführt werden. Dabei muss der
Client sämtliche Daten an den Server senden, mit Ausnahme der mit ’D’ markierten. Die Methode filterRecordsForSlowSync() der Klasse DataStore liefert die entsprechenden Records
zurück. Wenn zuvor schon eine erfolgreiche Synchronisation zwischen Server und Client erfolgt ist,
reicht ein sogenannter Fast-Sync. Dabei werden nur jene Daten zum Server übertragen, die sich seit
der letzten Synchronisation geändert haben.
Nachdem der Client diese Modification-Nachricht zusammengestellt und an den Server gesendet hat,
antwortet dieser ebenfalls mit einer solchen Nachricht. Sie enthält alle neuen oder geänderten Kontakte im vCard-Format sowie die UIDs der zu löschenden. Die Änderungen werden zunächst in der
Adressdatenbank des Gerätes vorgenommen, anschließend ins RMS übernommen. Beispielsweise
wird das Hinzufügen eines neuen Kontaktes folgendermaßen realisiert:
String key
50
= getXMLTagValue((String) addTags.elementAt(i), TAG_LOC_URI);
String content = getXMLTagValue((String) addTags.elementAt(i), TAG_DATA);
Record record = new Record(key, ’ ’, content);
record=pimStore.addPIMContact(record);
dataStore.storeRecord(record);
mappings.put(record.getKey(), key);
In einem Hashtable werden die UIDs von neu hinzugefügten Kontakten gespeichert. Viele Anwendungen übernehmen nicht die vom Server kommende globale UID (kurz GUID) sondern vergeben
beim Speichern eine eigene, lokale UID (LUID). Die PIM-API erlaubt es ebenfalls nicht, eine UID
vorzugeben, sondern legt beim Speichern eine eigene fest. Aus diesem Grund muss eine Abbildung
von der globalen auf die lokale UID vorgenommen werden. Laut SyncML-Spezifikationen sollte der
Server diese Arbeit übernehmen, die Abbildungen werden somit vom Client beim Abspeichern gesammelt, und in einer abschließenden Mapping-Nachricht an den Server gesandt.
Leider funktionierte dies beim verwendeten Sync4j-Server nicht einwandfrei. Hin und wieder schien
der Server das aktuelle Mapping zu vergessen“ und es kam daraufhin zu duplizierten Datensätzen.
”
Um diese Fehler zu umgehen übernimmt der Client selbst die Abbildung von LUID auf GUID und
zwar direkt beim Auslesen der Kontakte aus der Adressdatenbank. In den Records im RMS und für
die Kommunikation mit dem Server wird durchgängig die GUID verwendet. Das Mapping wurde in
der Klasse syncclient.pim.UIDMap implementiert, welche die Abbildungen persistent im RMS
ablegt. Bei der Initialisierung der Anwendung werden die Daten aus dem RMS ausgelesen und für
einen schnellen Zugriff in einem Hashtable gespeichert.
Nach Abschluss der Kommunikation mit dem Server werden vom SyncManager noch sämtliche
Records mit dem Status ’ ’ versehen und der neue Zeitstempel im RMS abgelegt – die Datensätze
sind jetzt synchronisiert.
4.3.7.5 Zugriff auf die PIM-Datenbank
Sämtliche Methoden für den Zugriff auf die Adressdatenbank des Gerätes finden sich in der Klasse
syncclient.pim.PIMStore. Details zu den einzelnen Methoden werden im Folgenden erläutert.
Dabei werden insbesondere die Probleme mit der Implementation der PIM-API, auf dem zu Testzwecken verwendeten Palm dokumentiert.
Import und Export von Adressdaten
Die PIM-API beinhaltet statische Methoden zum Import und Export von Adressdaten aus dem
vCard-Format. Welche Formate von der jeweiligen Implementation unterstützt werden, lässt sich mit
PIM.getInstance().supportedSerialFormats(PIM.CONTACT_LIST) abfragen. Zum Imund Export eines Kontaktes dienen folgende Methoden:
PIM.getInstance().toSerialFormat(contact,outputstream,encoding,format)
PIM.getInstance().fromSerialFormat(inputstream, encoding)
Die Spezifikation sieht vor, dass von der jeweiligen Implementation nicht unterstützte Felder
51
beim Import ignoriert werden. Ein Contact-Objekt soll aber in jedem Fall erzeugt werden.
Die Implementation der PIM-API auf dem Palm tat dies allerdings nicht: Wenn bestimmte Felder der zu importierenden vCard gesetzt werden, wird der Import mit NullPointer- oder
ArrayIndexOutOfBounds-Exceptions beendet, obwohl die vCards keine syntaktischen Fehler
aufwiesen.
Behelfsmäßig wurde bei den Tests des Prototypen darauf geachtet, dass die vom Server übermittelten
vCards diese Einträge nicht enthalten – eine annehmbare Lösung stellt dies jedoch nicht dar. Eine
Anwendung, die beliebige Adressdaten im vCard importieren soll, müsste demnach einen eigenen
Parser für diese Zwecke implementieren.
Zugriff auf einzelne Adressen des Gerätes
Um auf Einträge der Adressdatenbank des Gerätes zuzugreifen, bietet das PIM-API Methoden, mit
denen die Datenbank nach bestimmten Kriterien durchsucht werden kann. Am sinnvollsten eignet
sich die UID eines bestimmten Eintrages zu dessen Identifizierung. Leider lieferte die Implementation der PIM-API auf dem Palm keine Ergebnisse, wenn nach der UID gesucht wurde, obwohl die
Spezifikation diese Möglichkeit ausdrücklich vorsieht. Aus diesem Grund wurde für den Prototypen
die Suche selbst implementiert: Jeder Eintrag der Datenbank muss dabei ausgelesen und auf seine
UID überprüft werden.
Alle Zugriffe auf einzelne Adressen werden über die Methode PIMStore.retrievePIMContact
durchgeführt, der die UID des gewünschten Kontaktes übergeben wird. Eventuell muss innerhalb
dieser Methode eine Abbildung von der globalen auf die lokale UID vorgenommen werden (Siehe
Kapitel 4.3.7.4).
String pimUID=mapping.getPimUID(GUID);
if (pimUID!=null)GUID=pimUID;
myContacts=(ContactList) PIM.getInstance().openPIMList(PIM.CONTACT_LIST, PIM.READ_ONLY);
Enumeration pimEnumeration = myContacts.items();
Contact searchContact=null;
while (pimEnumeration.hasMoreElements()){
searchContact=(Contact)pimEnumeration.nextElement();
if (searchContact.getString(Contact.UID,0).equals(GUID))
return searchContact;
}
Hinzufügen neuer Adressen
Neue Adressen können vom Benutzer innerhalb der Anwendung erstellt, oder im Zuge der Synchronisation vom Server übermittelt werden. In letzterem Fall muss eine Abbildung von der globalen auf
die lokale UID gespeichert werden. Die lokale UID ergibt sich, nachdem ein Kontakt in der Adressdatenbank abgelegt wurde (commit()).
myContacts =(ContactList) PIM.getInstance().openPIMList(PIM.CONTACT_LIST,PIM.READ_WRITE);
Contact contact2add=myContacts.importContact(fromSerialFormat(record2add.getContent()));
contact2add.commit();
52
String globalUID = record2add.getKey();
String localUID
= contact2add.getString(Contact.UID,0);
mapping.addMapping(globalUID,localUID);
Modifizieren bestehender Adressen
Die Modifikation bestehender Adressen gestaltet sich etwas komplizierter. Ein Eintrag in der Adressdatenbank kann nicht komplett überschrieben werden, daher müssen die vom Server erhaltenen neuen Werte in sämtliche Felder des Eintrages übernommen werden. Es gibt unterschiedliche Arten von Feldern, beispielsweise wird auf Namen und Adresse eines Eintrages mittels eines StringArrays zugegriffen, während Telefonummern oder Emailadressen als Zeichenketten
gespeichert sind. Zu jedem Eintrag ist zusätzlich die Vergabe von speziellen Attributen möglich,
zum Beispiel bei Telefonnummern ATTR.HOME, ATTR.MOBILE, ATTR.PREFERED etc. Einige Felder
können zudem mehrfach vorkommen, beispielsweise mehrere Telefonnummern oder eine Adresse
mit HOME, und eine mit WORK als Attribut. Der Codeausschnitt zeigt die Übernahme von Feldern, die
Zeichenketten speichern.
Zudem sollte vor dem Zugriff auf ein jedes Feld überprüft werden, ob die jeweilige Implementation der PIM-API dieses Feld auch unterstützt. Da vom Server kommende Modifikationen zunächst mittels fromSerialFormat() deserialisiert werden, kann diese Überprüfung entfallen: Laut Spezifikation sollte diese Methode der PIM-API nur die Felder übernehmen, die
auf der jeweiligen Plattform unterstützt werden und die restlichen einfach ignorieren. Mittels
modifiedContact.getFields() kann dann auf die Felder des importierten Contacts zugegriffen werden, die auch alle unterstützt werden.
oldContact=retrievePIMContact(UID);
int [] modFields=modifiedContact.getFields();
for (int i=0;i<modFields.length;i++){
// ..Felder des alten Kontaktes mit modifizierten Werten überschreiben..
int numbersNEW=modifiedContact.countValues(modFields[i]);
int numbersOLD=oldContact.countValues(modFields[i]);
if (modFields[i]==Contact.TEL || modFields[i]==Contact.EMAIL){
for (int num=0;num<numbersNEW;num++){
attributes=modifiedContact.getAttributes(modFields[i],num);
if (num<numbersOLD)
oldContact.setString(modFields[i], num, attributes ,
modifiedContact.getString(modFields[i],num));
else
oldContact.addString(modFields[i], attributes ,
modifiedContact.getString(modFields[i],num));
}
}
// ...
}
oldContact.commit();
53
Löschen von Adressen
Der zu löschende Adressbucheintrag wird in der Datenbank lokalisiert, und kann dann entfernt
werden. Eventuell muss zusätzlich eine vorhandene Abbildung der UID gelöscht werden.
Contact contact2delete=retrievePIMContact(UID);
myContacts =(ContactList) PIM.getInstance().openPIMList(PIM.CONTACT_LIST,PIM.READ_WRITE);
if(contact2delete!=null){
mapping.removeMapping(contact2delete.getString(Contact.UID,0));
myContacts.removeContact(contact2delete);
}
4.3.7.6 Kompatibilität mit anderen SyncML-Lösungen
Ein wesentlicher Vorteil von SycnML ist die Möglichkeit, Daten zwischen Anwendungen unterschiedlicher Anbieter zu sychronisieren. Zu Testzwecken wurde eine Synchronisation zwischen dem
SyncML-Prototypen und dem Multisync-Server versucht. Leider blieben diese Versuche ohne Erfolg,
die Kommunikation ging über die Initialisierungsphase nicht hinaus. Der genaue Fehler ließ sich
nicht lokalisieren, wird aber auf der Seite des Servers vermutet.
Multisync wird zur Zeit vollständig überarbeitet und neu strukturiert, der Fokus der Entwicklung
liegt dabei insbesondere auf dem SyncML-Teil. Dieser soll in eine eigene Bibliothek ausgelagert
werden, damit auch andere Anwendungen unter Linux die Funktionalität von SyncML zur Datensynchronisation nutzen können. Zusätzlich soll neben HTTP auch OBEX als Transportprotokoll genutzt werden. Die Entwickler von Multisync haben aufgrund dieser umfangreichen Änderungen
seit einigen Monaten keine neue Version mehr freigegeben. Die Versuche mussten daher mit einer älteren Version durchgeführt werden, deren SyncML-Implementation als experimentell gekennzeichnet war.
Die Zukunft des Multisync-Projekts kann jedoch positiv eingeschätzt werden. Dafür spricht eine rege
Beteiligung von Entwicklern, die sich schon längere Zeit mit der Datensynchronisation beschäftigen.
Eine standardisierte Bibliothek würde sicherlich zu einer steigenden Verbreitung von SyncMLfähigen Anwendungen unter Linux führen.
Kapitel 5
Resümee
Durch die Evaluation konnte ein guter Einblick in die Möglichkeiten und Probleme bei der Synchronisation mobiler Anwendungen auf Basis der J2ME gewonnen werden. Bei der abschließenden Beurteilung sollen neben den technischen Ursachen der aufgetretenen Probleme auch weitere Faktoren
benannt werden, die den Einsatz der J2ME für die Entwicklung mobiler Anwendungen in Frage stellen. Ein Ausblick auf zukünftige Entwicklungen im Bereich der J2ME soll zeigen, welche Lösungen
für die hier dokumentierten Probleme in Zukunft zu erwarten sind. Eine wichtige Rolle spielt in
diesem Zusammenhang die weitere Verbreitung der Plattform, denn nur wenn neue Entwicklungen
auch auf einer ausreichenden Zahl an Geräten unterstützt werden, wird die Anwendungsentwicklung auf Basis der J2ME sinnvoll.
5.1 Beurteilung der Anwendungsentwicklung auf Basis der CLDC
Die Evaluation der betrachteten Verfahren zur Datensynchronisation brachte viele Schwierigkeiten bei der Entwicklung entsprechender mobiler Anwendungen auf Basis der CLDC zu Tage. Die
Gründe dafür sind unterschiedlich: Einige Probleme sind klar der geringen Leistungsfähigkeit der
betreffenden Geräte geschuldet, andere haben ihren Ursprung in relativ offen gehaltenen Spezifikationen einzelner Pakete. Darüber hinaus sind gewisse Restriktionen der Plattform von den Herstellern durchaus beabsichtigt; Schwierigkeiten, die hieraus resultieren, sind für den Entwickler umso
ärgerlicher.
Im Folgenden sollen die bei der Evaluation aufgetretenen Probleme im Kontext der Gesamtentwicklung der CLDC-Plattfom betrachtet werden. Die Problematik der drohenden Fragmentation
der Plattform wird dabei einer gesonderten Betrachtung unterzogen. Dem gegenübergestellt werden zunächst die positiven Aspekte bei der Entwicklung CLDC-basierter Anwendungen.
5.1.1 Vorteile der Entwicklung auf Basis der CLDC
Eine Laufzeitumgebung für Anwendungen auf Basis der CLDC findet sich zum heutigen Zeitpunkt
auf sehr vielen mobilen Geräten. Kaum ein Mobiltelefon oder Smartphone wird mehr ohne eine vir-
5.1 B EURTEILUNG DER A NWENDUNGSENTWICKLUNG AUF B ASIS DER CLDC
55
tuelle Maschine für die CLDC ausgeliefert. Damit existiert ein lukrativer Markt für Anwendungen auf
dieser Plattform.
Die J2ME ermöglicht eine plattformunabhängige Entwicklung auf einer Vielzahl unterschiedlicher
Geräte: Das MIDP in Version 2.0 ist weit verbreitet, bietet eine relativ umfangreiche Funktionalität
und die jeweiligen Implementationen der Gerätehersteller entsprechen ausreichend genau den Spezifikationen. Die Verheißungen des Slogans ”´Write once, run anywhere“ könnten realisiert werden –
solange die Funktionalität des MIDP 2.0 für die Entwicklung ausreicht. Sobald eine Anwendung jedoch auf optionale Pakete angewiesen ist, reduziert sich die Anzahl der verwendbaren Geräte leider
drastisch.
Sehr angenehm ist der Umstieg auf die J2ME-Plattform für Entwickler mit Erfahrung im Umgang
mit der Java Standard Edition. Die Unterschiede des Sprachumfangs und der API halten sich in Grenzen, für gängige Entwicklungsumgebungen ist eine Unterstützung der J2ME erhältlich, oder bereits
integriert. Einige Details sind auf der J2ME-Plattform sogar vorteilhafter gelöst, als bei der Standard
Edition: Beispielsweise ermöglicht der Aufbau des Generic Connection Frameworks eine einheitliche
und komfortable Verwendung unterschiedlichster Arten von Netzverbindungen.
Positiv hervorzuheben ist auch die Bluetooth-API. Die meisten Geräte mit Bluetooth-Technik implementieren diese Schnittstelle und erlauben so J2ME-Anwendungen die Kommunikation via Bluetooth. In der Java Standard Edition findet sich nichts Vergleichbares. Einziges Manko in diesem Zusammenhang bleibt die uneinheitliche Unterstützung des OBEX-Protokolls. Da dieses in der Spezifikation der Bluetooth-API als optional vorgesehen ist, unterstützen leider nur sehr wenige Geräte das
OBEX-Protokoll. Dieser Mangel lässt sich zwar durch die Integration einer zusätzlichen Bibliothek
in die Anwendung beheben – durch eine verpflichtende Unterstützung des OBEX-Protokolls wäre
die Bluetooth-API aber um einiges universeller einsetzbar geworden, da eine Reihe von Protokollen
der Anwendungsschicht OBEX als Transportprotokoll für Bluetooth-Verbindungen nutzen.
5.1.2 Probleme aufgrund der geringen Leistungsfähigkeit der Geräte
Mit Problemen, die der geringen Leistungsfähigkeit der mobilen Geräte geschuldet sind, wurde im
Vorfeld der Evaluation gerechnet. Im Wesentlichen beschränkte sich dieses Problemfeld auf die Restriktion der maximal möglichen Größe einer Anwendung von 64 Kilobyte. Komplexere Anwendungen stoßen schnell an dieses Limit, insbesondere wenn zusätzliche Bibliotheken mit integriert werden müssen. Im Rahmen der Evaluation ergaben sich für den Umfang der einzelnen Anwendungen
folgende Werte:
Die Größe der ersten Version der Mensaplan-Anwendung beträgt rund 19 Kilobyte – ohne die Klassen der Bluetooth-Verbindung wären es noch 8 Kilobyte weniger. Es bleibt ein großer Spielraum
für zusätzliche Features, denkbar wäre beispielsweise eine personalisierte Darstellung, oder die
Übernahme von Mensadaten in den Terminkalender des Gerätes.
Bei der zweiten Version der Mensaplan-Anwendung wurde zur Nutzung des Webservices eine entsprechende Bibliothek integriert. Diese hat einen Umfang von ca. 22 Kilobyte, vor allem wegen des
nötigen XML-Parsers. Zusammen mit den zusätzlichen Methoden zur De-/Serialisierung der Daten
in XML, wächst die Größe der Anwendung auf 45 Kilobyte. Bei etwas komplexeren Anwendungen
56
dürfte bei einer Integration dieser Webservice-Bibliothek die Grenze von 64 Kilobyte schnell erreicht
sein. Hier gilt es abzuwägen, ob die Verwendung des optionalen Webservice-Paketes nicht vorteilhafter ist, auch wenn dadurch die Zahl der unterstützten Geräte drastisch sinkt.
Um auch über die Bluetooth-Verbindung XML-kodierte Daten zu übertragen, wurde OBEX als Transportprotokoll verwendet. Die mangelnde Unterstützung des OBEX-Protokoll durch die BluetoothAPI macht hierfür den Einsatz einer Bibliothek nötig. Diese hat eine Größe von 10 Kilobyte, zusammen mit den für die Kommunikation via Bluetooth ohnehin nötigen Methoden stieg der Umfang der
gesamten Anwendung auf 63 Kilobyte. Der Einsatz von OBEX in J2ME-Anwendungen ergibt somit
leider nur in speziellen Fällen Sinn.
Aus diesem Grund wurde auch beim SyncML-Prototypen darauf verzichtet, die Synchronisation
via Bluetooth zu erproben. Diese Anwendung weist ohnehin schon eine Größe von 41 Kilobyte auf,
hauptsächlich bedingt durch die Verwendung des XML-basierten SyncML. Die Anwendung wurde
nur als Prototyp implementiert, daher ließe sich durch eine Optimierung des Programmcodes sicherlich noch etwas Speicherplatz einsparen. Es bleibt dennoch fraglich, ob dann die OBEX-Bibliothek
erfolgreich genutzt werden könnte .
Das Größenlimit von 64 Kilobyte stellt also ein ernsthaftes Problem bei der Entwicklung von Anwendungen zur Datensynchronisation dar. Eine mögliche Lösung wäre es, optionale Pakete vorauszusetzen. Das Webservice-API würde nicht nur den Einsatz einer zusätzlichen Bibliothek zur Nutzung von Webservices überflüssig machen – der integrierte XML-Parser könnte auch die Größe der
SyncML-Anwendung entscheidend verringern.
Diese Lösung ist jedoch im Bezug auf das OBEX-Protokoll nicht möglich: Das Bluetooth-API ist ohnehin ein optionales Paket, und OBEX ist darin als optionale Komponente spezifiziert. Dies führt
dazu, dass nur auf einem sehr kleinen Teil der Geräte mit Bluetooth-API auch das OBEX-Protokoll
zur Verfügung steht.
Eventuell wird es dem Benutzer in Zukunft möglich sein, zusätzliche Bibliotheken, unabhängig von
der Anwendung, auf dem Gerät zu installieren. Zumindest in den Vorschlägen zur nächsten Spezifikation des MIDPs in Version 3 [JSRb] finden sich auch solche shared libraries. Erforderlich wäre dazu
allerdings eine erhebliche Öffnung der bislang sehr restriktiven J2ME-Plattform.
Die naheliegendste Lösung des Problems besteht in einer einfachen Erhöhung des Größenlimits
der Anwendungen, ermöglicht durch die steigende Leistungsfähigkeit der Geräte. Einige Hersteller erlauben schon heute die Installation umfangreicherer Anwendungen; spezifiziert wird diese
Änderung aber wohl erst in der nächsten Version des MIDP.
Weitere Probleme im Zusammenhang mit der geringen Leistungsfähigkeit der Geräte konnten erfreulicherweise nicht festgestellt werden. Selbst die Erprobung des SyncML-Prototypen, bei dessen
Entwicklung nur am Rande auf Perfomanz Wert gelegt wurde, ergab keine weiteren Schwierigkeiten. Bei Initialisierung und Synchronisation dieser Anwendung werden relativ viele Daten verarbeitet, auf dem Emulator zeigt sich dabei ein starker Anstieg des Speicherverbrauchs. Auf dem Gerät
ist dies nicht spürbar, die Garbage Collection der KVM scheint recht effizient zu arbeiten. Bei anderen Anwendungsfeldern mag die geringe Rechen- und Speicherkapazität der mobilen Geräte einen
limitierenden Faktor darstellen – im Kontext der Datensynchronisation spielt dies nur eine untergeordnete Rolle.
57
5.1.3 Schwierigkeiten aufgrund zu offener Spezifikationen
Auf den zu Testzwecken verwendeten Geräten konnten erfreulicherweise keinerlei Inkompatibilitäten der jeweiligen Implementationen des MIDPs zur Referenzimplemenation von Sun festgestellt
werden. Diese Erfahrung scheinen die meisten Entwickler zu teilen: Im Verlauf der Implementation
wurden einige Internetforen für J2ME-Entwickler genutzt – von Problemen durch Inkompatibilitäten
der MIDP-Implementationen der verschiedenen Hersteller wurde dabei kaum berichtet. Die Spezifikationen des MIDP scheinen also sehr wenig Spielraum bei der Implementierung zu lassen; zudem
kann dem Profil eine gewisse Reife zugesprochen werden.
Ganz anders gestalteten sich die Versuche mit dem PIM-API: Zunächst wurde der SyncML-Client
mithilfe des Emulators aus dem Wireless Toolkit getestet. Dieser bietet eine vollständige Implementation der PIM-API und erlaubt den Zugriff auf sämtliche Felder eines Adressbucheintrages des
Gerätes. Erste Tests auf dem Palm-Gerät ergaben ein völlig anderes Bild, kaum etwas funktionierte
wie vorgesehen. Die Ursache hierfür liegt in einer sehr offenen Spezifikation der PIM-API. Zusätzlich
lässt die Dokumentation der PIM-API für den Palm wichtige Detailfragen offen, sodass langwierige
Tests nötig waren, um die Ursache der Probleme zu lokalisieren. In der Dokumentation einer anderen Implementationen dieser API werden die Restriktionen zumindest klar erläutert: Since the PIM
”
API leaves room for important variations among different manufacturers, it is important to be aware
of certain implementation details for Nokia devices.“ [pim]
Je größer der Spielraum für die Gerätehersteller bei der Implementierung einer Spezifikation ist, desto wahrscheinlicher werden Inkompatibilitäten zwischen den einzelnen Geräten. Das für die Synchronisation essentielle Revision-Feld, in dem das Datum der letzten Änderung eines Adressbucheintrages festgehalten wird, ist in der Spezifikation der PIM-API als optional ausgewiesen. Zur Zeit sind
zwei Implementationen der PIM-API verfügbar, bei beiden kann nicht auf das Revision-Feld zugegriffen werden. Die Entwicklung von Anwendungen zur Synchronisation dieser Daten ist somit kaum
möglich.
Anhand der PIM-API ließ sich auch ein weiteres Problem gut nachvollziehen: Die Veröffentlichung
von fehlerhaften Implementierungen durch die Hersteller. Dabei spielt der Zeitdruck bei der Entwicklung der Geräte eine große Rolle. Die PIM-API wurde beispielsweise im Juli 2004 endgültig
spezifiziert, die erste Implementierung von IBM im März 2005 für den Palm Treo veröffentlicht. Die
Methode zum Import von Adressbucheinträgen im vCard-Format weist Fehler auf, die eindeutig der
Implementierung der API zuzuschreiben sind. Obwohl die zu importierenden vCards der Spezifikation genau entsprachen, wurde der Import abgebrochen und eine Exception geworfen, die auf einen
Fehler innerhalb der API deutet. Eine Möglichkeit, fehlerhafte Implementierungen durch eine verbesserte Version zu ersetzen besteht im Rahmen der CLDC-Plattform bislang nicht.
5.1.4 Aus den Restriktionen der CLDC resultierende Probleme
Anwendungen für die CLDC werden innerhalb einer sehr restriktiven Umgebung ausgeführt. Dies
ist zunächst einmal positiv zu bewerten, weil dadurch eine sichere Ausführung von Anwendungen
auf dem mobilen Gerät möglich wird (siehe Kapitel 2.4 zu Sicherheitsmaßnahmen in der J2ME). Problematisch sind allerdings Einschränkungen, welche die Möglichkeiten des Benutzers beschneiden.
58
Anhand signierter Anwendungen kann sichergestellt werden, dass diese aus vertrauenswürdigen
Quellen stammen. Wenn aber allein das Gerät, ohne jegliche Interaktionsmöglichkeit seitens des Benutzers, über die Vertrauenswürdigkeit einer Quelle entscheidet, ist damit zugleich auch sichergestellt, dass der Entwickler einer signierten Anwendung seine Vertrauenswürdigkeit durch die Zahlung einer Gebühr an eine offizielle Certificate Authority unter Beweis gestellt hat. Der Preis für eine
von offizieller Stelle signierte Anwendung liegt bei einigen hundert US-Dollar im Jahr [ver].
Hat ein Entwickler seine Anwendung mittels eines sogenannten Self-Signed Certificate selber signiert,
liegt die Verantwortung beim Benutzer: Er muss sicherstellen, diese Anwendung von einer Quelle
zu beziehen, der er vertrauen kann – beispielsweise von der offiziellen Webseite des Entwicklers.
Im Rahmen der J2ME werden Self-Signed Certificates allerdings grundsätzlich abgelehnt, ohne dass
der Benutzer dies ändern könnte. Akzeptiert werden nur von offizieller Stelle signierte Anwendungen. Selbst erstellte Anwendungen können also nur unsigniert zur Verfügung gestellt werden und
laufen dann im Sicherheitskontext untrusted. In diesem Kontext ist eine dauerhafte Vergabe von Berechtigungen nicht möglich. Wenn eine Anwendung beispielsweise den Zugriff auf die Netzverbindung des Gerätes benötigt, muss der Benutzer dem bei jedem Start der Anwendung zustimmen.
Bei der Entwicklung des SyncML-Prototypen gestaltete sich die Fehlersuche auf dem Palm aus diesem Grund etwas langwieriger: Bei jedem Start der Anwendung mussten zunächst drei Anfragen
nach diversen Berechtigungen (PIM.READ, PIM.WRITE, CONNECTION.HTTP) beantwortet werden.
Einem zahlenden Kunden ist dies sicherlich nicht zuzumuten – für den Entwickler wird die kostspielige Zertifizierung durch eine offizielle Certificate Authority unumgänglich.
Der Umfang an Restriktionen, die den Benutzern der J2ME auferlegt werden, könnte ein entscheidender Faktor für den weiteren Erfolg der Plattform sein. Automatische Updates der Geräte durch
Hersteller oder Mobilfunkbetreiber dürften nicht nur dem Einsatz solcher Geräte im Unternehmenskontext entgegenstehen – auch viele private Nutzer könnte dies verärgern. Auf den DesktopComputern und auch im Bereich der Smartphones und PDAs sind die Benutzer weitreichende Freiheiten in der Verwendung der Geräte gewohnt, umfangreiche Restriktionen könnten für die Hersteller schwer zu vermitteln werden. Die bisherigen Erfahrungen im Bereich des Brandings [c’t05a] von
Geräten durch die Mobilfunkanbieter lassen hinsichtlich dieser Problematik zumindest eine gewisse
Aufmerksamkeit seitens der Benutzer erkennen. Beispielsweise konnte ein Käufer eines Mobiltelefons, bei dem der Mobilfunkanbieter unerwünschte Funktionen des Gerätes durch eine Anpassung der Firmware deaktiviert hatte, vor Gericht eine Rückerstattung des Kaufpreises durchsetzen
[c’t05d].
5.1.5 Fragmentation der CLDC-Plattform
Die CLDC ist als einheitliche, plattformübergreifende Basis für die Entwicklung mobiler Anwendungen gedacht. Diese Einheitlichkeit führt jedoch dazu, dass neue Funktionalitäten nur sehr langsam in
die Profile der CLDC integriert werden. Aus diesem Grund wurde die Möglichkeit geschaffen, optionale Pakete für die CLDC zu spezifizieren, die vergleichsweise schneller entworfen und umgesetzt
werden können. Allerdings verringert sich die Einheitlichkeit der Plattform, je mehr Anwendungen
optionale Pakete voraussetzen.
59
Obwohl die CLDC-Plattform seit Ende 1999 existiert und seitdem ständig weiterentwickelt wird,
fehlte lange Zeit die für professionelle Anwendungen nötige Funktionalität. Anfangs wurden auf Basis der CLDC in erster Linie kleine Spiele entwickelt. Erst seit der Ende 2002 veröffentlichten Version
2.0 des MIDPs stehen ausreichende Möglichkeiten zur Verfügung, auch komplexere Anwendungen
zu realisieren.
Die Entwicklung von CLDC und MIDP muss dabei im Kontext der Fähigkeiten der mobilen Geräte
gesehen werden: Obwohl die Produktlebenszyklen auf dem Markt für mobile Geräte sehr kurz sind,
vergingen nach der endgültigen Festlegung der Spezifikationen der Version 2.0 des MIDPs noch
einige Monate, bis dieses Profil bei den Geräteherstellern allgemeine Verwendung fand. Ungefähr
seit Mitte des Jahres 2004 wird ein Großteil der neuen Mobiltelefone und Smartphones mit Unterstützung des MIDPs in Version 2.0 ausgeliefert. Zwischen der Verabschiedung des neuen Profils,
und einer allgemeinen Verfügbarkeit auf einer Mehrzahl der im Einsatz befindlichen mobilen Geräte
liegen also mindestens 2 Jahre, auch bei Annahme eines häufigen Wechsels der Gerätemodelle seitens der Benutzer.
Die Arbeitsgruppe zur Weiterentwickelung des MIDPs plant die Verabschiedung der endgültigen
Spezifikationen des Profils in Version 3.0 für Mitte 2006. Geplant ist unter anderem die Realisierung einiger Funktionen, deren Fehlen momentan die Ursache für die beginnende Fragmentation
der CLDC-Plattform ist: Die Möglichkeit, optionale Pakete nachträglich zu installieren, sowie eine Unterstützung für Bibliotheken, die von mehreren Anwendungen gemeinsam genutzt werden
können (shared libraries).
Anhand der Erfahrungswerte bei der Einführung des MIDP 2.0 kann mit einer größeren Verbreitung
von Geräten mit dem MIDP in Version 3.0 jedoch frühestens gegen Ende des Jahres 2007 gerechnet
werden – die heutige Version des MIDPs wird also in den nächsten zwei bis drei Jahren Basis der
Anwendungsentwicklung bleiben. Während dieser Zeit wird zur CLDC-Plattform neue Funktionalität nur über weitere optionale Pakete hinzukommen können. Die sich abzeichnende Fragmentation
der Plattform wird mittelfristig also sehr wahrscheinlich zunehmen.
Ein möglicher Ausweg aus der Problematik könnte in der Spezifizierung eines weiteren Metapackages, ähnlich dem Java Technology for the Wireless Industry liegen (siehe Kapitel 2.3). Auf diese Weise könnte neben einer durch optionale Pakete erweiterten Basisplattform auch eine Erhöhung des
Größenlimits der Anwendungen festgeschrieben werden. Viele der heute verfügbaren Geräte wären
dafür sicherlich leistungsfähig genug.
5.1.6 Konsequenzen für die Datensynchronisation mobiler Anwendungen
Bei der Entwicklung mobiler Anwendungen auf Basis der CLDC muss zunächst entschieden werden, ob der Einsatz optionaler Pakete mit den damit verbundenen erhöhten Anforderungen an die
Geräte unumgänglich ist. Mit der Verwendung komplexerer Verfahren zur Datensynchronisation
wird in den meisten Fällen die Nutzung eines optionalen Paketes notwendig, damit der beschränkte
Speicherplatz auf dem Gerät vollständig für den Code der Anwendung genutzt werden kann. Das
Webservice-API bietet neben Methoden zur Nutzung von Webservices auch einen XML-Parser, sodass
dieses Paket eine gute Grundlage für standardisierte Verfahren zur Datensynchronisation darstellt.
5.2 D IE ZUK ÜNFTIGE E NTWICKLUNG DER CDC
60
Der Einsatz komplexerer Verfahren zur Datensynchronisation über eine Bluetooth-Verbindung scheitert leider an der fehlenden Unterstützung des OBEX-Protokolls. Nur in Ausnahmefällen dürfte die
Verwendung der zusätzlichen OBEX-Bibliothek noch genug Speicherplatz für die Anwendung lassen. Ebenso schwierig gestaltet sich die Interaktion mit den nativen Adress- und Termindatenbanken
eines Gerätes über das optionale PIM-Paket. Eine einfache Personalisierung von Anwendungen ist
damit möglich, eine weitergehende Synchronisation der Daten jedoch kaum zu realisieren.
Der große Vorteil der CLDC-Plattform bleibt jedoch die weite Verbreitung auf den unterschiedlichsten Geräten. Wenn dieser genutzt werden soll, müssen bei der Entwicklung einige Kompromisse
eingegangen werden. Solange sich die Komplexität der verwendeten Verfahren zur Datensynchronisation an den beschränkten Möglichkeiten der Geräte orientiert, sind auch umfangreichere Anwendungen möglich. Sinnvoll ist in diesem Zusammenhang die Verwendung eines dezidierten ProxyServers, mit dessen Hilfe Daten speziell für die mobile Anwendung aufbereitet werden können.
Auch die direkte Kommunikation zwischen mehreren mobilen Anwendungen über eine BluetoothVerbindung lässt sich unter Berücksichtigung der Limitationen der Plattform sinnvoll nutzen.
5.2 Die zukünftige Entwicklung der CDC
Wie bereits in den Überlegungen zur Evaluation geschildert, sind Geräte mit einer Unterstützung
für die Profile der CDC momentan kaum verfügbar. Um die Möglichkeiten der Entwicklung mit der
CDC abzuschätzen, bietet es sich daher an einen Blick in die Zukunft zu werfen.
Wegen der großen Verbreitung des MIDPs konzentrierte sich die Weiterentwicklung der J2MEPlattform in den Jahren 2001 bis 2004 auf die CLDC, die Entwicklung der CDC stagnierte hingegen. Erst gegen Ende 2004 wurde die Weiterentwicklung merklich beschleunigt, mit dem Ziel einer
vollständigen Kompatibilität zur API der Java Standard Edition in Version 1.4, inklusive des SwingFrameworks für die Gestaltung graphischer Oberflächen. Die endgültigen Spezifikationen wurden
im August 2005 verabschiedet (JSR 216 bis 219).
Die neue Version dürfte die Attraktivität der Plattform durch eine stark vereinfachte Migration
von Anwendungen der J2SE auf mobile Geräte erhöhen. Zudem könnten die oben angesprochenen
Probleme bei der Weiterentwicklung der CLDC-Plattform dazu führen, dass die Hersteller mobiler Geräte verstärkt auf die CDC setzen werden. Für die weit verbreitete, herstellerübergreifende
Symbian-Plattform ist eine zukünftige Unterstützung der CDC bereits angekündigt worden [c’t05c].
Möglicherweise wird das ursprüngliche Konzept der J2ME-Plattform auf diese Weise doch noch
realisiert: Die CLDC findet Verwendung in Mobiltelefonen, während die leistungsfähigeren Smartphones die CDC nutzen.
Fraglich bleibt jedoch, ob sich eine breitere Unterstützung der CDC auch bei den PDAs und PocketPCs durchsetzen wird. Warum auf der leistungsfähigen Palm-Plattform im Moment nur die CLDC
unterstützt wird, ist kaum verständlich. Die mangelnde Verfügbarkeit der CDC auf den PocketPCs, lässt sich hingegen anhand des angespannten Verhältnisses zwischen Sun und Microsoft, dem
Hersteller des Windows Mobile-Betriebssystems der PocketPCs erklären. Ob PDAs und Smartphones
5.3 FAZIT UND AUSBLICK
61
auf Linux-Basis in Zukunft weitere Verbreitung finden bleibt abzuwarten – eine Fortführung der
Unterstützung der CDC-Plattform auf diesen Geräten ist jedoch wahrscheinlich.
5.3 Fazit und Ausblick
Eine Entwicklung komplexerer Anwendungen auf Basis der J2ME ist zum heutigen Zeitpunkt kaum
zu empfehlen: Geräte mit Unterstützung der Profile der CLDC sind weit verbreitet, die Plattform
zeichnet sich allerdings durch umfangreiche Limitationen aus. Die Möglichkeiten diese zu verringern führen zu einer drastischen Verringerung des Umfangs verfügbarer Geräte. Die CDC steht
dagegen grundsätzlich nur auf sehr wenigen Geräten zur Verfügung. Einzig im Kontext von Unternehmen oder anderen größeren Organisationen erscheint ein Einsatz komplexer Anwendungen
auf Basis der J2ME sinnvoll, wenn zusammen mit der Anwendung auch geeignete Geräte angeschafft werden. Speziell für diese Einsatzgebiete sind auch Komplettlösungen wie das WebSphere
Studio Device Developer gedacht. IBM verspricht eine möglichst reibungslose Integration mobiler Anwendungen in bestehende, auf IBM-Lösungen basierende Informationssysteme und versucht dieses
Versprechen durch eine eigene virtuelle Maschine für ausgewählte mobile Geräte zu realisieren.
Angesichts der Einschränkungen der J2ME-Plattform sollte zur Zeit auch die Entwicklung nativer
Anwendungen in Betracht gezogen werden. Sowohl PalmOS, SymbianOS als auch Windows Mobile
dürften jeweils auf einer größeren Anzahl an Geräten verfügbar sein, als die CDC, oder die CLDC
in Verbindung mit bestimmten optionalen Paketen. Selbst PersonalJava findet aufgrund einer weiten Verbreitung noch rege Verwendung, obwohl diese Plattform von Sun schon lange nicht mehr
weiterentwickelt wird.
Für die Entwicklung mit der J2ME bleibt zunächst nur der Blick in die Zukunft. Dabei ergibt sich ein
durchaus positives Bild, denn für viele der angesprochenen Kritikpunkte werden zur Zeit adäquate
Lösungsansätze diskutiert und entwickelt. Die nachträgliche Installation von optionalen Paketen
und shared libraries soll das in JSR-232 entwickelte Mobile Operational Management ermöglichen.
Für Updates vorhandener Profile und Konfigurationen, beispielsweise zur Beseitigung von Sicherheitslücken und fehlerhaften Implementationen, wird die Mobile Service Architekture (JSR 248 und
249) entwickelt. Eine Schnittstelle für die Datensynchronisation mittels SyncML soll das Data Sync
API (JSR-230) schaffen, eine allgemeine Unterstützung von XML auf der J2ME-Plattform durch ein
XML-API realisiert werden (JSR-280).
Die Entwicklung dieser Pakete im Java Community Process befindet sich jedoch großenteils noch in der
Anfangsphase. Erst mit der Fertigstellung der nächsten Version des MIDPs (JSR-271) kann mit einer
umfassenden Erneuerung der CLDC-Plattform gerechnet werden. Die dabei geplanten Änderungen
sind sehr ambitioniert und könnten zu einer vollwertigen Plattform auf Basis des MIDPs führen:
Eine simultane Ausführung mehrerer Anwendungen mit der Möglichkeit der Kommunikation zwischen diesen, im Hintergrund ablaufende Anwendungen, gemeinsam genutzte Bibliotheken und die
nachträgliche Installation von Paketen würden die aktuellen Limitationen der Plattform Vergangenheit werden lassen.
5.3 FAZIT UND AUSBLICK
62
Angesichts des Umfangs der geplanten Änderungen steht allerdings zu befürchten, das einzelne Ziele wieder aufgegeben werden müssen, oder der Zeitplan zur Realisierung nicht eingehalten werden
kann. An der Zeitspanne, in der diese Weiterentwicklungen zu Marktreife gebracht werden, wird
sich auch zeigen, ob die Zusammenarbeit der beteiligten Unternehmen im Java Community Process
effektiv funktioniert.
Es bleibt in jedem Fall lohnenswert die weitere Entwicklung der J2ME im Auge zu behalten, denn
eine leistungsfähige und flexible Basis zur plattformübergreifenden Entwicklung mobiler Anwendungen könnte in Zukunft entstehen.
Literaturverzeichnis
Ant A NTENNA P ROJECT:
An Ant-to-End Solution For Wireless Java.
http://antenna.
sourceforge.net/. – Online–Ressource, Abruf: 22. 05. 2005
avea AVETANA G MB H:
AvetanaBluetooth, a Java/JNI-Implementation of JSR-82 for Linux and
J2SE. http://sourceforge.net/projects/avetanabt/. – Online–Ressource, Abruf: 22. 05. 2005
aveb AVETANA G MB H: AvetanaOBEX, an OBEX implementation for J2ME phones supporting JSR82. http://sourceforge.net/projects/avetanaobex. – Online–Ressource, Abruf: 22. 05. 2005
Axi T HE A PACHE S OFTWARE F OUNDATION: Webservices Project - Axis. http://ws.apache.
org/axis/. – Online–Ressource, Abruf: 22. 05. 2005
Ber B ERKA, Stan: JAVA for PocketPC PDA’s. http://www.berka.name/stan/jvm-ppc/
java_for_pda.html. – Online–Ressource, Abruf: 08. 08. 2005
Blu B EN H UI: J2ME application development resources for Bluetooth technology. http://benhui.
net/modules.php?name=Bluetooth&page=bluelet.html. –
Online–Ressource,
Abruf: 22. 05. 2005
c’t04a H EISE O NLINE: Java-Sicherheit auf Handys ausgehebelt. Version: 19.Oktober 2004. http://
www.heise.de/newsticker/meldung/52321. – Online–Ressource, Abruf: 22. 06. 2005
c’t04b H EISE O NLINE: Nokia wird Download-Händler. Version: 25.Oktober 2004. http://www.
heise.de/newsticker/meldung/52477. – Online–Ressource, Abruf: 22. 06. 2005
c’t04c H EISE O NLINE: Schwere Sicherheitslücken bei Bluetooth-Handys. Version: 29.Dezember 2004.
http://www.heise.de/newsticker/meldung/54659. – Online–Ressource, Abruf:
22. 06. 2005
c’t05a H EISE O NLINE:
Branding Extreme: T-Mobile bringt UMTS-Handy ohne Bluetooth-
Datendienste. Version: 13.Mai 2005. http://www.heise.de/newsticker/meldung/
59530. – Online–Ressource, Abruf: 23. 07. 2005
c’t05b H EISE O NLINE:
JavaOne 2005: Java für Handys wird ausgebaut.
Version: 27.Juni 2005.
http://www.heise.de/newsticker/meldung/61069. – Online–Ressource, Abruf:
27. 06. 2005
LITERATURVERZEICHNIS
64
c’t05c H EISE O NLINE:
Handys.
JavaOne 2005: Nokia setzt auf die Fernkonfiguration von Series-60-
Version: 27.Juni 2005.
http://www.heise.de/newsticker/meldung/
61114. – Online–Ressource, Abruf: 27. 06. 2005
c’t05d H EISE O NLINE: Urteil gegen Handy-Branding.
Version: 13.März 2005. http://www.
heise.de/newsticker/meldung/57462. – Online–Ressource, Abruf: 23. 07. 2005
Ecla E CLIPSE F OUNDATION:
Eclipse Platform.
http://www.eclipse.org/. –
Online–
Ressource, Abruf: 22. 05. 2005
Eclb E CLIPSE ME P ROJECT: EclipseME Plugin Homepage. http://www.eclipseme.org/. –
Online–Ressource, Abruf: 22. 05. 2005
enc M ANES, Anne T.: Document vs. RPC style. http://searchwebservices.techtarget.
com/ateQuestionNResponse/0,289625,s%id26_cid494324_tax289201,00.
html. – Online–Ressource, Abruf: 08. 08. 2005
GCH04 G MELIN, Moritz ; C AMPANA, Julien ; H ARBAUM, Till: Bluetooth-Programmierung mit Java
auf dem Desktop. In: c’t 22 (2004)
Gig G IGUERE, Eric ; S UN D EVELOPER N ETWORK:
Profiles.
Object Serialization in CLDC-Based
http://developers.sun.com/techtopics/mobility/midp/ttips/
serialization/%. – Online–Ressource, Abruf: 22. 05. 2005
Gme05 G MELIN, Moritz: Bluetooth-Handys: OBEX-Anwendungen mit Java entwickeln. In: c’t 8
(2005)
HMPT02 H ANSMANN, Uwe ; M ETTALA, Riku ; P URAKAYASTHA, Apratim ; T HOMPSON, Peter:
SyncML: Synchronizing and Managing Your Mobile Data. Pearson Education, 2002. – ISBN
0130093696
HZ05 H EIN, Manfred ; Z ELLER, Henner: Java WebServices. Addison-Wesley, 2005. – ISBN
3827322316
J9 I NC ., IBM:
WebSphere Everyplace Micro Environment.
http://www-306.ibm.com/
software/wireless/weme/. – Online–Ressource, Abruf: 08. 08. 2005
JAXa S UN M ICROSYSTEMS , I NC .: Java API for XML-Based RPC (JAX-RPC. http://java.sun.
com/xml/jaxrpc/. – Online–Ressource, Abruf: 08. 07. 2005
JAXb S UN M ICROSYSTEMS , I NC .: Java API for XML Processing (JAXP). http://java.sun.
com/xml/jaxp/. – Online–Ressource, Abruf: 08. 07. 2005
Jbe I NC ., Esmertec:
Jbed CDC.
http://www.esmertec.com/solutions/mobile_
multimedia/jbed_cdc/. – Online–Ressource, Abruf: 08. 08. 2005
JCPa J AVA C OMMUNITY P ROCESS: Java Community Process Program Overview. http://jcp.
org/en/introduction/overview. – Online–Ressource, Abruf: 07. 06. 2005
JCPb J AVA C OMMUNITY P ROCESS:
JCP 2: Process Document.
http://www.jcp.org/en/
procedures/jcp2. – Online–Ressource, Abruf: 07. 06. 2005
65
JSRa J AVA C OMMUNITY P ROCESS: Java Specification Requests for J2ME. http://jcp.org/en/
jsr/ec?listBy=2. – Online–Ressource, Abruf: 07. 06. 2005
JSRb J AVA C OMMUNITY P ROCESS: JSR 271: Mobile Information Device Profile 3. http://www.
jcp.org/en/jsr/detail?id=271. – Online–Ressource, Abruf: 21. 08. 2005
JXM P ROJECT JXTA:
JXTA-J2ME (JXME) Platform Project.
http://jxme.jxta.org/. –
JXT P ROJECT JXTA: Project JXTA Homepage. http://www.jxta.org/. – Online–Ressource,
Abruf: 08. 07. 2005
Knu03 K NUDSEN, Jonathan: Wireless Java: Developing with J2ME, Second Edition. Springer Verlag,
2003. – ISBN 1-59059-077-5
kOb K O BJECTS . ORG: Utility classes for J2ME. http://kobjects.sourceforge.net/. –
McL02 M C L AUGHLIN, Brett: Java & XML. O’Reilly, 2002. – ISBN 389721296X
Mir T HE A PACHE S OFTWARE F OUNDATION: Webservices Project - Mirae. http://ws.apache.
org/mirae/index.html. – Online–Ressource, Abruf: 22. 05. 2005
MK03 M ICHAEL K ROLL, Stefan H.: J2ME Developer’s Guide. Pearson Education, 2003. – ISBN
3-8272-6509-6
mul M ULTISYNC P ROJECT: Opensync. http://www.opensync.org/. – Online–Ressource,
Abruf: 22. 07. 2005
Nek T HE A PACHE S OFTWARE F OUNDATION: CyberNeko HTML Parser. http://people.
apache.org/˜andyc/neko/doc/html/index.html. –
Online–Ressource, Abruf:
22. 05. 2005
Ngh02 N GHIEM, Alex: IT Web Services: A Roadmap for the Enterprise. Prentice Hall, 2002. – ISBN
0130097195
OAS OASIS: Organization for the Advancement of Structured Information Standards. http://www.
oasis-open.org/. – Online–Ressource, Abruf: 07. 07. 2005
OMA O PEN M OBILE A LLIANCE:
Open Mobile Alliance - Data Synchronisation Working
Group. http://www.openmobilealliance.org/syncml. – Online–Ressource, Abruf:
07. 07. 2005
pim N OKIA, Forum: Introduction To The PIM API. http://www.forum.nokia.com/main/
0,,1_0_15,00.html. – Online–Ressource, Abruf: 08. 08. 2005
Pro P RO G UARD P ROJECT:
Proguard Java obfuscation tools.
http://proguard.
sourceforge.net/. – Online–Ressource, Abruf: 22. 05. 2005
RMI S UN M ICROSYSTEMS , I NC .: Java Remote Method Invocation. http://java.sun.com/
products/jdk/rmi/. – Online–Ressource, Abruf: 10. 06. 2005
66
RS03 R UPP, Stephan ; S IEGMUND, Gerd: Java in der Telekommunikation. Grundlagen, Konzepte,
Anwendungen. Dpunkt Verlag, 2003. – ISBN 3898642445
Sch04 S CHMATZ, Klaus-Dieter: J2ME: Entwicklung mobiler Anwendungen mit CLDC und MIDP.
dpunkt.verlag, 2004. – ISBN 3-89864-271-2
SIG B LUETOOTH S PECIAL I NTEREST G ROUP:
The Official Bluetooth Site.
http://www.
bluetooth.org. – Online–Ressource, Abruf: 22. 05. 2005
SOA T HE W ORLD W IDE W EB C ONSORTIUM (W3C): The Simple Object Access Protocol. http:
//www.w3.org/TR/soap12-part0/. – Online–Ressource, Abruf: 22. 05. 2005
SUNa S UN M ICROSYSTEMS , I NC .: EmbeddedJava Platform. http://java.sun.com/products/
embeddedjava/. – Online–Ressource, Abruf: 06. 06. 2005
SUNb S UN M ICROSYSTEMS , I NC .: J2ME Personal Profile for Zaurus. http://java.sun.com/
developer/earlyAccess/pp4zaurus/. – Online–Ressource, Abruf: 06. 08. 2005
SUNc S UN M ICROSYSTEMS , I NC .: J2ME Wireless Toolkit. http://java.sun.com/products/
sjwtoolkit/. – Online–Ressource, Abruf: 06. 06. 2005
SUNd S UN M ICROSYSTEMS , I NC .: PersonalJava Platform. http://java.sun.com/products/
personaljava/. – Online–Ressource, Abruf: 06. 06. 2005
SUN99 S UN M ICROSYSTEMS , I NC .:
Press Release: SUN outlines three Editions of JAVA2 Plat-
form. Version: 15.Juni 1999. http://www.sun.com/smi/Press/sunflash/1999-06/
sunflash.990615.15.html. – Online–Ressource, Abruf: 05. 06. 2005
Sym LTD, Symbian: SymbianOS - mobile operating system. http://www.symbian.com/. –
Syn F UNAMBOL . COM: Sync4j - Java SyncML Client and Server. http://sync4j.funambol.
com/. – Online–Ressource, Abruf: 22. 05. 2005
Tom T HE A PACHE S OFTWARE F OUNDATION: Tomcat Servlet Container. http://jakarta.
apache.org/tomcat/. – Online–Ressource, Abruf: 22. 05. 2005
Top02 T OPLEY, Kim: J2ME in a nutshell. O’Reilly, 2002. – ISBN 0-596-00253-X
vCa IMC, Internet Mail C.: Personal Data Interchange. http://www.imc.org/pdi/. – Online–
ver (UTI), Unified Testing I.: Java Verified Program. http://www.javaverified.com/
index.jsp. – Online–Ressource, Abruf: 08. 08. 2005
W3Ca T HE W ORLD W IDE W EB C ONSORTIUM (W3C): Web Services Activity. http://www.w3.
org/2002/ws/. – Online–Ressource, Abruf: 07. 07. 2005
W3Cb T HE W ORLD W IDE W EB C ONSORTIUM (W3C): Web Services Architecture Usage Scenarios. http://www.w3.org/TR/ws-arch-scenarios/. – Online–Ressource, Abruf:
07. 07. 2005
67
W3Cc T HE W ORLD W IDE W EB C ONSORTIUM (W3C): Web Services Description Language (WSDL)
Version 2.0. http://www.w3.org/TR/wsdl20-primer/. – Online–Ressource, Abruf:
07. 07. 2005
WAP WAP
F ORUM:
The
Wireless
Application
Protocol
Forum.
http://www.
openmobilealliance.org/tech/affiliates/wap/wapindex.html. –
Online–
WBFT04 WANG, Dapeng ; B AYER, Thomas ; F ROTSCHER, Thilo ; T EUFEL, Marc ; WANG, Dapeng:
Java Web Services mit Apache Axis. Javamagazin, 2004. – ISBN 3935042574
WBX WAP
F ORUM:
Binary XML Content Format Specification.
http://www.
openmobilealliance.org/tech/affiliates/wap/wap-192-wbxml-200%
10725-a.pdf. – Online–Ressource, Abruf: 05. 07. 2005
WSP WAP
F ORUM:
Wireless
Session
Protocol
Specification.
http://www.
openmobilealliance.org/tech/affiliates/wap/wap-230-wsp-20010%
WTL WAP F ORUM:
Wireless Transport Layer Security Specification.
http://www.
openmobilealliance.org/tech/affiliates/wap/wap-261-wtls-2001%
Xer T HE A PACHE S OFTWARE F OUNDATION: Xerces XML Parser. http://xml.apache.org/
xerces2-j. – Online–Ressource, Abruf: 22. 05. 2005

Synchronisation mobiler Anwendungen auf Basis der Java 2 Micro

Transcrição

Documentos relacionados

Antrag auf steuerliche Unbedenklichkeitsbescheinigung

Anbieterkatalog Seite 1 von 1 Stammdaten Anbietername

Zeittafel - Wald

väterberatung gera

Schulanmeldung - Freie Gemeinschaftsschule der Grundig

UNIX Netzwerk

Casting für Massachusetts - Das Bee Gees Musical

Der GOLDENE SPATZ 2015: Das

Der Geraer Verkehrsbetrieb GmbH i. IN

13. Repetitorium der klinischen Sonographie in Gera