OBEX Object Passing Home (PDF)





OBEX Object Passing
�ber Bluetooth





















Hochschule Furtwangen ⋅ 31. M�rz 2006

Wintersemester 2005/2006
Jens Frey ⋅ jens.frey@coffeecrew.org
 Matrikelnummer ⋅ 216401
Fakult�t ⋅ Informatik
 Studiengang ⋅ Computer Networking


Diplomarbeit

Referent ⋅ Prof. Dr. Harald Gl�ser
Koreferent ⋅ Prof. Dr. Wolfgang Bauer




Eidesstattliche Erkl�rung
Ich erkl�re hiermit an Eides statt, dass ich die vorliegende Diplomarbeit selbstst�ndig und ohne unzul�ssige fremde Hilfe angefertigt habe. Die verwendeten Quellen und Hilfsmittel sind vollst�ndig zitiert.
Furtwangen, 31. M�rz 2006







Jens Frey



Abstrakt

Die vorliegende Arbeit beschreibt das Design sowie die Implementierung des OBEX Object Passing (OOP) Mechanismus, welcher dazu entwickelt wurde um Java Objekte �ber eine Bluetooth Funkstrecke von einem Bluetooth und Java f�higen Endger�t auf ein zweites zu �bertragen.
Die Informationen der vorliegenden Arbeit werden ohne R�cksicht auf einen eventuellen Patentschutz publiziert. Die wiedergegebenen Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. k�nnen auch ohne besondere Kennzeichnung Marken sein und unterliegen als solche den gesetzlichen Bestimmungen.

Inhaltsverzeichnis



Kapitel 1  Einleitung

Die Bluetooth Technologie erfreut sich in letzter Zeit immer gr�sserer Beliebtheit, wird doch durch sie das l�stige Kabel endlich obsolet. Im Bereich der Applikationsentwicklung fehlt dem Programmierer jedoch die M�glichkeit Java Objekte zwischen zwei Endger�ten auszutauschen. Diese L�cke wird durch die vorliegende Arbeit geschlossen.

1.1  Aufbau der Arbeit

Die Arbeit ist wie folgt aufgeteilt:
Kapitel 1
beschreibt die Zielsetzung, technische Randbedingungen, sowie denkbare Anwendungsszenarien, und Bezugsquellen der vorliegenden Arbeit.
Kapitel 2
gibt einen kurzen �berblick �ber die zur Realisierung der Bibliothek eingesetzten Technologien.
Kapitel 3
beschreibt das Design der entwickelten Bibliothek, sowie deren Funktionsweise.
Kapitel 4
beschreibt den konkreten Einsatz der Bibliothek anhand eines einfachen Beispiels, und vermittelt die Grundlagen der J2ME Applikationsentwicklung.
Kapitel 5
fasst die Arbeit zusammen und gibt einen Ausblick auf Weiterentwicklungsm�glichkeiten der Bibliothek.
Anhang A
demonstriert, wie innerhalb der eingesetzten Netbeans IDE ein J2ME Projekt erstellt werden kann, das die entwickelte Bibliothek einsetzt. Ferner wird beschrieben wie die Beispielapplikation in Betrieb genommen werden kann.

1.2  Zielsetzung der Arbeit

Ziel der Arbeit ist es eine Bibliothek zu erstellen, mit deren Hilfe sich Java Objekte �ber ein Bluetooth Funknetzwerk �bertragen lassen. Ein solcher Mechanismus findet Anwendung, wenn man gezwungen ist, Objekte �ber ein Netzwerk transportieren zu m�ssen, wie es in gr�sseren Implementierungen der Fall ist. Dies ist bspw. dann notwendig, wenn Daten aus einer Datenbank an ein bestimmes Endger�t oder einen Serverprozess auf einer physisch differenten Maschine zu senden sind.

Die Anwendungsentwicklung – im Bereich der Daten�bertragung – wird mit der entwickelten Bibliothek merklich vereinfacht. Der Programmierer wird lediglich angehalten, in seinen Entit�tsobjekten eine vorgegebene Schnittstelle zu implementieren. Sofern die Schnittstelle implementiert wurde, ist die Bibliothek in der Lage, das gegebene Objekt selbstst�ndig zu �bertragen.

Diese Arbeit bildet keinen Serialisierungsmechanismus nach, auch wenn es auf Grund der Schnittstellendefinition danach aussehen mag. Die Implementierung der Serialisierung muss vom Programmierer selbst durchgef�hrt werden.

1.3  Anwendungsszenarien

Die Anwendungsszenarien der Bibliothek sind vielf�ltig. Sie kann prinzipiell bei jeder Art von Objektdaten�bertragung eingesetzt werden.

Eine konkrete Anwendung w�re bspw. eine Applikation, die mit einem K�hlschrank interagiert. Die Software des K�hlschranks verwaltet einen „Einkaufszettel“ mit Hilfe von Produktobjekten. Diese Objekte k�nnen mit Hilfe der Bibliothek leicht auf ein mobiles Endger�t �bertragen werden, das im Gesch�ft als „Einkaufszettel“ dient.

Eine andere Anwendungsm�glichkeit w�re z. B. die �bertragung von Punktobjekten, die von einer Landkartenapplikation ausgewertet werden.

1.4  Technische Randbedingungen

Der Einsatz von Bluetooth sowie der Java 2 Platform, Micro Edition waren technische Randbedingungen der Arbeit. Um eine maximale Transparenz und Kosteneffizienz zu erreichen, sind, zur Realisierung des Projekts, bestehende Technologien aus dem Open Source Bereich eingesetzt worden.

1.5  Bezugsquellen

Die vorliegende Arbeit, sowie deren zugeh�riger Quellcode kann unter der URL https://oop.coffeecrew.org/ bezogen werden.

An dieser Stelle soll speziell auf die verf�gbare JavaDoc hingewiesen werden, die direkt unter der URL https://oop.coffeecrew.org/doc/ erreicht werden kann. Sie ist zus�tzlich mit Beispielen versehen worden, um die Einarbeitungszeit des Entwicklers zu verk�rzen.

S�mtliche Beispielprogramme sind unter der angegebenen Adresse verf�gbar. Die Webseite ist zus�tzlich auf der beigelegten CD-ROM offline verf�gbar gemacht.

Kapitel 2  Technische Grundlagen

In diesem Kapitel werden die zur Umsetzung, bzw. zum Verst�ndnis der vorliegenden Arbeit, notwendigen Technologien bzw. Spezifikationen kurz angesprochen. Ist der Leser mit den folgenden Technologien bereits vertraut, kann dieses Kapitel problemlos �bersprungen werden. Die Technologien werden nicht in vollem Umfang diskutiert, lediglich der jeweils relevante Teil wird herausgegriffen und kurz zusammengefasst bzw. gegeneinander abgegrenzt. Ausgehend davon, dass die zuk�nftige Entwicklung im Bereich mobiler Endger�te nicht stagniert, wird speziell nur auf die zum Zeitpunkt der Drucklegung aktuelle Version der entsprechenden Spezifikation eingegangen. Die einzige Ausnahme stellt die Bluetooth-Spezifikation dar, die lediglich in der Version 1.2 vorgestellt wird, da die Mehrzahl der aktuell verf�gbaren Endger�te lediglich diese Version unterst�tzt. Die aktuelle Version (zum Zeitpunkt der Drucklegung v2.0) kann unter https://www.bluetooth.org/spec/ bezogen werden. Die �ltere Version 1.1 der Bluetooth-Spezifikation, auf die der JSR-82 aufsetzt, kann unter der selben URL angefordert werden.

Die angesprochenen Technologien und Spezifikationen umfassen dabei:

2.1  Bluetooth

Die im Folgenden beschriebenen Grundlagen beziehen sich auf die Bluetooth-Spezifikation in der Version 1.2. Die �nderungen im Vergleich zur Version 1.1 beziehen sich haupts�chlich auf die Reduktion der Interferenzen mit anderen Funktechnologien und sind deshalb minimal. Die Version 1.1 h�tte von der Bluetooth SIG speziell angefordert werden m�ssen, was somit vermieden werden konnte, da die Version 1.2 zum Zeitpunkt der Drucklegung ohne Registrierung verf�gbar war.

Die Bluetooth Funktechnologie ist ein Kurzstreckenfunkverfahren, das prim�r dazu entwickelt wurde mobile Endger�te kabellos zu verbinden. Das Bluetooth Grundsystem besteht aus Basisband, Sende-/Empfangseinheit und dem zugeh�rigen Protokollstapel1. Das Kurzstreckenfunkverfahren wird im weltweit lizenzfreien 2.4 GHz ISM2 Band betrieben. Um die Komplexit�t der Sende- und Empfangseinheit gering zu halten und somit die Kosten zu minimieren, wird als Modulationsverfahren dass Gaussian Frequency Shift Keying (GFSK)3 eingesetzt (Vgl. : [Blu03, Architecture, S. 13; PDF, S. 89]).

Die Reichweite des Bluetooth-Kurzstreckenfunks ist, wie bei jeder Funktechnologie, abh�ngig von der Sendeleistung des Ger�ts. Die Sendeleistung – und somit auch die Reichweite – des Funks wird in drei Klassen eingeteilt:
Klassifikation Reichweite Sendeleistung
Klasse 1 100 m 100 mW
Klasse 2 40 m 2.5 mW
Klasse 3 10 m 1 mW
Tabelle 2.1: Reichweiten der einzelnen Bluetooth Klassen (Vgl. : [Wik06b])
Die Daten�bertragungsraten sind abh�ngig von der Spezifikation bzw. der Bluetooth-Version des jeweiligen Produkts. Die �bertragungsrate hat sich w�hrend der ersten drei Versionen nicht gesteigert, sie wurde erst mit der Bluetooth-Spezifikation Version 2.0 erh�ht. Ein �berblick �ber die �bertragungsraten, sowie die grossen �nderungen/Probleme, der jeweilgen Bluetooth-Versionen ist in [Tab.: 2.2] dargestellt.
Bluetooth-Version Maximale Daten�bertragungsrate �nderung/Problem
1.0 und 1.0B 723.2 Kbit/s Enth�lt Sicherheitsprobleme
1.1 723.2 Kbit/s Indikator f�r die Signalst�rke hinzugef�gt Received Signal Strength Indicator (RSSI)
1.2 723.2 Kbit/s Adaptive Frequency-Hopping spread spectrum (AFH) eingef�hrt; reduziert Interferenzen mit anderen Funktechnologien (z. B. WLAN)
2.0 2.1 Mbit/s Etwa dreifache Daten�bertragungsgeschwindigkeit durch Enhanced Data Rate (EDR)
Tabelle 2.2: Daten�bertragungsraten von Bluetooth (Vgl. : [Wik06b, Versionen])
Der Datentransport innerhalb der Bluetooth-Architektur sowie s�mtliche Betriebsmodi folgen dem selben generischen Ansatz. Dieser generische Ansatz ist mit Hilfe einer Schichtenarchitektur realisiert, die in [Abb.: 2.1] dargestellt, und mit dem OSI-Schichtenmodell vergleichbar ist.
Abbildung 2.1: Allgemeine Datentransport Architektur von Bluetooth (Vgl. : [Blu03, Architecture, S.25; PDF, S. 101])

2.1.1  Physical Layer

Der Physical Layer bestimmt die Art und Weise wie die Daten �bertragen werden, bzw. wie die �bertragung der Daten stattzufinden hat. Er spezifiziert bspw. was notwendig ist um Kollisionen zu vermeiden, oder welches Verfahren verwendet wird um parallele Operationen zu unterst�tzen.

2.1.1.1  Physical Channel



Auf der untersten Ebene dieser Architektur befindet sich der Physical Channel. Er wird von zwei Bluetooth Ger�ten zur Kommunikation genutzt. Um miteinander kommunizieren zu k�nnen, m�ssen beide Sende- und Empfangseinheiten in Reichweite sein und auf die selbe Funkfrequenz eingestellt werden. Um unbeabsichtigte Kollisionen zu vermeiden wird der Kommunikation ein Zugriffscode angef�gt. Dies verhindert Kollisionen, w�rden mehrere Ger�te auf die selbe Frequenz eingestellt werden. In der Spezifikation sind vier physische Kan�le definiert, von denen jeder f�r einen bestimmten Anwendungszweck definiert und optimiert wurde. Um parallele Operationen zu unterst�tzen, wird das Time Division Multiplexing4 Verfahren verwendet. Durch diesen Mechanismus wird es erm�glicht, dass das Ger�t w�hrend einer bestehenden Kommunikation auffindbar und zug�nglich ist. Die Spezifikation nimmt weiterhin an, dass das Ger�t lediglich in der Lage ist, sich ausschliesslich mit einem �bertragungskanal zu verbinden (Vgl. : [Blu03, Architecture, S. 32; PDF, S. 108]).

2.1.1.2  Physical Links



Der Physical Link repr�sentiert die Basisbandverbindung5 zwischen den Endger�ten. Eine solche physische Verbindung ist immer mit genau einem physischen Kanal verkn�pft, obwohl ein physischer Kanal mehr als eine physische Verbindung unterst�tzen kann. Die physische Verbindung ist innerhalb eines Bluetooth-Systems lediglich ein virtuelles Konzept. Innerhalb eines Bluetooth-Pakets existiert kein Feld, welches es erm�glichen w�rde die physische Verbindung direkt zu identifizieren. Die physische Verbindung kann stattdessen �ber den logischen Transportkanal6 identifiziert werden. Physische Verbindungen haben �blicherweise gemeinsame Eigenschaften, die auf alle logischen Transportkan�le – die zu dieser Verbindung geh�ren – angewandt werden. Beispiele solcher Eigenschaften sind die Verschl�sselung und Leistungssteuerung (Power Control) des Ger�ts. Soll eine �bertragung �ber mehrere physische Verbindungen hinweg ausgel�st werden (Broadcast), werden die Sendeparameter entsprechend angepasst, sodass auf allen physischen Verbindungen gesendet werden kann (Vgl. : [Blu03, Architecture, S. 37; PDF: S. 113]).

2.1.2  Logical Layer

Der Logical Layer definiert, wie die logischen Transportverbindungen physisch zugeordnet werden.

2.1.2.1  Logical Transports

Zwischen Master und Slave – Master und Slave ist das Analogon zum Client-/Server-Modell bei Protokollen wie z. B. FTP – k�nnen verschiedene Typen von logischen Transportverbindungen (Logical Transports) hergestellt werden. Dabei ist es jedem Ger�t m�glich, den Master oder Slave Status einzunehmen; der Status kann sogar w�hrend der bestehenden Verbindung gewechselt werden. Logische Transportverbindungen werden von aktiven physischen Verbindungen getragen und sind in der Lage, verschiedene Arten logischer Verbindungen zu beinhalten (Vgl. : [Blu03, Architectur, S. 39f; PDF, S. 115f]).

In der Spezifikation sind f�nf logische Transportverbindungen zwischen Master und Slave definiert: Die synchronen Transportverbindungen stellen hierbei Punkt-zu-Punkt-Verbindungen von einem Master zu einem Slave dar. Sie unterst�tzen typischerweise zeitabh�ngige Informationen wie z. B. Sprache. Das Master-Ger�t regelt hierbei die Verbindung indem es reservierte Slots in regelm��igen Abst�nden benutzt. Die ACL Verbindungen stellen ebenfalls eine Punkt-zu-Punkt-Verbindung zwischen einem Master und einem Slave dar. Der Master kann die ACL Verbindung zu einem beliebigen Slave – inklusive der Slaves die bereits eine bestehende synchrone Verbindung haben – herstellen, indem er die Slots benutzt, die nicht f�r die synchrone Verbindung reserviert sind. Eine genaue Beschreibung der einzelnen Transportverbindungen ist unter [Blu03, Baseband Specification, S. 85ff; PDF, S.243ff] zu finden.

2.1.2.2  Logical Links



Um die verschiedenen Anforderungen einer Applikation bez�glich dem Datentransport abzudecken, ist eine Vielzahl logischer Verbindungen (Logical Links) verf�gbar. Jede logische Verbindung wird mit einer logischen Transportverbindung assoziiert, die �ber verschiedene Charakteristika verf�gt. Diese beinhalten z. B. Flusskontrolle, Sequenznummerierung sowie die Ablaufkoordination (Scheduling). Innerhalb einer logischen Transportverbindung kann die logische Verbindung anhand des Logical Link Identifiers (LLID) erkannt werden, der im Header eines Basisbandpakets zu finden ist (Vgl. : [Blu03, Architectur, S. 46f; PDF, S. 122f]).

Die folgenden f�nf logischen Verbindungen sind in der Spezifikation definiert (Vgl. : [Blu03, Baseband Specification, S. 95ff; PDF, S. 253ff])
Link Control (LC)
Diese logische Verbindung tr�gt Kontrollinformationen der unteren Ebenen, wie z. B. Acknowledgement/Repeat Request (ARQ), Flusskontrolle und Nutzlastcharakterisierungen.
ACL Control (ACL-C)
Die ACL-C Verbindung tr�gt Kontrollinformationen, die zwischen den Link Managern (LM)7 der Endger�te ausgetauscht werden m�ssen. Der Austausch dieser Informationen geschieht �ber das Link Manager Protokoll (LMP).
User Asynchronous/Isochronous (ACL-U)
Die ACL-U Verbindung tr�gt asynchrone, sowie isochrone L2CAP Benutzerdaten. Diese Nachrichten k�nnen in einem oder mehreren Paketen �bermittelt werden. Bei fragmentierten Daten wird im Header der LLID auf den entsprechenden Wert gesetzt.
User Synchronous (SCO-S)
Die SCO-S Verbindung transportiert synchrone Benutzerdaten.
User Extended Synchronous (eSCO-S)
Die eSCO-S Verbindung transportiert ebenfalls synchrone Benutzerdaten.

2.1.3  L2CAP Layer



Das Logical Link Control and Adaption Protocol (L2CAP) unterst�tzt Multiplexing zu Protokollen h�herer Ebenen, Paketsegmentierung und -reassemblierung, sowie das �bermitteln von Quality of Service8 Informationen. Applikationen und Service-Protokolle kommunizieren mit dem L2CAP-Layer �ber ein sogenanntes Channel-Orientated Interface, um Verbindungen zu anderen Ger�ten herzustellen. Die entsprechenden Endpunkte werden �ber einen Channel Identifier (CID) gekennzeichnet, dessen Wert vom L2CAP-Layer zugewiesen wird. Das Hauptaugenmerk des L2CAP-Layers liegt aber auf dessen Multiplexing-F�higkeit. Er ist daf�r zust�ndig, dass die �ber das Channel Interface ankommenden Daten (Service Data Units [SDUs]) auf die ACL-U Verbindungen verteilt werden. Ist ein HCI9 vorhanden, hat der L2CAP-Layer ebenfalls daf�r Sorge zu tragen, dass die Daten entprechend der Puffergr�sse des Basisbands segmentiert werden (Vgl. : [Blu03, Architectur, S. 48; PDF, S. 124]).

2.1.4  Bluetooth Sicherheit

Die Bluetooth-Spezifikation beschreibt das Sicherheitssystem, das bereits auf der Verbindungsebene (Link Layer) angewendet wird, sehr ausf�hrlich. Verschl�sselung, Authentifizierung sowie Schl�sselerzeugungsschemata und die Erzeugung von Zufallszahlen sind spezifiziert. Die Authentifizierungs- und Verschl�sselungsalgorithmen m�ssen in jedem Ger�t eine �quivalente Implementierung aufweisen. Um die Sicherheit auf der Verbindungsebene zu realisieren, werden die vier in [Tab.: 2.3] aufgef�hrten Entit�ten verwendet.
Entit�t Gr�sse
Bluetooth Device Address (BD_ADDR) 48 Bit
Privater Schl�ssel des Benutzers (Authentifizierung) 128 Bit
Privater Schl�ssel des Benutzers (Verschl�sselung) 8-128 Bit
Pseudozufallszahl (RAND) 128 Bit
Tabelle 2.3: In Authentifizierung und Verschl�sselung involvierte Entit�ten (Vgl. : [Blu03, Security Specification, S. 749; PDF, S. 907 Tabelle 1.1])
Die Authentifizierung beider Ger�te erfolgt in zwei Schritten, das heisst es wird eine gegenseitige Authentifizierung beider Ger�te vorgenommen. In direktem Anschluss der Authentifizierung des Ger�ts A bei Ger�t B wird die Authentifizierung in entgegengesetzter Richtung vorgenommen10 (Vgl. : [Blu03, Security Specification, S. 758; PDF, S. 914]).

Benutzerdaten k�nnen mittels des angebotenen Verschl�sselungsalgorithmus gesch�tzt werden. Es werden jedoch lediglich die Nutzdaten des zu sendenden Pakets verschl�sselt. Der Header des Pakets bleibt unangetastet. Der Algorithmus implementiert eine Stromchiffrierung mit Hilfe der SAFER+ Methode, die frei erh�ltlich ist. Sie ist eine verbesserte Version des SAFER11 Algorithmus [Blu03, Security Specification, S. 777ff; PDF, S. 935ff].

2.1.5  Generic Access Profile (GAP)

Sinn und Zweck des Generic Access Profiles (GAP) ist es, Definitionen, Empfehlungen sowie allgemeine Anforderungen in Bezug auf verschiedene Betriebsmodi und Zugriffsprozeduren zu beschreiben, die von Transport- und Applikationsprofilen verwendet werden sollten. Es wird weiterhin beschrieben, wie sich die Ger�te im Ruhe- und im Verbindungsaufbauzustand verhalten sollten. Speziell wird der Fokus hierbei auf die Ger�tesuche, Erzeugung der Verbindung sowie die Sicherheitsprozeduren gelegt. Das Schichtenmodell des GAP folgt dem in [Abb.: 2.2] dargestellten Aufbau [Blu03, Generic Access Profile, S. 179ff; PDF: S. 1127ff].
Abbildung 2.2: GAP Schichtenmodell (Vgl.: Abbildung 2.1: Profile stack covered by this profile, S. 181 [Blu03])
Die Spezifikation des GAP besch�ftigt sich haupts�chlich damit, zu beschreiben, welchem Zweck die unteren Schichten des Bluetooth Protokollstapels dienen (LC und LMP). Um Sicherheitsbezogene Alternativen zu diskutieren, wurden ebenfalls h�here Ebenen mit einbezogen (L2CAP, RFCOMM und OBEX) [Blu03, Generic Access Profile, S. 181; PDF: S. 1129].



In Bezug auf eine Suchanfrage (inquiry) kann sich ein Bluetooth-Ger�t in drei verschiedenen Zust�nden befinden. Die m�glichen Zust�nde sind in [Tab.: 2.4] abgedruckt.
Auffindbarkeitszustand Beschreibung
Non-discoverable mode Ist das Ger�t in diesem Zustand, so kann es von einer Suchanfrage nicht gefunden werden. Ein Bluetooth-Ger�t in diesem Zustand wird als “Stilles Ger�t” (silent device) bezeichnet.
Limited discoverable mode (LIAC) Das Ger�t ist f�r einen beschr�nkten Zeitraum oder bis zum Eintritt eines bestimmten Ereignisses auffindbar. Es sollte allerdings nicht l�nger als eine vordefinierte Zeit in diesem Zustand bleiben (timeout). Ist ein Ger�t in diesem Zustand, antwortet es auf Suchanfragen die den Limited Dedicated Inquiry Access Code (LIAC) verwenden.
General discoverable mode (GIAC) Das Ger�t befindet sich in einem dauerhaft auffindbaren Zustand. Ist ein Ger�t in diesem Zustand, antwortet es auf Suchanfragen die den General/Unlimited Inquiry Access Code (GIAC) verwenden.
Tabelle 2.4: Auffindbarkeitszust�nde eines Bluetooth-Ger�ts [M+05, Generic Access Profile, S. 189ff; PDF, S.1137ff]
Die spezifizierten Werte der Zugriffskennzeichner LIAC und GIAC sind auf der Bluetooth Homepage12 zu finden [Blu06].

2.1.6  Bluetooth Implementierungen

Um Bluetooth auf einem Ger�t verwenden zu k�nnen ist es notwendig, dass eine – zur Hardware passende – Implementierung eines Bluetooth-Stacks bereitgestellt wird. F�r die mobilen Endger�te ist in den meisten F�llen eine Bluetooth Implementierung des jeweiligen Herstellers auf dem Ger�t vorhanden. Um allerdings auf einem Desktop-System Bluetooth-Unterst�tzung zu erhalten, muss i. d. R. ein entsprechender Stack nachtr�glich installiert werden.

2.2  Java 2 Micro Edition (J2ME)

Die Java 2 Platform, Micro Edition (J2ME ) ist eine Plattform, die speziell auf die Bed�rfnisse von Embedded Devices zugeschnitten ist. Die J2ME Architektur definiert Konfigurationen, Profile sowie optionale Pakete, mit deren Hilfe es m�glich ist, Java Laufzeitumgebungen zu entwickeln, die eine m�glichst breite Palette an Endger�ten des jeweiligen Zielmarktes abdecken. Konfigurationen bestehen aus der Kombination einer virtuellen Maschine (VM) sowie einem zugeh�rigen minimalen Set an Klassenbibliotheken. Um eine komplette Laufzeitumgebung f�r dom�nenspezifische Endger�te zu schaffen, muss die Konfiguration um ein Set zus�tzlicher Klassenbibliotheken erweitert werden, die in einem Profil oder optionalen Paket definiert sind. Die J2ME Plattform l�sst sich, wie in [Abb.: 2.3] dargestellt, im Java Umfeld einordnen (Vgl. : [Sun06]).
Abbildung 2.3: Einordnung von J2ME im Java Umfeld (Vgl. : [Sun06])
Die J2ME Architektur folgt also prinzipiell dem in [Abb.: 2.4] dargestellten Aufbau. Die einzelnen Schichten der Architektur (CLDC [Kapitel 2.3] und MIDP [Kapitel 2.4]) werden im Folgenden genauer beschrieben.
Abbildung 2.4: J2ME Architektur (Vgl. : [T+03, Abb. 1, S. 28])

2.3  Connected Limited Device Configuration (CLDC)



Die Connected Limited Device Configuration (CLDC) stellt, zusammen mit dem Mobile Information Device Profile (MIDP)13, die Grundlage der J2ME dar. Wie nahezu alle Standards rund um Java, ist die CLDC ebenfalls Ergebnis eines Java Specification Request (JSR). Die CLDC 1.0 wird als JSR-30 [T+00], die Version 1.1 als JSR-139 [T+03] gef�hrt14. Die CLDC 1.1 ist nicht als komplette Neuerung, sondern lediglich als Erweiterung der CLDC 1.0 zu sehen. Das bedeutet, dass die CLDC 1.1, mit ein paar wenigen Ausnahmen wie z. B. der Unterst�tzung f�r Gleitpunktoperationen, abw�rtskompatibel zur CLDC 1.0 ist. Die CLDC Spezifikation hat zum Ziel, eine Entwicklungsplattform f�r netzwerkf�hige, jedoch in ihren Ressourcen limitierte, portable, Ger�te zu standardisieren. Solche Ger�te sind bspw. ein Mobiltelefon oder ein Personal Digital Assistant (PDA). Eine Konfiguration der J2ME Plattform spezifiziert hierbei die Basismenge der Java Programmiersprache sowie die Funktionalit�t der zugeh�rigen VM. Sun Microsystems, Inc. bietet eine Referenzimplementierung einer solchen virtuellen Maschine an, die in der Spezifikation als K Virtual Machine (KVM) bezeichnet wird, aber mittlerweile unter der Bezeichnung CLDC HotSpot Implementation Virtual Machine15 bekannt ist, die die 8-10 fache Geschwindigkeit der KVM erreicht. Die CLDC dient als Basis f�r ein oder mehrere Profile, die ein dem Ger�t entsprechendes API anbieten (Vgl. : [T+03, S. xi]).

Da die CLDC darauf ausgerichtet wurde, eine m�glichst grosse Anzahl verschiedener Ger�te zu unterst�tzen, besitzt sie, ausser der Mindestanforderung an den Speicher, keine weiteren Anforderungen bzgl. der zu Grunde liegenden Hardware. Typischerweise besitzen die angesprochenen Ger�te jedoch limitierte Ressourcen: In keinem Fall ist die CLDC mit der Connected Device Configuration (CDC)16 zu verwechseln, die einen erheblich gr�sseren Umfang als die CLDC bietet. Innerhalb der CDC ist z. B. der Mechanismus der Serialisierung und Deserialisierung von Objekten implementiert, was in der CLDC nicht der Fall ist. Die CDC ist f�r portable High-End-Ger�te entwickelt worden.

Die Implementierung der CLDC kann keine Kenntnis eines Dateisystems auf dem Endger�t voraussetzen. Viele, in ihren Ressourcen eingeschr�nkte Ger�te, verf�gen nicht �ber die Kenntnis eines Dateisystems oder �hnlichem, welches es erm�glicht dynamisch bezogene Daten persistent auf dem Ger�t zu speichern. Die Implementierung muss lediglich in der Lage sein, die Applikation zu laden und sie direkt nach ihrer Ausf�hrung wieder zu verwerfen. Verf�gt das Ger�t allerdings �ber einen Persistenzmechanismus, ist es Aufgabe des Betriebssystems, einen Mechanismus zur Verwaltung der Applikationen zur Verf�gung zu stellen. Auf Grund der variablen Bandbreite verf�gbarer Ger�te, ist ein solcher Mechanismus allerdings stark abh�ngig vom Ger�t selbst und wird aufgrunddessen nicht von der Spezifikation behandelt (Vgl. : [T+03, S. 29]).

2.3.1  Generic Connection Framework (GCF)

In einer einheitlichen, erweiterbaren Art und Weise bietet das Generic Connection Framework (GCF) die M�glichkeit, auf Ein- und Ausgabeoperationen sowie Netzwerkressourcen zuzugreifen. Anstatt auf eine Vielzahl verschiedener Abstraktionsmechanismen f�r jeden Kommunikationstyp zur�ckzugreifen, wird eine Menge zugeh�riger Abstraktionen auf Ebene der Applikationsprogrammierung benutzt. Dieser generische Mechanismus besitzt folgende Form:

Connector.open(«protocol>:<address>;<parameters>");

Das GCF, das in der CLDC spezifiziert wird, definiert allerdings kein zwingend zu unterst�tzendes Netzwerkprotokoll. Sie fordert ebensowenig eine Implementierung bereits bestehender Protokolle. Sie bietet jedoch ein erweiterbares Rahmenwerk, das von J2ME Profilen, wie z. B. dem MIDP17 angepasst werden kann. Die tats�chliche Implementierung der entsprechenden Protokolle erfolgt also auf Ebene des Profils (Vgl.: [T+03, S. 56ff]).

2.3.2  CLDC Sicherheit

Das von der J2SE bekannte, sehr m�chtige, Sicherheitsmodell konnte aufgrund des Code-Umfangs nicht �bernommen werden, da es die spezifizierten Speichergrenzen der CLDC bei weitem �berschreitet. Das Sicherheitsmodell ist deshalb in drei verschiedene Ebenen eingeteilt.
Low-level security
Der Begriff low-level security ist auch unter der Bezeichnung Virtual machine security bekannt. Low-level security stellt sicher, dass Applikationen, die in der VM ausgef�hrt werden, die Semantik der Java Programmiersprache einhalten. Sie stellt weiterhin sicher, dass jedweder fehlerhafte oder sch�dliche Programm-Code nicht in der Lage ist, das Ger�t zu besch�digen oder es zum Absturz zu bringen (Vgl. : [T+03, S. 30]).
Application-level security
Application-level security bedeutet, dass die Applikation nur auf Ressourcen, Bibliotheken und andere Komponenten zugreifen kann, die von der Java Laufzeitumgebung und dem Ger�t genehmigt worden sind. Realisiert wird das durch ein sogenanntes Sandbox-Modell. Es muss gew�hrleisten, dass Java Applikationen nicht aus ihrer Sandbox ausbrechen k�nnen. Das CLDC Sandbox-Modell verbietet ebenfalls ein herunterladen beliebiger neuer Bibliotheken, die nicht zum Umfang der Java Bibliotheken der CLDC oder des Herstellers geh�ren. Das Ausf�hren nativen Codes ist ebenfalls verboten (Vgl. : [T+03, S. 31]).
End-to-end security
Mit end-to-end security bezeichnet man ein Modell, das gew�hrleistet, dass die �ber ein Netzwerk gesendeten Daten – w�hrend ihres Transports durch diese Netze – gesch�tzt werden. Um dies zu gew�hrleisten ist ein Verschl�sselungs- oder ein �quivalenter anderer Schutzmechanismus notwendig. Aufgrund des breiten Spektrums verf�gbarer Endger�te kann allerdings keine einheitliche L�sung des Problems geschaffen werden. Die Spezifikation deklariert die end-to-end security diesbez�glich als implementierungsabh�ngig (Vgl. : [T+03, S. 32]).

2.4  Mobile Information Device Profile (MIDP)



Das Mobile Information Device Profile (MIDP) spezifiziert ein Profil, welches auf die F�higkeiten eines kleinen mobilen Endger�ts – einem sogenannten Mobile Information Device (MID) – abgestimmt ist. Das MIDP 2.0 ist das Ergebnis des JSR-118, basiert auf dem MIDP 1.0 (JSR-37) und ist zu diesem abw�rtskompatibel, sodass MIDlets18, die f�r das MIDP 1.0 geschrieben wurden, ebenfalls auf dem MIDP 2.0 lauff�hig sind19. Das MIDP spezifiziert eine auf der CLDC20 aufgesetzte Schicht. MIDP 2.0 setzt mindestens die Version 1.0 der CLDC voraus, jedoch wird angenommen, dass die meisten MIDP 2.0 Implementierungen auf der CLDC 1.1 aufsetzen werden. Da MIDs typischerweise eine sehr breite Spanne an Ressourcen zur Verf�gung stellen, ist die Anzahl der Programmierschnittstellen auf das Wesentliche reduziert worden, um eine m�glichst hohe Portabilit�t zu gew�hrleisten. Aus diesem Grund sind einige Funktionsbereiche abgegrenzt worden. Die abgegrenzten Bereiche sind die systemnahen Programmierschnittstellen (System-level APIs) sowie die Sicherheit der virtuellen Maschine (Low-level security) (Vgl. : [VW02, S. 5f]).

Die spezifizierten Mindestanforderungen an das MID sind als zus�tzliche Anforderungen zur CLDC zu betrachten. Die Anforderungen sind unterteilt in Hard- und Softwareanforderungen. Die f�r die vorliegende Arbeit relevanten Spezifikationspunkte sind das Netzwerk sowie der spezifizierte Persistenzmechanismus:
Netzwerk
Die Netzwerkhardware muss eine Zwei-Wege-Funkverbindung (mit limitierter Bandbreite) zur Verf�gung stellen. Um das Netzwerk API zu unterst�tzen, muss der Software lesender und schreibender Zugriff auf die Funkverbindung gew�hrt werden.
Persistenzmechanismus
Ein Mechanismus, um auf den nichtfl�chtigen Speicher zu schreiben und von ihm zu lesen, um die Anforderungen des Record Management Systems21 abzudecken.
In der Spezifikation sind weitere Anforderungen an des Ger�t definiert, die weitere Punkte wie Anzeige, Eingabemechanismen, Speicheranforderungen und Audioeigenschaften festlegen. Es wird weiterhin festgelegt, wie die Software-Landschaft des Ger�ts auszusehen hat. Dies umfasst z. B. einen minimalistischen Kernel sowie einen Mechanismus, der den Lebenszyklus der Applikation auf dem Ger�t verwaltet (Vgl. : [VW02, S. 7ff]).

2.4.1  Record Management System (RMS)

Das Record Management System (RMS) ist ein Mechanismus, der es MIDlets erm�glicht, Daten persistent auf dem Ger�t abzulegen. Der Mechanismus ist wie eine einfache datensatzorientierte Datenbank modelliert (Vgl. : [VW02, S. 463]).

2.4.1.1  Record Store

Ein Record Store ist eine Ansammlung an Datens�tzen, die, �ber mehrere Aufrufe der Applikation hinweg, persistent erhalten bleiben. Die zu Grunde liegende Plattform ist f�r die Integrit�t der Datens�tze verantwortlich. Sie ist auch f�r das Erzeugen des Record Stores verantwortlich, der an einem der Plattform spezifischen Ort liegt. Dieser Speicherort darf dem MIDlet, aus Sicherheitsgr�nden, nicht bekanntgegeben werden. Der Name des Records Stores wird allerdings auf Ebene des MIDlets festgelegt. Dieser Name muss innerhalb eines MIDlets eindeutig sein. Das RMS-API definiert keinen Locking-Mechanismus. Schreiboperationen auf das Datenbanksystem werden automatisch synchronisiert, was bedeutet, dass das API Thread-Safe22 ist (Vgl. : [VW02, S. 463f]).

2.4.1.2  Records

Records sind als Byte-Arrays implementiert. Der Entwickler kann also DataInputStream und DataOutputStream sowie ByteArrayInputStream und ByteArrayOutputStream verwenden, um Daten in einen Datensatz zu schreiben bzw. von ihm zu lesen. Jeder Record kann innerhalb eines Record Stores anhand seiner eindeutigen Identifikationsnummer (ID) zugeordnet werden. Das bedeutet; wird ein Datensatz eingef�gt, erh�lt er die ID „n“. Der n�chste eingef�gte Datensatz erh�lt die ID „n+1“ (Vgl. : [VW02, S. 464]).

Dieses Konzept der Enumeration wird konsequent verfolgt. Wird z. B. ein Datensatz gel�scht, wird die ID nicht wiederverwendet. Das bedeutet; sind drei Datens�tze mit den IDs >>1<<, >>2<< und >>3<< eingef�gt worden und wird der Datensatz mit der ID >>2<< gel�scht, erh�lt der n�chste eingef�gte Datensatz die ID >>4<< und nicht wie evtl. angenommen werden k�nnte, die ID >>2<<.

2.4.2  MIDP Sicherheit

Da sich das MIDP auf die Bereitstellung eines APIs f�r die Applikationsentwicklung bezieht, wurden die System-level APIs nicht weiter spezifiziert. Das heisst sie unterliegen der korrekten Implementierung und den Sicherheitsanforderungen des Herstellers. Es werden seitens der Spezifikation explizit keine weiteren Low-level Sicherheitsmechanismen definiert (Vgl. : [VW02, S. 6]).

Da das MIDP jedoch auf der CLDC aufsetzt, erbt es die bereits in der CLDC vorhandenen Sicherheitsmechanismen. Das System-level API wird prinzipiell von der Application-level security, die Low-level Sicherheit von der gleichnamigen Sicherheit in der CLDC abgedeckt23.

Das MIDP 1.0 zwingt jedes MIDlet dazu, innerhalb einer Sandbox ausgef�hrt zu werden, die jeglichen Zugriff auf sensitive Schnittstellen oder Funktionen des Ger�ts unterbindet. Dieses Konzept wird vom MIDP 2.0 ebenfalls f�r jedes nicht vertrauensw�rdige (untrusted) MIDlet verlangt. Jede MIDP 2.0 Implementierung ist verpflichtet, Unterst�tzung f�r untrusted MIDlets anzubieten. Mit dem MIDP 2.0 ist das Konzept vertrauter (trusted) Applikationen eingef�hrt worden, das den Zugriff auf sensitive Schnittstellen erlaubt. Nicht vertrauensw�rdige MIDlets m�ssen innerhalb der vom MIDP 1.0 spezifizierten Sandbox ausgef�hrt werden. Findet beim Ausf�hren eines solchen MIDlets ein Zugriff auf nicht vertrauensw�rdige Schnittstellen statt, muss der Zugriff entweder verworfen, oder, nach einer explizit angeforderten Genehmigung des Benutzers, erlaubt werden. Das trusted Modell definiert im Gegensatz dazu drei verschiedene Interaktionsmuster, die als User Permission Modes bezeichnet werden. Sie erm�glichen es dem Benutzer, den Zugriff auf ein bestimmtes API zu erlauben oder zu verwehren (Vgl. : [VW02, S. 23ff]).

Die verschiedenen Zugriffsmodi, die vom Benutzer festgelegt werden k�nnen, sowie deren G�ltigkeitszeitraum sind in [Tab.: 2.5] festgehalten.
User Permission G�ltigkeitszeitraum
blanket G�ltig f�r jede Ausf�hrung der MIDlet-Applikation bis sie deinstalliert oder die Rechte vom Benutzer ge�ndert werden.
session G�ltig vom Start eines MIDlets, bis zu dessen Termination. Der “session” Modus ist verpflichtet, den Benutzer beim oder vor dem ersten Aufruf einer gesch�tzten Funktion einen Dialog anzuzeigen, in dem der Benutzer entweder den Zugriff gestattet oder ablehnt. Bei einem erneuten Start des MIDlets muss diese Abfrage erneut erfolgen.
oneshot Eine Interaktion mit dem Benutzer ist bei jedem Zugriff auf ein gesch�tztes API notwendig.
Tabelle 2.5: G�ltigkeitszeitraum der Rechte eines MIDlets (Vgl. : [VW02, S. 26])

2.5  Java API for Bluetooth (JSR-82)

Um die Bluetooth Funktionalit�t von einem MIDlet aus ansprechen zu k�nnen, ist ein entsprechendes API notwendig. Der JSR-8224 definiert ein solches API sowie dessen Architektur, um Drittherstellern die M�glichkeit zu geben, Programme zu entwickeln, die eine Bluetooth Funkverbindung zur gegenseitigen Kommunikation nutzen. Das mit dem JSR-82 entwickelte API, das auch unter dem Akronym JABWT (Java API for Bluetooth Wireless Technology) bekannt ist, baut auf der Grundlage der CLDC [Kapitel 2.3] auf und basiert auf der Bluetooth Spezifikation in der Version 1.125. Es ist als optionale Erweiterung eines MIDP [Kapitel 2.4] zu sehen (Vgl. : [M+05, S. 11]).

Mit der Spezifikation wurde beabsichtigt, eine Grundlage zu schaffen, mit der es erm�glicht wird, weitere Profile zu entwickeln. Dazu werden APIs f�r das L2CAP und OBEX26 Protokoll angeboten, auf deren Basis zuk�nftige Profile entwickelt werden k�nnen. Das API bietet folgende Dienste an:
  1. Registrierung eines Dienstes
  2. Ger�t- und Dienstsuche
  3. M�glichkeit, L2CAP und OBEX Verbindungen herzustellen.
  4. Sichere Ausf�hrung dieser Aktivit�ten.
Da nicht alle Profile und Ebenen der Bluetooth Spezifikation �bernommen werden k�nnen, beschr�nkt sich der Umfang des APIs lediglich auf Datendienste. Sprachdienste k�nnen nicht verarbeitet bzw. angesteuert werden (Vgl. : [M+05, S. 14]).

2.5.1  Anforderungen

Die vom JSR-82 definierten Anforderungen sind als Zus�tze zu den bereits bestehenden Anforderungen der CLDC zu betrachten. Sie umfassen Anforderungen an die Spezifikation selbst, wie z. B. eine alleinige Abh�ngigkeit zu den CLDC Bibliotheken. Auf die Spezifikationsanforderungen soll jedoch nicht n�her eingegangen werden. Es sind vielmehr die Anforderungen an das Ger�t sowie die des zu Grunde liegenden Bluetooth-Systems von Interesse.
Hardware-Anforderungen
Das JSR-82 API ist entwickelt worden, um auf Ger�te mit folgenden Hardware-Charakteristika eingesetzt werden zu k�nnen.
Bluetooth-Anforderungen
Die Anforderungen an das zu Grunde liegende Bluetooth-System sind folgende:
Die Unterst�tzung f�r das OBject EXchange (OBEX) Protokoll kann entweder bereits vom zu Grunde liegenden Bluetooth-System, oder durch Implementierung des JSR-82 APIs bereitgestellt werden [M+05, S. 14f].

2.5.2  Paketierung

In der Spezifikation sind zwei Pakete definiert: Auf Grund der Tatsache, dass das OBEX API unabh�ngig ist von Bluetooth, wird es in einem separaten Paket ausgeliefert. Eine CLDC ist somit in der Lage, entweder nur eines der beiden, oder beide auszuliefern. Das Paket javax.bluetooth beinhaltet die Bluetooth Basisbibliotheken, wohingegen das javax.obex Paket die Implementierung des OBEX APIs beinhaltet. Aus diesem Grund werden auch zwei verschiedene Technology Compatibility Kits (TCK) zur Verf�gung gestellt, mit Hilfe derer die Implementierung gegen�ber der Spezifikation getestet werden kann [M+05, S. 21].

2.5.3  Bluetooth Control Center

Bei Ger�ten die das JSR-82 API implementieren, kann es u. U. m�glich sein, dass mehrere Applikationen zeitgleich ausgef�hrt werden. Die Notwendigkeit eines Bluetooth Control Centers (BCC) ergibt sich aus dem Wunsch, zu verhindern, dass eine Applikation eine andere nachteilig beeinflusst. Es ist als zentrale Anlaufstelle des lokalen Bluetooth-Ger�ts zu sehen. Die Implementierung des BCC kann entweder als native Applikation bzw. als Applikation mit separatem API oder als fixe Gruppe von Eigenschaften, die nicht vom Benutzer ge�ndert werden k�nnen, umgesetzt werden. Das BCC ist nicht als Klasse oder Schnittstelle innerhalb des JSR-82 APIs spezifiziert, stellt jedoch eine wichtige Rolle f�r die Sicherheitsarchitektur des JSR-82 dar. Das BCC muss der JSR-82 Implementierung folgende Funktionen zur Verf�gung stellen: Keine dieser Informationen darf von einer Applikation aus ge�ndert werden k�nnen. Die einzige Applikation, die berechtigt ist dies zu tun, ist das BCC. Das BCC kann weitere Eigenschaften des Ger�ts zug�nglich machen, wie z. B. die Einstellung des Ger�tenamens (friendly name) oder die M�glichkeit, das Ger�t auf die Werkseinstellungen zur�ckzusetzen [M+05, S. 22].

2.5.4  Eigenschaften des Ger�ts

Da sich je nach Einsatzzweck die Konfiguration der Bluetooth-Ger�te unterscheidet, besteht die Notwendigkeit, bestimmte Eigenschaften des Ger�ts abzufragen. Das API definiert eine Reihe von Eigenschaften, die durch einen Aufruf der Funktion LocalDevice.getProperty() abgefragt werden k�nnen. Die Werte, die abgefragt werden k�nnen, sind in [Tab.: 2.6] dargestellt. Soll ein solcher Wert abgefragt werden, ist zu beachten, dass die Zeichenketten case sensitive28 sind. Ist die Eigenschaft nicht definiert, oder unbekannt, muss null zur�ckgegeben werden. S�mtliche Eigenschaften, die durch LocalDevice.getProperty() abgefragt werden k�nnen, m�ssen ebenfalls durch die von der CLDC bereitgestellte Funktion System.getProperty() zug�nglich sein [M+05, S. 23f].
Eigenschaft Beschreibung
bluetooth.api.version obex.api.version Version des Java APIs for Bluetooth wireless technology die unterst�tzt wird. F�r die Version 1.1 wird entsprechend “1.1” zur�ckgeliefert.
bluetooth.l2cap.receiveMTU.max Maximum Transfer Unit (MTU) in Empfangsrichtung, die von L2CAP unterst�tzt wird. Der zur�ckgelieferte Wert ist dezimal in einem java.lang.String kodiert.
bluetooth.connected.devices.max Maximale Anzahl verbundener Ger�te.
bluetooth.connected.inquiry Kann eine Ger�tesuche durchgef�hrt werden, w�hrend das Ger�t bereits verbunden ist?
bluetooth.connected.page Kann das lokale Ger�t eine Verbindung zu einem entfernten Ger�t herstellen, wenn das lokale Ger�t bereits verbunden ist?
bluetooth.connected.inquiry.scan Kann das lokale Ger�t auf eine Suchanfrage antworten, w�hrend es mit einem anderen Ger�t verbunden ist?
bluetooth.connected.page.scan Kann das lokale Ger�t eine Verbindung von einem anderen Ger�t annehmen, w�hrend es bereits mit einem anderen Ger�t verbunden ist?
bluetooth.master.switch Ist der master/slave Wechsel erlaubt?
bluetooth.sd.trans.max Maximale Anzahl zeitgleicher Dienstsuchen (Service Discovery)
bluetooth.sd.attr.retrievable.max Maximale Anzahl der Service-Attribute die mit einem Service Record empfangen werden k�nnen.
Tabelle 2.6: �bersicht der Eigenschaften des Ger�ts (Vgl. [M+05, S. 24, Tabelle 3-2 Device Properties])

2.5.5  Client-/Server Modell

Ein Bluetooth-Dienst (Service) ist eine Server-Applikation, die einem Client eine bestimmte Funktionalit�t erm�glicht. Ein Service zum Drucken �ber Bluetooth w�re bspw. eine solche Applikation. Entwickler, die mit Bluetooth arbeiten, k�nnen ihre eigenen Server-Applikationen schreiben, die sie anderen (Clients) zur Verf�gung stellen. Dies wird realisiert, indem der Service Discovery Database (SDDB) des lokalen Bluetooth-Ger�ts ein sogenannter Service Record hinzugef�gt wird, der den angebotenen Dienst beschreibt. Nachdem der Service registriert wurde, wartet der Server auf einen Client, der die Verbindung zu dem gew�nschten Service initiiert [M+05, S. 24].

2.5.6  Discovery

Da die meisten mit Bluetooth ausgestatteten Ger�te tragbar sind, wird ein Mechanismus ben�tigt, der es erm�glicht, dass sich zwei oder mehr Ger�te finden k�nnen. Dieser Prozess wird als Discovery bezeichnet. Es existieren hierbei zwei Discovery-Arten; Device- und Service-Discovery [M+05, S. 27].

2.5.6.1  Device Discovery

Ger�te k�nnen von einer Applikation mit Hilfe der Funktion startInquiry(), die nicht blockierend implementiert ist, oder mit ihrem blockierenden �quivalent retrieveDevices() gefunden werden. Die retrieveDevices() Methode ist jedoch nicht in der Lage, “neue” Ger�te zu finden, sondern liefert lediglich eine Liste der dem Ger�t bereits bekannten Ger�te. Das sind Ger�te, die bspw. in einer vorhergehenden Suche bereits gefunden wurden oder Ger�te die als Pre-known klassifiziert sind. Als Pre-known Ger�te bezeichnet man Ger�te, die im BCC definiert wurden. Die retrieveDevices() Methode f�hrt keine aktive Suche durch, stellt aber die M�glichkeit dar, eine Liste von Ger�ten zu erhalten, die sich im n�heren Umfeld befinden k�nnten. Wird die startInquiry() Methode verwendet, muss zus�tzlich ein Listener implementiert werden, der benachrichtigt wird sobald ein neues Ger�t gefunden wurde. Der zu implementierende Listener ist im Interface javax.bluetooth.DiscoveryListener definiert. Die Klasse javax.bluetooth.DiscoveryAgent bietet die entsprechenden Methoden zur Ger�te- und Dienstsuche an [M+05, S. 28f].

2.5.6.2  Service Discovery

Nachdem ein Ger�t mittels einer Device Discovery ausfindig gemacht werden konnte, ist es i. d. R. von Interesse herauszufinden, ob auf dem gefundenen Ger�t der gew�nschte Dienst vorhanden ist. Die Suche nach einem solchen Dienst wird als Service Discovery bezeichnet. Eine lokale Service-Suche wird vom JSR-82 API allerdings nicht unterst�tzt. Die in eine Service-Suche involvierten Klassen sind Folgende [M+05, S. 30f]: In der Spezifikation ist zu jeder der aufgelisteten Klassen Beispielcode zu finden, der die Anwendung der Klassen verdeutlicht.

2.5.7  Generic Access Profile (GAP)

Im Kapitel 7 der JSR-82 Spezifikation sind die Klassen aufgef�hrt, die dazu dienen, Eigenschaften des Ger�ts zu manipulieren, die Teil des GAPs29 sind. Die Standardmechanismen zur Manipulation des lokalen Ger�ts befinden sich in der Klasse javax.bluetooth.LocalDevice, die Methoden um Informationen von einem entfernten Ger�t zu erhalten befinden sich in der Klasse javax.bluetooth.RemoteDevice. Die Klasse javax.bluetooth.DeviceClass definiert Werte, mit Hilfe derer es m�glich ist den Ger�tetyp sowie den Typ des Angebotenen Dienstes zu identifizieren [M+05, S. 50f].

2.5.8  Kommunikation

Um den Dienst eines anderen Bluetooth-Ger�ts in Anspruch nehmen zu k�nnen, m�ssen beide Ger�te in der Lage sein miteinander zu kommunizieren. Dies erfordert die Kenntnis eines gemeinsamen Kommunikationsprotokolls, sodass verschiedene Applikationen miteinander kommunizieren k�nnen. Der JSR-82 stellt APIs zur Verf�gung, mit deren Hilfe man Verbindungen zu RFCOMM, L2CAP oder OBEX Diensten herstellen kann. Das Generic Connection Framework (GCF)30 der CLDC stellt dabei den Basismechanismus der Protokollimplementierung dar (Vgl. : [M+05, S. 63]).

2.5.8.1  Serial Port Profile

Das RFCOMM Protokoll emuliert mehrere RS-232 Ports zwischen zwei Bluetooth Endger�ten. Die Bluetooth-Adressen der beiden Endger�te identifizieren hierbei die RFCOMM Sitzung. Zwischen zwei Ger�ten darf immer nur eine Sitzung bestehen, die jedoch �ber mehr als eine Verbindung verf�gen darf. Die Anzahl gleichzeitiger Verbindungen ist hierbei abh�ngig von der jeweiligen Implementierung. Eine Applikation, die einen Dienst auf Basis des Serial Port Profiles (SPP) anbietet, wird dabei als SPP Server, eine die zu einem solchen eine Verbindung initiiert, als SPP Client bezeichnet. Nachdem eine Verbindung hergestellt ist, k�nnen Daten in beiden Richtungen ausgetauscht werden. Die Aushandlung der Verbindungsparameter sowie der Flusskontrolle muss hierbei automatisch zwischen den an der Kommunikation teilnehmenden Endger�ten von der SPP Implementierung gehandhabt werden (Vgl. : [M+05, S. 64ff]).

Innerhalb eines Code-Fragments sind SPP Verbindungen (Client- oder Serverseitig) am String "btspp://" innerhalb von Connector.open() zu erkennen. Stellt die Applikation einen Dienst zur Verf�gung, ist "btspp://localhost" zu Beginn des Strings enthalten.

URLs, die einen Verbindungsaufbau zu einem entfernten Ger�t erm�glichen, sind nach folgendem Schema aufgebaut:

{scheme}:[{target}{params}]

Um RFCOMM zu benutzen ist das Schema ({scheme}), das f�r Client und Server verwendet wird, btspp. Die beiden anderen Platzhalter ({target} und {params}) unterscheiden sich, je nachdem, ob die Applikation einen Client oder Server darstellt. Alle g�ltigen Parameter, die in einem RFCOMM, L2CAP oder OBEX �ber RFCOMM Verbindungskennzeichner vorkommen k�nnen, sind in [Tab.: 2.7] aufgelistet.

Name Beschreibung Zul�ssige Werte Client oder Server
master Gibt an, ob das Ger�t master der Verbindung sein muss. true, false Beide
authenticate Gibt an, ob das entfernte Ger�t authentifiziert werden muss bevor eine Verbindung hergestellt werden kann. true, false Beide
encrypt Gibt an, ob die Verbindung verschl�sselt werden muss. true, false Beide
authorize Gibt an, ob alle Verbindungen zu diesem Ger�t authorisiert werden m�ssen um den Dienst zu nutzen. true, false Server
name Der Name des angebotenen Dienstes, der in der SDDB gespeichert wird. Jeder g�ltige String Server
Tabelle 2.7: G�ltige Parameter f�r RFCOMM Verbindungskennzeichner (Vgl. : [BJJ04, S. 59, Tabelle 4.1 Valid Parameters for RFCOMM Connection Strings])

2.5.8.2  Object Exchange Protocol (OBEX)

Das OBEX Protokoll wurde urspr�nglich von der Infrared Data Association (IrDA)31 entwickelt, um Objekte auf einen Client oder Server zu “schieben” (push) oder sie von diesem zu “ziehen” (pull). Um Objekte zu transferieren, etabliert OBEX zun�chst eine Sitzung. Eine OBEX Sitzung beginnt mit einer CONNECT Anforderung und endet mit einer DISCONNECT Anforderung. W�hrend die Sitzung etabliert ist, kann der Client Objekte vom Server holen (GET) oder Objekte am Server ablegen (PUT). Diese Objekte k�nnen Dateien, Visitenkarten (vCards32) oder Byte-Arrays darstellen. Indem der Client das SETPATH Kommando sendet, kann er den Server dazu veranlassen, sein aktuelles Verzeichnis zu wechseln (Vgl. : [M+05, S. 93]).

OBEX skaliert sehr gut, egal ob es sich um grosse oder kleine Dateien handelt die �bertragen werden m�ssen. Erreicht wird dies dadurch, dass OBEX die zu �bertragenden Daten in mehreren Paketen schickt. Sobald der Client eine PUT oder GET Anforderung sendet, wird eine OBEX-Operation gestartet. Diese Operation besteht solange, bis die Datei vollst�ndig �bertragen ist oder ein Fehler eintritt. Um eine PUT Operation durchzuf�hren, bricht der Client (Applikation oder Protokoll-Stack) das zu sendende Objekt in kleine St�cke und sendet jedes einzeln an den Server. Der Client sendet das nachfolgende St�ck nicht bevor der korrekte Versand des Vorg�ngerst�cks best�tigt wurde (Vgl. : [M+05, S. 93]).

OBEX bietet, wie das Hypertext Transfer Protocol (HTTP)33, die M�glichkeit, zus�tzliche Informationen zwischen Client und Server auszutauschen. Diese zus�tzlichen Meta-Informationen befinden sich im OBEX-Header, der im vergleich zum HTTP-Header lediglich Byte-Werte akzeptiert34. OBEX bietet Standard-Header an, wie z. B. Name-, L�nge- und Beschreibungsfelder. Zus�tzlich existieren noch 64 Header die vom Anwender definiert – und belegt – werden d�rfen (Vgl. : [M+05, S. 93]).

Das vom JSR-82 definierte API erlaubt es einer Applikation OBEX-Operationen zwischen Client und Server auszuf�hren. Allerdings adressiert das API das verbindungslose OBEX nicht, wie dies in der OBEX Spezifikation der IrDA der Fall ist. Das bereitgestellte OBEX API stellt die in [Tab.: 2.8] dargestellten Operationen zur Verf�gung.

Operation Beschreibung
CONNECT Stellt die Verbindung zum Server her.
PUT �bertr�gt Daten vom Client an den Server.
GET �bertr�gt Daten vom Server an den Client.
SETPATH �ndert das Arbeitsverzeichnis auf dem Server.
ABORT Bricht eine PUT oder GET Operation ab.
CREATE-EMPTY Erzeugt ein leeres Objekt mit dem im Header angegebenen Namen auf dem Server.
PUT-DELETE L�scht das im Header angegebene Objekt auf dem Server.
DISCONNECT Beendet die Verbindung zum Server.
Tabelle 2.8: OBEX Operationen
Da das OBEX Protokoll �ber verschiedene Transportprotokolle verwendet werden kann, muss der String, der die Verbindung spezifiziert, das Transportprotokoll beinhalten. Die URL, um eine Verbindung zu einem entfernten Ger�t herzustellen, hat folgenden Aufbau:

{scheme}:[{target}{params}]

Um die zus�tzliche Verwendung des Protokolls bei OBEX deutlich zu machen, wird, mit Ausnahme von OBEX �ber RFCOMM, folgendes Schema verwendet:

{transport}obex://{target}{params}.

Wird RFCOMM als Transportprotokoll verwendet, ist der als {scheme} gekennzeichnete Teil mit btgoep zu ersetzen und {target} spezifiziert die Bluetooth-Adresse, sowie die RFCOMM Kanalnummer. Alle f�r RFCOMM g�ltigen Parameter ({params}) sind ebenfalls f�r OBEX �ber RFCOMM g�ltig35. Ein g�ltiger OBEX �ber RFCOMM Verbindungskennzeichner hat also die Form:

Client: btgoep://0123456789ab:1;authenticate=yes
Server: btgoep://localhost:DEADBEEFCAFEBABE5DADD115A1D1DEAD

Die von den anderen Verbindungskennzeichnern differente Schreibweise r�hrt daher, dass das OBEX Protokoll mit Hilfe des in der Bluetooth-Spezifikation definierten Generic Object Exchange Profiles (GOEP)36 realisiert wurde [M+05, S. 98].

2.5.9  JSR-82 Sicherheit

Im JSR-82 werden Methoden beschrieben, die es erm�glichen, eine gesicherte Bluetooth-Kommunikation herzustellen. Es ist m�glich, bereits beim Aufbau der Verbindung, durch einen entsprechend angepassten Connection String, die Sicherheitsparameter festzulegen. Methoden der javax.bluetooth.RemoteDevice Klasse k�nnen benutzt werden, um Sicherheits�nderungen der bestehenden Verbindung zu veranlassen. Die Definition und Belegung der Parameter ist sehr umfangreich und wird in Kapitel 8 des JSR-82 detailliert beschrieben. Die Beschreibung umfasst dabei, wie die Sicherheitsanforderungen bereits beim Verbindungsaufbau festgelegt oder Client und Server Authentifikations- oder Verschl�sselungsforderungen stellen k�nnen [M+05, S. 52ff].

1
Engl. : baseband, transceiver, protocolstack
2
Industrial, Scientific, and Medical Band [Wik06c]
3
Illustration: [Bec05, Folie 9]
4
Siehe [Wik06d]
5
Frequenzbereich des Nutzsignals (siehe [Wik06a])
6
engl.: Logical Transport, siehe [Kapitel 2.1.2.1]
7
Der LM ist verantwortlich f�r die Erzeugung, Modifikation und Freigabe logischer Verbindungen [Blu03, Architecture, S. 23; PDF, S. 99].
8
Kurz: QoS, bezeichnet ein Verfahren, das einem (Paket-)Dienst eine Mindestbandbreite zusichert.
9
Das Host Controller Interface (HCI) befindet sich zwischen logischem und L2CAP-Layer und stellt eine einheitliche Schnittstelle zum Bluetooth-Controller dar.
10
Sogenanntes Challenge-Response Verfahren (siehe [FS06, S. 56])
11
Siehe [Sch96, S. 392ff]
12
Siehe https://www.bluetooth.org/
13
Siehe [Kapitel 2.4]
14
Alle JSRs sind abrufbar unter: https://www.jcp.org/en/home/index
15
Siehe https://java.sun.com/products/cldc/
16
Siehe [C+05]; Einordnung siehe [Abb.: 2.3]
17
Siehe [Kapitel 2.4]
18
Programme, die auf einem MID ausgef�hrt werden k�nnen.
19
JSR-118: [VW02]; JSR-37 [Van00]
20
Siehe [Kapitel 2.3]
21
Siehe [Kapitel 2.4.1]
22
Parallele Aufrufe einer Funktion auf einen Datensatz/-block f�hren nicht zu Inkonsistenzen dessen.
23
Siehe [Kapitel 2.3.2]
24
Siehe https://www.jcp.org/en/jsr/detail?id=82
25
Version 1.1 kann unter https://www.bluetooth.org/spec/ angefordert werden.
26
Siehe [Kapitel 2.5.8.2]
27
Siehe [Kapitel 2.5.8.1]
28
Gross-/Kleinschreibung ist zu beachten.
29
Siehe [Kapitel 2.1.5]
30
Siehe [Kapitel 2.3.1]
31
Siehe https://www.irda.org/
32
Datenformat f�r eine elektronische Visitenkarte
33
Siehe https://www.ietf.org/rfc/rfc2616.txt
34
OBEX wird aus diesem Grund auch gerne als bin�res HTTP bezeichnet.
35
Siehe [Tab.: 2.7]
36
Spezifikation: [Blu05]

Kapitel 3  OBEX Object Passing

Mobile Endger�te verf�gen durch das GCF der CLDC �ber einen Mechanismus, der es ihnen erlaubt, eine Verbindung zu einem anderen Ger�t �ber ein Netzwerk herzustellen. Das Kommunikationsverhalten ist jedoch, auf Grund der fehlenden M�glichkeit Java-Objekte zu �bertragen, als eingeschr�nkt einzustufen.

Als Vorstufe der �bertragung ist eine Serialisierung des Objekts notwendig, sodass dieses �bertragen und beim Empf�nger wieder deserialisiert werden kann. RMI beinhaltet einen solchen Mechanismus um Objekte zu �bertragen. Mit dem JSR-661 – RMI Optional Package (RMI OP) – wurde der RMI Mechanismus, der im J2EE Umfeld h�ufig im Zusammenhang mit bspw. Enterprise JavaBeans (EJB) genannt wird, innerhalb der J2ME verf�gbar gemacht. Als Nachteil dieser L�sung erweist sich jedoch der Umstand, dass die RMI OP Erweiterung abh�ngig von der CDC ist, die von dem Vorhandensein einer VM, welche die JVM Spezifikation vollst�ndig unterst�tzt, abh�ngig ist. Ein Einsatz in Verbindung mit der CLDC ist, wegen der fehlenden, vollst�ndigen JVM Unterst�tzung nicht m�glich2.

Es existieren allerdings andere Frameworks, die sich des Problems der Serialisierung von Objekten mit der J2ME annehmen. Ein Vergleich der Frameworks Javolution, kSOAP, Burlap/Hessian und RMI OP wurde in [BSM06] durchgef�hrt. Als Ergebnis der Untersuchung wurde festgestellt, dass keines der untersuchten Frameworks in der Lage ist, ein komplexes Objekt innerhalb der J2ME (auf Basis der CLDC) zu deserialisieren. W�re eine Serialisierung der Objekte mit Hilfe einer der o. g. Frameworks m�glich gewesen, w�rden sie allerdings das Problem der Daten�bertragung – abgesehen von RMI – nicht l�sen k�nnen.

Der Fokus der OOP Bibliothek liegt nicht auf der Serialisierung von Objekten, wie dies auf Grund der Schnittstellendefinition evtl. angenommen werden k�nnte, sondern vielmehr auf der effizienten, einfachen �bertragung der Daten einfacher Objekte. Tiefe Kopien von komplexen Objektstrukturen k�nnen, sofern sie vom Programmierer in eine Byte-Array-Repr�sentation �berf�hrt und von dieser auch wieder hergestellt werden k�nnen, ebenfalls mit dem Mechanismus �bertragen werden. Die einfachste Methode jedoch ist es, die komplexe Objektstruktur in eine einfache Darstellung zu �berf�hren. Falls es das Projekt zul�sst, kann auf die CDC gewechselt werden, die einen Mechanismus zur Serialisierung von Objekten bereitstellt, sodass die zu �bertragenden Objekte sehr leicht in einer Byte-Array-Repr�sentation erhalten werden k�nnen.

Das OBEX Object Passing (OOP) stellt eine signifikante Vereinfachung der �bertragung von Objekten �ber eine Bluetooth-Funkstrecke dar.

Das Peer2Me Projekt3 scheint einen, dem OOP �hnlichen, Mechanismus zu implementieren. Die Schnittstelle Persistent des Projekts weist die selbe Signatur wie die Schnittstelle IObexObjectPassing der OOP Bibliothek auf. Die Peer2Me Bibliothek baut auf der RFCOMM Schnittstelle auf. Um Transportprotokollunabh�ngigkeit zu erreichen, wurde ein eigener Mechanismus entwickelt (Vgl. : [LN05, S. 70] und [LN05, S. 58]). Eine genauere Untersuchung des Projekts liess sich, auf Grund der sp�ten Entdeckung, nicht mehr realisieren.

OOP setzt im Vergleich zu Peer2Me auf der OBEX Schicht auf. Die Transportprotokollunabh�ngigkeit wird beim OOP durch eben diesen Umstand erreicht. Das OOP passt sich wie in [Abb.: 3.1] dargestellt in den Bluetooth-Protokollstapel ein.
Abbildung 3.1: Einordnung von OOP im Bluetooth-Protokollstapel

3.1  Technische Voraussetzungen

Die Implementierung der Bibliothek sowie die Umsetzung der Beispielapplikation, ist mit der Netbeans IDE4 realisiert worden. Die Netbeans IDE wurde auf Grund pers�nlicher Pr�ferenzen des Autors sowie der beispiellosen Integration des Wireless Toolkits (WTK)5 gew�hlt. Die Integration des WTK erfolgt durch die zus�tzliche Installation des sogenannten Mobility Packs, das unter der selben URL gefunden werden kann wie die IDE selbst. Die Applikationsentwicklung wird durch die gute Integration der vom WTK bereitgestellten Emulatoren wesentlich vereinfacht.

Die Netbeans IDE ist auf nahezu allen Betriebssystemen, auf denen eine JVM unterst�tzt wird, verf�gbar. Allerdings gilt dieser Umstand nur f�r die IDE selbst. Das f�r die Entwicklung von J2ME Applikationen notwendige Wireless Toolkit ist nicht f�r Macintosh Plattformen verf�gbar. Es ist jedoch m�glich, durch den Einsatz eines alternativen Emulators, J2ME Applikationen auf dem Macintosh zu entwickeln6.

M�chte man, abgesehen von Applikationen f�r mobile Endger�te, Applikationen entwickeln, die auf einem Desktop-Computer verwendet werden sollen, ist die zus�tzliche Installation eines Bluetooth-Stacks sowie einer JSR-82 Implementierung notwendig.

3.1.1  Bluetooth-Stack

Beim Kauf eines Bluetooth-Adapters wird der Stack i. d. R. vom Hersteller des Produkts mitgeliefert. Der Funktionsumfang des mitgelieferten Stacks ist jedoch vom Hersteller abh�ngig. Ein nicht mit dem Produkt gelieferter Bluetooth-Stack kann (wahrscheinlich) installiert werden, jedoch ist die Beschaffung desselben auf legalem Wege nicht zu erreichen. Linux verwendet einen eigenen Bluetooth-Stack; den sogenannten BlueZ Stack7. Die Macintosh Plattform verwendet ebenfalls ihre Eigenentwicklung.

3.1.2  JSR-82 Implementierung

Bei der Wahl der JSR-82 Implementierung ist ebenfalls Vorsicht geboten. Die Implementierungen sind abh�ngig vom zu Grunde liegenden Bluetooth-Stack. So kann es passieren, dass die gew�nschte JSR-82 Implementierung nicht mit dem auf dem System installierten Bluetooth-Stack zusammenarbeitet.

Um den JSR-82 auf realen Ger�ten einsetzen zu k�nnen, muss das Endger�t Unterst�tzung f�r diesen bereitstellen. Dies ist bei den meisten mobilen Endger�ten, wie z. B. Handys, oder PDAs gegeben. M�chte man allerdings auf einem Desktop-Computer eine Bluetooth-Anwendung in Betrieb nehmen, muss zus�tzlich zum Bluetooth-Stack eine JSR-82 Implementierung installiert werden.

Die meisten Implementierungen werden in Form eines Java-Archivs und einer Systembibliothek ausgeliefert. Es gibt allerdings auch Ausnahmen, wie z. B. die Harald-8 oder JavaBluetooth-Implementierung9, die eine vollst�ndig in Java realisierte JSR-82 Implementierung bereitstellen. Da die beiden Alternativen allerdings das javax.comm Paket verwenden, muss dieses zus�tzlich installiert werden. Hier hat man die Wahl zwischen dem Paket von Sun10, und einer RXTX11 genannten Implementierung. Die Installation und Konfiguration der Bibliotheken erweist sich jedoch, im Vergleich zu den Paketen mit Systembibliothek und Java-Archiv, schwieriger. Es existieren allerdings auch Implementierungen, die lediglich in einem einzigen Java-Archiv ausgeliefert werden. Sie laden die notwendigen nativen Bibliotheken intern nach.

Bei den verschiedenen verf�gbaren JSR-82 Implementierungen muss zus�tzlich darauf geachtet werden, ob sie den JSR-82 vollst�ndig (inklusive javax.obex) implementieren. Die Spezifikation l�sst bei der Implementierung des OBEX Protokolls die Wahl, ob OBEX im zu Grunde liegenden Bluetooth-System oder mit dem JSR-82 implementiert wird12. Dieses Faktum scheint von einigen JSR-82 Implementierungen falsch verstanden oder bewusst weggelassen zu werden. In jedem Fall sollte die JSR-82 Implementierung die Schnittstellen exportieren bzw. sollten sie vom JSR-82 API angesteuert werden k�nnen.

Das Problem des fehlenden javax.obex Pakets kann durch den Einsatz der avetanaOBEX13 Bibliothek kompensiert werden. Da viele mobile Endger�te ohnehin nur den javax.bluetooth Teil der Spezifikation unterst�tzen, k�nnen diese Ger�te durch den Einsatz der Bibliothek ebenfalls adressiert werden. Ein allgemeines Nachr�sten der fehlenden OBEX Unterst�tzung ist hingegen nicht m�glich. Die von der CLDC gesetzten Sicherheitsstandards verbieten eine Nachr�stung von Funktionalit�t durch externe Bibliotheken14, was zur Folge hat, dass die Bibliothek in jeder Applikation mitgeliefert werden muss, was auf den ohnehin schon mit knappem Speicher bemessenen Ger�ten zus�tzlichen Speicherplatz in Anspruch nimmt.

F�r die vorliegende Arbeit ist auf dem Desktop-System der mit dem Service Pack 2 f�r Windows XP ausgelieferte Bluetooth-Stack verwendet worden. Als JSR-82 Implementierung ist BlueCove15 auf Grund seiner freien Verf�gbarkeit und einfachen Installation zum Einsatz gekommen.

3.2  Design

Das OBEX Protokoll ist pr�destiniert zur �bertragung gr�sserer Objekte �ber ein Netzwerk. Die korrekte Fragmentierung der Daten, die ansonsten manuell durchgef�hrt werden m�sste, ist innerhalb des Protokolls vorgesehen und kann somit bei jeder OBEX Implementierung vorausgesetzt werden. Bei Bluetooth bspw. muss die Fragmentierung, sofern ein HCI vorhanden ist, sp�testens von der L2CAP Implementierung durchgef�hrt werden16. Ein weiterer Vorteil des OBEX Protokolls besteht in der Unabh�ngigkeit der zu Grunde liegenden Transportprotokolle. So ist es bspw. m�glich OBEX �ber TCP/IP zu verwenden. Dieses Verhalten sollte die Adaption des OOP Verfahrens auf andere Transportprotokolle wesentlich vereinfachen. F�r die Proof-Of-Concept Implementierung wurde OBEX �ber RFCOMM gew�hlt17. Eine paketorientierte �bersicht �ber die OOP Bibliothek ist in [Abb.: 3.2] zu sehen.
Abbildung 3.2: Paket�bersicht der OBEX Object Passing Bibliothek
Der Aufbau der Bibliothek ist relativ simpel gehalten. Das >>oop<< Paket beinhaltet lediglich das Interface der Bibliothek sowie die Konstanten. Das >>util<< Paket beinhaltet Klassen, die zur Realisierung der Bibliothek notwendig waren. Das >>impl<< Paket beinhaltet diejenigen Klassen, welche die �bertragung der Daten letzten Endes realisieren. Das >>exceptions<< Paket enth�lt die von der OOP Bibliothek definierten Ausnahmen. Die Funktionalit�t der Klassen der jeweiligen Pakete wird im folgenden erl�utert.

3.2.1  Paket >>oop<<

Wie in [Abb.: 3.3] zu sehen ist, befinden sich lediglich zwei Klassen im >>oop<< Paket. Die Klassen haben folgende Funktionalit�t:
IObexObjectPassing
Dieses Interface muss von Entit�tsobjekten, welche die Daten kapseln, implementiert werden, um �bertragen werden zu k�nnen. Es zwingt den Programmierer dazu, die Methoden setObjectData(byte[] objectData) und getAsByteArray() zu implementieren, die zur korrekten Funktionsweise der Bibliothek notwendig sind.
Constants
Diese Klasse enth�lt die in der Bibliothek verwendeten Konstanten, sodass diese an einer zentralen Stelle ge�ndert werden k�nnen.
Abbildung 3.3: Klassen des >>oop<< Pakets
Durch Implementierung des IObexObjectPassing Interfaces ist zus�tzlich eine einfache Weiterverarbeitung der Daten m�glich, sollen diese persistent auf dem Ger�t gespeichert werden. Begr�ndet werden kann dies durch die Limiterung, welchen den mobilen Endger�ten auferlegt ist. Da sie laut der CLDC keine Kenntnis eines Dateisystems vorweisen m�ssen18, ist ein alternativer Mechanismus im MIDP zur Verf�gung gestellt worden; das RMS19. Lese- und Schreiboperationen auf das RMS k�nnen jedoch ausschliesslich in Byte-Str�men durchgef�hrt werden. Durch die Implementierung der IObexObjectPassing Schnittstelle sind die Entit�tsobjekte bereits auf diese Aufgabe vorbereitet. Auf den Umgang mit dem RMS soll an dieser Stelle jedoch nicht n�her eingegangen werden20.

Die Bibliothek wurde bewusst mit einer Schnittstelle und nicht als abstrakte Basisklasse modelliert. Gem�ss Balzert wird eine Schnittstelle wie folgt beschrieben:
„Es werden funktionale Abstraktionen in Form von Operationssignaturen bereitgestellt, die das >>Was<<, aber nicht das >>Wie<< festlegen. Eine Schnittstelle besteht also im Allgemeinen nur aus Operationssignaturen, d. h. sie besitzt keine Operationsr�mpfe und keine Attribute. Schnittstellen k�nnen jedoch in Vererbungsstrukturen verwendet werden. Eine Schnittstelle ist �quivalent zu einer Klasse, die keine Attribute und ausschlie�lich abstrakte Operationen besitzt.“ [Bal00, S. 817]
Da in der Java Programmiersprache allerdings der Mechanismus der Mehrfachvererbung nicht vorgesehen ist, w�re die Modellierung als abstrakte Basisklasse f�r den Programmierer unvorteilhaft gewesen, da eine Schnittstelle, im Gegensatz zur abstrakten Basisklasse, auf n-ter Stufe der Erbhierarchie implementiert werden kann, wohingegen die abstrakte Basisklasse an der Wurzel der Erbhierarchie implementiert werden m�sste.

3.2.2  Paket >>impl<<

Wie in [Abb.: 3.5] zu erkennen ist leiten diejenigen Klassen, die zur �bertragung verwendet werden, von der Observer Klasse im >>util<< Paket ab. Das Observer-Pattern, oder zu deutsch Beobachter-Muster, erm�glicht es, Klassen, die von einem Objekt abh�ngig sind, zu informieren, dass sich der Zustand des zu �berwachenden Objekts ge�ndert hat. Dieses Pattern wird h�ufig in der Programmierung graphischer Oberfl�chen eingesetzt, wenn eine graphische Repr�sentation der Daten automatisch ge�ndert werden soll, sobald sich der Datenbestand �ndert. Die Struktur des Patterns ist in [Abb.: 3.4] abgebildet.
Abbildung 3.4: Struktur des Observer-Patterns (Vgl. : [Bal00, S. 849])
Die Klassen ObjectPusher, ObjectReceiver und BulkObjectPusher aus [Abb.: 3.5] stellen dabei die in [Abb.: 3.4] als Concrete Subject bezeichnete Klasse dar.
Abbildung 3.5: Klassen des >>impl<< Pakets
Die Funktionalit�t der im >>impl<< Paket enthaltenen Klassen ist folgende:
ObjectReceiver
Die ObjectReceiver Klasse wird verwendet um Objektdaten, die von der ObjectPusher Klasse versandt wurden, zu empfangen, um sie dann in einem Speicher empfangener Objekte abzulegen.
ObjectPusher
Die ObjectPusher Klasse dient dem Zweck ein Objekt, welches das Interface IObexObjectPassing implementiert, zu versenden.
BulkObjectPusher
Die Klasse BulkObjectPusher ist, wie der Name schon andeutet, dazu gedacht mehrere Objekte sequenziell in einem Aufruf zu �bertragen.
ReceiverRequestHandler
Diese Klasse ist notwendig, da in Java die M�glichkeit der Mehrfachvererbung nicht gegeben ist. Sie wird innerhalb der Klasse ObjectReceiver verwendet und bei der Initiierung einer Verbindung durch einen Client instanziert. Die Behandlung der PUT Anfrage21 wird durch sie durchgef�hrt.
Den Klassen ObjectReceiver, ObjectPusher und BulkObjectPusher ist gemein, dass sie in einem separaten Thread ablaufen. Dies ist bei der Anwendung der Klassen von Vorteil, da sie den weiteren Programmablauf nicht st�ren. Der Transfer der Daten wird dadurch im Hintergrund durchgef�hrt. Um �ber die Beendigung des Datentransfers informiert zu werden, muss die aufrufende Klasse das Interface Observer implementieren. Die Verwendung der angesprochenen Klassen ist auch ohne Implementierung des Observer Interfaces m�glich, jedoch verliert man die M�glichkeit �ber die Beendigung der �bertragung informiert zu werden.

3.2.3  Paket >>util<<

Im Paket >>util<< sind diejenigen Klassen enthalten, die nicht in direktem Zusammenhang zur Implementierung stehen, jedoch zur Umsetzung derer notwendig waren [Abb.: 3.6].
Abbildung 3.6: Klassen des >>util<< Pakets
Observer
Diese Klasse implementiert die in [Abb.: 3.4] dargestellte Observer Klasse. Die Implementierung ist an die aus der J2SE bekannte java.util.Observer Klasse angelehnt. Beim Entwurf der Klasse wurde auf Signaturgleichheit der Methoden geachtet.
Observable
Diese Klasse implementiert die in [Abb.: 3.4] dargestellte Subject Klasse. Die Implementierung ist an die java.util.Observable Klasse aus der J2SE angelehnt. Ebenso wie bei der Observer Implementierung wurde auf die Signaturgleichheit der Methoden geachtet.
OOPFinder
Diese Klasse ist hilfreich, wenn die Methode DiscoveryAgent.selectService() von der verwendeten JSR-82 Implementierung nicht unterst�tzt wird22. Diese Klasse stellt die Methode getConnectionURL() bereit, welche das Verhalten der Methode DiscoveryAgent.selectService() imitiert.
InspectBT
Diese Klasse stellt die Methode getAllProperties() zur Verf�gung, mit deren Hilfe s�mtliche Eigenschaften des zu Grunde liegenden Bluetooth-Systems als String erhalten werden k�nnen. S�mtliche abgefragten Eigenschaften sind dabei, inklusive Erkl�rung, in [Tab.: 2.6] aufgelistet.
M�chte man auf einem J2SE System aus bestimmten Gr�nden die Observable und Observer Klassen der J2SE verwenden, m�ssen, dank der Signaturgleichheit der Klassen, lediglich die import Anweisungen der Bibliothek angepasst werden.

3.2.4  Paket >>exceptions<<

Das >>exceptions<< Paket definiert die in der Bibliothek verwendeten Ausnahmen. Das Paket enth�lt momentan lediglich eine Ausnahme [Abb.: 3.7].
Abbildung 3.7: Klassen des >>exceptions<< Pakets
ObjectNotPassableException
Diese Ausnahme wird geworfen wenn das zu �bertragende Objekt die Schnittstelle IObexObjectPassing nicht implementiert.

3.3  Deus ex machina

Die Funktionsweise des OBEX Object Passing wird anhand des Sequenzdiagramms in [Abb.: 3.8] im Folgenden erkl�rt. Das dargestellte Diagramm zeigt den Versand eines einzelnen Datenobjekts. Auf den Versand mehrerer Datenobjekte, der durch den BulkObjectPusher realisiert ist, wird nicht eingegangen. Beim BulkObjectPusher wird lediglich f�r jedes zu �bertragende Objekt die Klasse ObjectPusher aufgerufen. Die Funktionsweise des ObjectReceivers wird im Zuge der Erkl�rung des ObjectPushers behandelt. Weitere Informationen zur Implementierung des ObjectReceivers sind in [Kapitel 3.3.1] zu finden.
Abbildung 3.8: ObjectPusher Sequenzdiagramm
Nach der Erzeugung des ObjectPusher Objekts ruft es, durch die interne Thread-Erzeugung, die Methode run() auf, in der die eigentliche Arbeit des Objekts verrichtet wird.
  1. [Schritt 1.1)] In diesem Schritt wird die URL der Verbindung ermittelt, um das mobile Endger�t ansprechen zu k�nnen.
  2. Die Verbindung zum entfernten Ger�t wird hergestellt und die Sitzung etabliert.
  3. Mit Hilfe der vorhandenen Sitzung wird ein HeaderSet erzeugt.
  4. In das erzeugte HeaderSet wird der Name der zu �bertragenden Klasse in das Feld HeaderSet.NAME gesetzt.
  5. Der OBEX Transfer wird er�ffnet und das HeaderSet zum entfernten Ger�t �bertragen.
  6. Nachdem ein Ausgabestrom ge�ffnet wurde, werden die Daten mit der Methode getAsByteArray() aus dem Objekt extrahiert und zum entfernten Ger�t �bertragen. Dieses liest die eintreffenden Daten und speichert sie zun�chst tempor�r in einer Variablen ab. Der ObjectReceiver erzeugt aus der im HeaderSet �bermittelten Information des Klassennamens, mit Hilfe des Classloaders ein neues Objekt des �bermittelten Typs. Nachdem die Erzeugung abgeschlossen ist, werden die empfangenen Daten mit Hilfe der Methode setObjectData() in das erzeugte Objekt geschrieben. Das Objekt wird im n�chsten Schritt in einem Vector gespeichert, sodass dieses sp�ter zug�nglich ist.
  7. Der Zustand des Objekts wird auf ge�ndert gesetzt, da die �bertragung der Daten abgeschlossen ist.
  8. Die angeschlossenen Observer werden �ber das Ende der �bertragung informiert. (Die Klasse BulkObjectPusher realisiert durch diese Benachrichtigung ihr sequenzielles senden der Objekte).

3.3.1  ObjectReceiver

Die Implementierung des ObjectReceivers ver�ndert, bedingt durch die Tatsache, dass sie einen Dienst zur Verf�gung stellt, den Auffindbarkeitszustand des Ger�ts. Das Ger�t wird in den GIAC Modus23 versetzt, um permanent auffindbar zu sein. Ist dieses Verhalten nicht gew�nscht, so muss es, in der aktuellen Version der Bibliothek, im Quellcode ge�ndert werden. Die Registrierung des Dienstes in der SDDB24 wird von der avetanaOBEX Bibliothek, beim Aufruf der Methode OBEXConnector.open(), vorgenommen. Diese Registrierung ist notwendig, damit der OOP Dienst gefunden werden kann. Die Implementierung der avetanaOBEX Bibliothek weist an dieser Stelle jedoch einen kleinen Sch�nheitsfehler auf; so wird der Dienst in der SDDB als SPP Dienst, anstelle eines OBEX Dienstes eingetragen, was jedoch die Funktion nicht weiter st�rt.

Ist die �nderung des Auffindbarkeitszustands, sowie die Registrierung in der SDDB abgeschlossen, wartet das Objekt auf eingehende Verbindungen. Da bei einem eintreffenden Client ein nebenl�ufiger Prozess gestartet wird, erfolgt in der ObjectReceiver Klasse eine synchronisation der Prozesse des ReceiverRequestHandlers und der ObjectReceiver Klasse selbst. Der ObjectReceiver wartet auf die Termination der ReceiverRequestHandler Klasse bis er mit seiner Ausf�hrung fortf�hrt.

3.4  Tests

Es sind im Rahmen der Entwicklung der Bibliothek rudiment�re Tests durchgef�hrt worden. Diese Tests sind auf Grund des relativ hohen Einarbeitungsaufwands nicht mit einem automatisierten Test-Rahmenwerk wie z. B. JUnit25 durchgef�hrt worden. Tests sollten wegen der Affinit�t des Entwicklers zu seinem Projekt, normalerweise niemals vom Entwickler selbst durchgef�hrt werden. Da die Tests jedoch lediglich die w�hrend der Entwicklungsphase durchgef�hrten Testszenarien reflektieren, m�ge dies entschuldigt werden. Die durchgef�hrten Testf�lle sind in [Tab.: 3.1] zusammengefasst.
Testbeschreibung Erwartetes Ergebnis Test Erf�llt
Es wird versucht ein Objekt zu �bertragen, dass die Schnittstelle IObexObjectPassing nicht implementiert. Die �bertragung wird abgebrochen. Ja
Sind die Daten am Empfangsger�t korrekt rekonstruiert worden? Korrekte Rekonstruktion der Daten. Ja
Es existieren zwei Ger�te auf denen der Server ObjectReceiver gestartet wurde. Die Implementierung informiert den Anwender, dass mehrere Ger�te verf�gbar sind. Nein26
Es wird versucht zu senden, jedoch ist am Empfangsger�t keine ObjectReceiver Instanz erzeugt worden. Die Methode OOPFinder.getConnectionURL() liefert null. Ja
Wird nach einer abgelehnten Verbindung durch das BCC eine erneute R�ckfrage an den Benutzer gestellt? R�ckfrage wird erneut gestellt. Nein27
Besteht die M�glichkeit ObjectReceiver und BulkObjectPusher parallel auf einem Ger�t zu instanziieren? Beide k�nnen parallel gestartet werden. Ja
Tabelle 3.1: W�hrend der Entwicklung durchgef�hrte Testf�lle
Die Testreihe konnte auf Grund mangelnder Hardware nicht auf zwei reale Mobiltelefone ausgedehnt werden. Der Versuch mit Hilfe der Bibliothek Daten von einem Laptop auf ein Mobiltelefon zu �bertragen, schlug ebenfalls fehl. Das entfernte Ger�t konnte weder vom Laptop noch vom Mobiltelefon aus gefunden werden.

Eine Untersuchung der Eigenschaften des Ger�ts, mit Hilfe der Klasse InspectBT, f�rderte zu Tage, dass das verwendete Mobiltelefon (Nokia 6230) w�hrend es mit einem Ger�t gekoppelt ist, weder auf eine Suchanfrage antworten, noch eine initiieren kann. Dieses Verhalten jedoch ist f�r die korrekte Funktionsweise der OOP Bibliothek relevant.

Die verwendete JSR-82 Implementierung des Laptops lieferte bei allen abgefragten Eigenschaften null als Ergebnis. Das bedeutet, dass die Eigenschaft nicht implementiert ist oder die JSR-82 Implementierung falsch reagiert. Weiterhin bedeutet dies, dass selbst bei korrektem Verhalten des Mobiltelefons, immer noch die verwendete JSR-82 Implementierung fehlerhaft sein k�nnte.

1
Siehe https://www.jcp.org/en/jsr/detail?id=66
2
Architekturelle Einordnung siehe [Abb. 2.3, S. ??]
3
Siehe https://www.peer2me.org/
4
Erh�ltlich unter
5
Separat erh�ltlich unter https://java.sun.com/products/sjwtoolkit/
6
Anleitung zur Konfiguration der IDE unter [Has06]
7
Erh�ltlich unter
8
Siehe https://www.control.lth.se/~johane/harald/
9
Siehe https://www.javabluetooth.org/
10
Siehe https://www.sun.com/download/products.xml?id=43208d3d
11
Siehe https://www.rxtx.org/
12
Siehe [Kapitel 2.5.1]
13
Erh�ltlich unter https://sourceforge.net/projects/avetanaobex/
14
Siehe [Kapitel 2.3.2]
15
Erh�ltlich unter https://sourceforge.net/projects/bluecove/; Installationsanleitung unter [Lab06]
16
Siehe [Kapitel 2.1.3]
17
Siehe [Kapitel 2.5.8]
18
Siehe [Kapitel 2.3]
19
Siehe [Kapitel 2.4.1]
20
Eine Einf�hrung ist unter [Gho06] zu finden.
21
Siehe [Tab.: 2.8]
22
Dies ist z. B. beim BlueCove-Stack der Fall.
23
Siehe [Kapitel 2.4]
24
Siehe [Kapitel 2.5.5]
25
Erh�ltlich unter
26
Die Implementierung w�hlt das erste verf�gbare Ger�t.
27
Ergebnis ist abh�ngig von der Implementierung des BCC [M+05, S. 53]

Kapitel 4  Entwickeln mit OOP

In diesem Kapitel wird demonstriert, wie die OOP Bibliothek eingesetzt werden kann. Um die zur Demonstration entwickelte Beispielapplikation verstehen zu k�nnen, wird an dieser Stelle kurz auf die Grundlagen der J2ME Programmierung eingegangen. Die Kenntnis der Grundlegenden Sprachkonstrukte von Java sowie das Verst�ndnis einfacher Datenstrukturen und -container wird vorausgesetzt.

4.1  Grundlagen der J2ME Programmierung

Die J2ME ist, wie bereits in [Abb.: 2.3] gezeigt, im Java Umfeld einzuordnen. Java Programme, die auf einem mobilen Endger�t ausgef�hrt werden k�nnen, werden als MIDlets bezeichnet. Die Namensgebung folgt aus dem Zusammenschluss von MID (Mobile Information Device) und Applet. Der haupts�chliche Unterschied zur J2SE besteht im limiterten Sprachumfang der J2ME. Der signifikante Unterschied der beiden Umgebungen ist auf die Beschaffenheit der Hardware zur�ckzuf�hren, die wie bereits in [Kapitel 2.3] und [Kapitel 2.5.1] gezeigt, im J2ME Umfeld mit starken Einschr�nkungen belegt ist.

4.1.1  Lebenszyklus eines MIDlets

Jedes MIDlet ist gezwungen von der MIDlet Klasse zu erben. Sie erm�glicht das korrekte starten, stoppen und aufr�umen des MIDlets. Eine MIDlet darf, im Gegenteil zu J2SE Programmen, nicht �ber eine public static void main() Methode verf�gen. Ist dies trotzdem der Fall wird sie von der Application Management Software (AMS) ignoriert [VW02, S. 438].

Die AMS ist Bestandteil des Betriebssystems des mobilen Endger�ts. Sie erm�glicht die Ausf�hrung des MIDlets (und ggf. auch die Installation/Deinstallation dessen). Weiterhin ist die AMS in der Lage das MIDlet zu pausieren oder es zu stoppen. Der Zustandsautomat eines MIDlets ist in [Abb.: 4.1] dargestellt.
Abbildung 4.1: Zustandsautomat eines MIDlets (Vgl.: [VW02, S. 440])
Die Struktur des Zustandsautomaten wird im Code durch die an den Zustand�berg�ngen in [Abb.: 4.1] annotierten Methoden realisiert. Das Betriebssystem ist dadurch in der Lage beim Eintreffen eines externen Ereignisses, wie z. B. einem eingehenden Anruf, die Methode pauseApp() aufzurufen, durch die das MIDlet bis zu Fortf�hrung pausiert wird. [Listing 1] zeigt ein einfaches „Hello World“ MIDlet um den Sachverhalt zu verdeutlichen.

Listing 1: Hello World MIDlet

package hello; import javax.microedition.midlet.*; 5 import javax.microedition.lcdui.*; public class Test extends MIDlet { private TextBox tf; 10 public Test() { tf = new TextBox("Hello", "World", 20, TextField.UNEDITABLE); } public void startApp() { 15 Display.getDisplay(this).setCurrent(tf); } public void pauseApp() {} public void destroyApp(boolean unconditional) {} 20 }


4.1.2  User-Interface Entwicklung

Um die User-Interface Entwicklung eines MIDlets zu vereinfachen, kann ein sogenannter Screen Designer eingesetzt werden. Die Netbeans Entwicklungsumgebung bietet einen solchen mit dem Mobility Pack an1. Des weiteren bietet es einen sogenannten Flow Designer, mit dessen Hilfe einzelne „Seiten“, sogenannte Forms, leicht untereinander verk�pft werden k�nnen. M�chte man keine Spiele oder Programme mit anspruchsvollen graphischen Elementen entwickeln, l�sst sich mit den dargebotenen Werkzeugen relativ schnell das Frontend einer Applikation entwickeln. Um das Basisset der graphischen Elemente dennoch mit einer ansprechenderen Optik zu versehen, wurde das J2ME Polish2 Projekt ins Leben gerufen. J2ME Polish l�sst sich, zumindest laut Angabe der Entwickler, ebenfalls in die Netbeans IDE integrieren3.
Abbildung 4.2: Netbeans Flow Designer
Die [Abb.: 4.2] zeigt den Flow Designer f�r ein „Hello World“ Projekt. Wie zu sehen ist, verbindet man den Startpunkt der Applikation direkt mit der nach dem Start des MIDlets anzuzeigenden Form. Wird der mit Exit beschriftete Button des MIDlets gedr�ckt, terminiert die Applikation. Die Handhabung der Netbeans IDE, bez�glich der Applikationsentwicklung im J2ME Umfeld, soll an dieser Stelle nicht weiter vertieft werden4.

4.2  Projektorganisation

Wie bei jedem gr�sseren Projekt, ist es auch bei der Entwicklung von Applikationen f�r mobile Endger�te sinnvoll, f�r die verwendeten Entit�tsobjekte eine Bibliothek zu erzeugen. Dadurch kann eine mehrfache Implementierung der Entit�tsobjekte f�r differente Plattformen vermieden werden. M�chte man also eine Applikation entwickeln, die es erm�glicht, Daten zwischen einem Desktop-Computer und einem mobilen Endger�t auszutauschen, ist dieser Ansatz jedem anderen vorzuziehen. Da die OOP Bibliothek in der Lage ist, sowohl im J2SE, als auch im J2ME Umfeld zu operieren, bietet es sich an diese Form der Projektorganisation prinzipiell zu verwenden, da man sich so die M�glichkeit offen h�lt, einen Client f�r andere Plattformen zu implementieren. Eine beispielhafte Projektkonfiguration ist dann wie folgt gestaltet.
MeineApplikation-J2ME
Dieses Projekt beinhaltet den Code der notwendig ist, um die Logik und die Anzeige des mobilen Endger�ts entsprechend der Anforderung zu manipulieren.
MeineApplikation-J2SE
Dieses Projekt beinhaltet den Code der Applikationslogik sowie die notwendigen Manipulationen der Anzeige, um eine �nderung der Entit�tsobjekte zu erm�glichen.
MeineApplikation-Entit�tsobjekte
In diesem Projekt sind einzig die zu beiden Projekten geh�renden Entit�tsobjekte zu finden. Sollte eine �nderung der Entit�tsobjekte erfolgen, wirkt sich die �nderung unweigerlich auf beide Projekte aus, womit sich eine Duplikation des Codes vermeiden l�sst.

4.3  Beispielapplikation

Die Funktionsweise sowie der konkrete Einsatz der Bibliothek wird anhand einer J2ME Beispielapplikation demonstriert. Die Applikation ist bewusst sehr einfach gehalten. So existieren keine zus�tzlichen Forms mit deren Hilfe die Entit�tsobjekte manipuliert werden k�nnen. Eine Manipulation der Daten ist f�r die Demonstration nicht erforderlich. Die Applikation bietet allerdings die M�glichkeit zur visuellen Repr�sentation der Daten, damit die korrekte �bertragung derer verifiziert werden kann.

Die Beispielapplikation ist mit Hilfe des in Netbeans integrierten Emulators entwickelt worden. Zur Demonstration der Bibliothek muss der Emulator zweimal gestartet werden. Durch die F�higkeit des Emulators eine Bluetooth-Schnittstelle zu emulieren, kann die Applikation ohne einen vorhandenen Bluetooth-Stack getestet werden. Netbeans ist allerdings nicht in der Lage die Bluetooth-Schnittstelle von einer J2SE Applikation auf ein J2ME Projekt zu emulieren, weswegen sich die Beispielapplikation auf ein J2ME Programm beschr�nkt.

Die Funktionsweise des Programms ist relativ einfach. Nachdem das Projekt in Netbeans importiert wurde, muss das Programm zweimal gestartet werden. Auf einem der beiden simulierten Ger�te wird nun der Empfangsdienst gestartet. Man kann sich nun auf Wunsch die vorhandenen Daten anzeigen lassen. Das Programm reagiert mit einer Fehlermeldung, dass keine Daten vorhanden sind. Auf dem anderen Ger�t wird im n�chsten Schritt die �bertragung der (im Code konfigurierten) Daten veranlasst. Ist die �bertragung der Daten abgeschlossen, wird ein Dialogelement angezeigt, welches das Ende der �bertragung signalisiert. Auf dem empfangenden Ger�t k�nnen die Daten jetzt angezeigt werden. Die Zustands�berg�nge der Beispielapplikation sind in [Abb.: 4.3], ein bebilderter Ablauf in [Abb.: 4.4] dargestellt.
Abbildung 4.3: Zustands�berg�nge der J2ME Beispielapplikation
Da innerhalb der Applikation keine M�glichkeit besteht die zu �bertragenden Daten zu manipulieren bzw. zu setzen, werden die Daten innerhalb des Programmcodes direkt zugewiesen. Die Konfiguration eines Person Objekts, das die Schnittstelle IObexObjectPassing implementiert, erfolgt wie in Listing [Listing 2] gezeigt. Das Beispiel zeigt wie zwei Person Objekte konfiguriert, und anschliessend mit der Klasse BulkObjectPusher versendet werden k�nnen.

Listing 2: Verwendung von BulkObjectPusher

Person p = new Person(); p.setName("Schneider"); p.setVorname("Rosemarie"); p.setAge(37); 5 Person hans = new Person(); hans.setName("Peter"); hans.setVorname("Hans"); hans.setAge(37); 10 Vector transferringObjects = new Vector(); transferringObjects.addElement(p); transferringObjects.addElement(hans); 15 new BulkObjectPusher(transferringObjects).addObserver(this);


Die Klassen der OOP Bibliothek sind in ihrer Anwendung sehr einfach. Der in [Listing 2] gedruckte Code f�hrt den Transfer der Daten in Zeile 15 durch. Wie zu sehen ist, wird die Klasse ohne Zuweisung initialisiert. Eine Zuweisung auf eine lokal verf�gbare Variable ist nicht notwendig. Durch den an die Klasse angeschlossenen Observer5 ist es m�glich, �ber das Ende der Daten�bertragung informiert zu werden. Es ist weiterhin zu erkennen, dass dem Objekt keine Zieladresse �bergeben wurde. Das ist ebenfalls nicht notwendig, da die Bibliothek in der Lage ist, ihren Kommunikationspartner selbstst�ndig zu lokalisieren.

Um auf dem entfernten Ger�t Daten empfangen zu k�nnen muss der ObjectReceiver instanziiert werden. Er ist, ebenso wie die Klassen ObjectPusher und BulkObjectPusher nicht blockierend implementiert.
Listing 3: Verwendung von ObjectReceiver

Vector receivedObjects = new Vector(); new ObjectReceiver(receivedObjects);


Der vorgestellte Code in [Listing 3] empf�ngt die �bertragenen Objekte und speichert sie in den Vector receivedObjects, aus dem die empfangenen Daten zu einem sp�teren Zeitpunkt wieder ausgelesen und weiterverabeitet werden k�nnen.

Damit dies alles m�glich ist, muss das zu �bertragende Objekt lediglich das Interface IObexObjectPassing implementieren. Ein partieller Ausschnitt der Implementierung des Person Objekts ist in [Listing 4] dargestellt. Die restlichen Methoden sind ausschliesslich Accessor/Mutator Methoden des Objekts.

Listing 4: Implementierung von IObexObjectPassing

public byte[] getAsByteArray() { bout = new ByteArrayOutputStream(); dout = new DataOutputStream( bout ); 5 byte[] ret = null; try { /* Write values */ 10 dout.writeUTF(name); dout.writeUTF(vorname); dout.writeInt(age); dout.flush(); 15 /* do temp copy so we can close * the writers */ ret = bout.toByteArray(); dout.close(); 20 bout.close(); } catch (IOException ex) { ex.printStackTrace(); 25 } return ret; } 30 public void setObjectData(byte[] ba) { bin = new ByteArrayInputStream(ba); din = new DataInputStream(bin); try 35 { this.name = din.readUTF(); this.vorname = din.readUTF(); this.age = din.readInt(); 40 din.close(); bin.close(); } catch (IOException ex) { 45 ex.printStackTrace(); } }


Die wichtigsten Elemente, des in [Listing 4] dargestellten Codes sind die Zeilen 10-12 sowie die Zeilen 36-38. Mit diesen Zeilen werden die Daten des Objekts in ein Byte-Array geschrieben (10-12) und k�nnen ebenfalls von einem Byte-Array gelesen werden (36-38). Dieser Mechanismus ist zur korrekten Funktionsweise der OOP-Bibliothek notwendig6.

Der Ablauf der Beispielapplikation ist in [Abb.: 4.4] dargestellt. Da die Applikation auf zwei Mobiltelefonen gestartet werden muss, wird im Begleittext das jeweilige Ger�t mit >>1<< oder >>2<< markiert. Ist keine Markierung angegeben, so bezieht sich die Anzeige auf beide Telefone.
[Auf beiden Telefonen muss zun�chst das Programm mittels “Launch” gestartet werden.]

[Anzeige nach dem Programmstart.]

[>>1<< Der Server muss gestartet werden.]

[>>1<< Der Start des Servers muss einmalig best�tigt werden, da ein Zugriff auf das Bluetooth API erfolgt.]

[>>1<< Die vorhandenen Daten sollen angezeigt werden.]

[>>1<< Es sind keine Daten verf�gbar, mit “Back” verlassen]

[>>2<< Daten sollen �bertragen werden.]

[>>2<< Zum senden “Send” w�hlen.]

[>>2<< Der Zugriff auf das Bluetooth API muss einmalig best�tigt werden.]

[>>2<< Die �bertragung wird best�tigt, mit “Done” verlassen.]

[>>1<< Empfangene Daten k�nnen angezeigt werden.]

Abbildung 4.4: Ablauf der Beispielapplikation
1
Entwicklungsumgebung und Mobility Pack k�nnen unter https://www.netbeans.org bezogen werden.
2
Siehe https://www.j2mepolish.org/
3
Siehe https://www.j2mepolish.org/docs/install.html#netbeans5
4
Eine Einf�hrung in die MIDP Entwicklung mit Hilfe des Mobility Packs f�r Netbeans ist unter [Net06] zu finden.
5
Siehe [Kapitel 3.2.2]
6
Siehe [Kapitel 3.3]

Kapitel 5  Konklusion und Ausblick

Durch den Einsatz der OOP Bibliothek wird die Entwicklung von Applikationen, die Daten �ber eine Bluetooth Funkstrecke versenden m�chten, wesentlich vereinfacht. Durch die Implementierung des von der Bibliothek vorgegebenen Interfaces erh�lt man zus�tzlich die M�glichkeit, die erstellten Objekte direkt mit dem RMS zu verwenden, was den Zugewinn durch den Einsatz der Bibliothek erh�ht.

Die notwendigen Zeilen Code, die normalerweise zum Verbindungsauf- und -abbau geschrieben werden m�ssten, sinken durch den Einsatz der Bibliothek auf ein Minimum. Mit welchem minimalen Aufwand eine Applikation erstellt werden kann, die in der Lage ist Daten zu einem entfernten Endger�t zu senden, ist in Kapitel 4 demonstriert worden. Wieviel Aufwand es bedeuten w�rde die selbe Applikation mit Hilfe des Peer2Me Frameworks zu entwickeln, konnte auf Grund der sp�ten Entdeckung, nicht evaluiert werden.

Beim Umgang mit der Bluetooth-Technologie war festzustellen, dass sich die Anwendungsentwicklung f�r mobile Endger�te, teilweise problematisch darstellt. So ist bspw. bei vielen Mobiltelefonen der JSR-82 lediglich teilweise implementiert, was zur Folge hat, dass die OBEX Bibliotheken nachger�stet werden m�ssen, was auf Kosten der geringen Speicherkapazit�t der Ger�te teuer erkauft werden muss. Die strikten Sicherheitsmechanismen der J2ME Architektur legen einem in diesem Fall ebenfalls Steine in den Weg. So ist eine globale Nachr�stung der OBEX-Funktionalit�t, auf Grund des Verbots der nachtr�glichen Installation externer Bibliotheken, nicht m�glich. Als weiteres Problem stellt sich die Vielzahl verf�gbarer Bluetooth-Stacks dar. M�chte man eine Applikation f�r ein Desktop-System schreiben, so muss f�r fast jeden verf�gbaren Bluetooth-Stack eine entsprechende Bin�rdatei zur Verf�gung gestellt werden.

Die Sicherheit der Bluetooth-Architektur sollte jedoch nicht �bersch�tzt werden. Die Behauptung, dass sich Bluetooth wegen seiner kurzen Distanz nur schwer abh�ren lasse, konnte erfolgreich widerlegt werden. Mit Hilfe spezieller Richtantennen ist es m�glich, Ger�te aus Entfernungen bis zu 1.6 Km anzusteuern und erfolgreich auszusp�hen [Zet04, S. 2]. Allein durch die Tatsache, dass es sich bei Bluetooth um eine Kurzstreckenfunktechnologie handelt, sollte man sich demnach nicht in falscher Sicherheit wiegen.

Bez�glich der Sicherheit der Bibliothek gilt es zu pr�fen, ob sich im konkreten Einsatz, der OBEX Header manipulieren l�sst, sodass das Ger�t dazu veranlasst werden kann, eine nicht den Daten zugeh�rige Klasse zu laden.

Durch die Transportprotokollunabh�ngigkeit des OBEX Protokolls l�sst sich die Bibliothek leicht auf andere Transportprotokolle portieren. Eine Weiterentwicklung der Bibliothek, die zus�tzliche Transportprotokolle unterst�tzt, w�re in diesem Zusammenhang vorstellbar. So w�re es in Zukunft denkbar, dass die eingangs erw�hnte „Einkaufszettel“-Applikation das mobile Endger�t �ber Bluetooth und den vorhandenen Desktop-Computer �ber TCP/IP ansteuert.

Anhang A  Entwicklungsumgebung

Im Folgenden wird beschrieben, wie sich die entwickelte Bibliothek innerhalb der Netbeans IDE einsetzen l�sst. Die Beschreibung umfasst dabei die Erzeugung eines neuen Projektes welches die Bibliothek verwendet, sowie die notwendigen Schritte um die Beispielapplikation in Betrieb zu nehmen.

A.1  Anlegen eines J2ME Projekts mit OOP

Nachdem die IDE gestartet ist, kann mit der Tastenkombination >>Strg+Shift+n<< ein neues Projekt er�ffnet werden. Man w�hlt nun, wie in [Abb.: A.1] gezeigt, „Mobile“→„Mobile Application“ und f�hrt mit dem „Next“ Button fort.
Abbildung A.1: Neue Applikation anlegen
Als n�chstes zeigt sich einem der Dialog aus [Abb.: A.2], in dem man einen Projektordner, sowie einen Namen f�r das Projekt spezifiziert. Die Erzeugung des „Hello MIDlets“ kann deaktiviert werden, bleibt jedoch in diesem Beispiel aktiv.
Abbildung A.2: Applikation benennen
Der Dialog kann jetzt mit einem Klick auf „Finish“ beendet werden. Anschliessend zeigt sich einem [Abb.: A.3].
Abbildung A.3: Arbeitsplatz nach anlegen der Applikation
Nachdem die Applikation erzeugt wurde, wird gem�ss der Projektorganisation aus [Kapitel 4.2] eine Entit�sbibliothek erzeugt. Durch die Tastenkombination >>Strg+Shift+n<< wird erneut der „New Project“ Dialog ge�ffnet. Diesmal f�llt die Auswahl jedoch auf „Mobil“→„Mobile Class Library“, wie in [Abb.: A.4] zu sehen ist.
Abbildung A.4: Entit�tsbibliothek anlegen
Man spezifiziert f�r die Bibliothek, wie in [Abb.: A.5] gezeigt, ebenfalls einen Namen und einen Projektordner und beendet den Dialog mit einem Klick auf „Finish“.
Abbildung A.5: Entit�tsbibliothek benennen
Der vorzufindene Arbeitsplatz sieht nun aus wie in [Abb.: A.6] dargestellt.
Abbildung A.6: Arbeitsplatz nach anlegen der Entit�tsbibliothek
Als n�chstes muss die OOP Bibliothek Netbeans bekannt gemacht werden. Dies geschieht �ber den „Library Manager“ der durch die Tastenkombination >>Alt+t+l<< ge�ffnet werden kann. In dem folgenden Dialog selektiert man „Mobile Libraries“, und klickt auf „New Library“, woraufhin ein neuer Dialog erscheint, in dem der Name der Bibliothek eingetragen werden muss (siehe [Abb.: A.7]).
Abbildung A.7: Erzeugen einer neuen Bibliothek („Library Manager“)
Ist dieser Schritt abgeschlossen muss der Bibliotheksbezeichnung noch ein Java-Archiv (JAR) hinzugef�gt werden. Dies geschieht durch einen Klick auf „Add JAR“. In dem aufkommenden Dialog muss nun die JAR-Datei der OOP Bibliothek von dem lokalen Dateisystem gew�hlt werden (ObexObjectPassing.jar). Ist dieser Schritt abgeschlossen, zeigt sich einem [Abb.: A.8]
Abbildung A.8: JAR Datei selektiert und hinzugef�gt
Die Bibliothek ist Netbeans nun bekannt und kann in den der IDE bekannten Projekten verwendet werden. Die Bibliothek muss zun�chst dem Entit�tsprojekt zugeordnet werden. Dazu klickt man mit der rechten Maustaste auf das Entit�tsprojekt, und selektiert, wie in [Abb.: A.9] gezeigt „Libraries & Resources“. Dort ordnet man die Bibliothek mit einem Klick auf „Add Library“ dem Projekt zu.
Abbildung A.9: Bibliothek zum Entit�tsprojekt hinzuf�gen
Nachdem die Bibliothek mit einem Klick auf „Add Library“ und „Ok“ hinzugef�gt wurde, muss die Entit�tsbibliothek dem J2ME Projekt zugeordnet werden. Dazu w�hlt man , nach einem Rechtsklick auf das J2ME Projekt „Properties“→„Libraries & Resources“. Das Entit�tsprojekt kann nun, mit einem Klick auf „Add Project“ vom lokalen Dateisystem gew�hlt werden (siehe [Abb.: A.10]).
Abbildung A.10: Entit�tsprojekt der Applikation hinzuf�gen
Damit die OOP Bibliothek auch in der J2ME-Anwendung zur Verf�gung steht muss sie, nach dem obligatorischen Rechtsklick, und der Wahl von „Properties“→„Libraries & Resources“, mit der Selektion von „Add Library“ hinzugef�gt werden.
Abbildung A.11: OOP Bibliothek der Applikation hinzuf�gen
Nach einem Klick auf „Add Library“→„Ok“ ist die Bibliothek korrekt in das Projekt eingebunden worden. Ab diesem Zeitpunkt kann entwickelt werden.

A.2  Beispielapplikation in Betrieb nehmen

Um die Beispielapplikation in Betrieb zu nehmen, m�ssen die Dateien IOOP2.zip, IOOPEntityLib.zip, ObexObjectPassingSrc.zip und avetanaObex.jar auf dem lokalen Dateisystem – mit Ausnahme der JAR Datei – entpackt werden.

Ist dies geschehen, muss die avetanaOBEX Bibliothek unter dem Namen „avetanaOBEX“ im „Library Manager“ der IDE unter „Mobile Libraries“ registriert werden. Der Vorgang ist in [Abb.: A.7] und [Abb.: A.8] bebildert und wird in [Kapitel A.1] f�r ein neues Projekt beschrieben. Ist der Import der Bibliothek abgeschlossen, k�nnen die drei Projektordner mit der Tastenkombination >>Strg+Shift+o<< ge�ffnet, und der IDE hinzugefuegt werden. Hat alles geklappt muss ggf. das „IOOP“ Projekt mit der rechten Maustaste als „Set Main Project“ markiert werden. Die Applikation kann anschliessend durch einen Tastendruck auf >>F6<< augef�hrt werden. Es ist zu beachten, dass zur korrekten Demonstration, wie sie in [Abb.: 4.4] dargestellt wird, das Projekt zweimal gestartet werden muss.

Anhang B  Glossar und Abk�rzungsverzeichnis


A


ACL, S. 9
Asynchronous Connection-Oriented (logical transport)
ACL-C, S. 10
ACL Control
ACL-U, S. 10
User Asynchronous/Isochronous
AFH, S. 7
Adaptive Frequency-Hopping spread spectrum, Verfahren zur Reduktion der St�ranf�lligkeit gegen�ber anderen Funktechnologien (z.+.1667emB. WLAN)
AMS, S. 45
Application Management Software
API, S. 16
Application Programming Interface
ARQ, S. 10
Acknowledgement/Repeat Request
ASB, S. 9
Active Slave Broadcast (logical transport)




B


BCC, S. 23
Bluetooth Control Center, Zentrale Anlaufstelle welche die Bluetooth-Einstellungen des lokalen Ger�ts verwaltet.
BD_ADDR, S. 11
Bluetooth Device Address




C


CDC, S. 16
Connected Device Configuration
CID, S. 11
Channel Identifier
CLDC, S. 15
Connected Limited Device Configuration, Grundlage von J2ME. Geht aus den JSRs 30 und 139 hervor (Version 1.0/1.1)
CLDC HotSpot Implementation, S. 15
Nachfolgeimplementierung der KVM mit verbesserter Performanz (8-10x schneller)




D


Discovery, S. 25
dt. Entdeckung; bezeichnet den Prozess der es zwei Bluetooth-Ger�ten erm�glicht sich gegenseitig zu lokalisieren.




E


EDR, S. 7
Enhanced Data Rate
EJB, S. 31
Enterprise JavaBeans
eSCO, S. 9
Extended Synchronous Connection-Oriented (logical transport)
eSCO-S, S. 10
User Extended Synchronous




F


FTP, S. 9
File Transfer Protocol




G


GAP, S. 12
Generic Access Profile
GCF, S. 16
Generic Connection Framework, offeriert die M�glichkeit, auf Ein- und Ausgabeoperationen sowie Netzwerkressourcen zuzugreifen.
GFSK, S. 6
Gaussian Frequency Shift Keying, Bei Bluetooth oder DECT Technologie eingesetztes Modulationsverfahren.
GIAC, S. 13
General/Unlimited Inquiry Access Code
GOEP, S. 29
Generic Object Exchange Profile, Bluetooth-Profil welches das OBEX Protokoll implementiert.




H


HCI, S. 11
Host Controller Interface, befindet sich zwischen logischem und L2CAP-Layer und stellt eine einheitliche Schnittstelle zum Bluetooth-Controller dar.
HTTP, S. 28
Hypertext Transfer Protocol




I


ID, S. 19
Identifikationsnummer
IDE, S. 48
Integrated Development Environment
ISM, S. 6
Industrial, Scientific, and Medical Band




J


J2ME , S. 14
Java 2 Platform, Micro Edition
JABWT, S. 21
Java API for Bluetooth Wireless Technology
JSR, S. 15
Java Specification Request




K


KVM, S. 15
K Virtual Machine, manchmal auch Kilobyte Virtual Machine Virtuelle Maschine, die mit sehr geringen Hardwareanforderungen auskommt.




L


L2CAP, S. 11
Logical Link Control and Adaption Protocol
LC, S. 10
Link Control
LIAC, S. 13
Limited Dedicated Inquiry Access Code
LLID, S. 10
Logical Link Identifier, Feld im Basisband-Paketkopf um die logische Verbindung zu identifizieren
LM, S. 10
Link Manager, verantwortlich f�r die Erzeugung, Modifikation und Freigabe logischer Verbindungen.
LMP, S. 10
Link Manager Protocol, Protokoll, mit dessen Hilfe Kontrollinformationen zwischen den Link Manager Instanzen zweier Endger�te ausgetauscht werden k�nnen.




M


MID, S. 18
Mobile Information Device
MIDlet, S. 18
Programm, dass auf einem MID ausgef�hrt werden kann.
MIDP, S. 18
Mobile Information Device Profile
MTU, S. 24
Maximum Transfer Unit, Anzahl an Daten die unfragmentiert in einem Paket �bertragen werden k�nnen.




O


OBEX, S. 22
OBject EXchange (Protocol)
OEM, S. 22
Original Equipment Manufacturer
OOP, S. 32
OBEX Object Passing




P


PDA, S. 15
Personal Digital Assistant, kleiner Computer, der typischerweise in einer Handfl�che Platz findet.
PSB, S. 9
Parked Slave Broadcast (logical transport)




R


RAM, S. 22
Random Access Memory
RAND, S. 11
Pseudo-Random-Number, Pseudozufallszahl
RFCOMM, S. 27
Emulation mehrerer Serieller RS-232 Ports zwischen zwei Bluetooth-Ger�ten
RMI OP, S. 31
RMI Optional Package
RMS, S. 19
Record Management System, vom MIDP spezifizierter Mechanismus zur persistenten Speicherung von Daten
ROM, S. 22
Read Only Memory
RSSI, S. 7
Received Signal Strength Indicator




S


SCO, S. 9
Synchronous Connection-Oriented (logical transport)
SCO-S, S. 10
User Synchronous
SDDB, S. 25
Service Discovery Database
SDP, S. 22
Service Discovery Protocol
SDU, S. 11
Service Data Units
SPP, S. 27
Serial Port Profile




T


TCK, S. 22
Technology Compatibility Kits, Test-Suite die eine korrekte Implementierung der Spezifikation �berpr�fen kann.
TCP/IP, S. 35
Transmission Control Protocol/Internet Protocol




U


URL, S. 27
Uniform Resource Locator, einheitliche Ortsangabe f�r Ressourcen.




V


VM, S. 14
Virtual Machine, Programm, das f�r die entsprechende Plattform �bersetzten Bytecode interpretiert.




W


WLAN, S. 7
Wireless Local Area Network
WTK, S. 32
Wireless Toolkit, Ein Set an Emulatoren und zugeh�rigen Bibliotheken, welche die Entwicklung von Applikationen f�r mobile Endger�te erm�glicht.

Literatur

[Ano06]
Anonymous. HCI Layer Tutorial.
https://www.palowireless.com/. Jan. 2006

[Bal00]
Balzert, Helmut: Lehrbuch der Software-Technik. Bd. 1. 2. Auflage. Spektrum, Akad. Verl., 2000

[Bal05]
Baldwin, Richard G. Digital Signatures 101 using Java.
https://www.developer.com/. 2005

[Bec05]
Becker, Markus. Drahtlose lokale Netze (Ad-hoc / Bluetooth Kommunikation).
https://jerry.c-lab.de/. Jun. 2005

[BJJ04]
Bala Kumar, C ; J. Kline, Paul ; J. Thompson, Timothy: Bluetooth Application Programming with the Java APIs. Morgan-Kaufmann Verlag, 2004

[Blu03]
Bluetooth SIG. Specification of the Bluetooth System - Wireless connections made easy - Version 1.2.
https://bluetooth.org/. Nov. 2003

[Blu04]
Bluetooth SIG. Specification of the Bluetooth System - Wireless connections made easy - Version 2.0 + EDR.
https://www.bluetooth.org/. Nov. 2004

[Blu05]
Bluetooth SIG. Generic Object Exchange Profile.
https://www.bluetooth.org/. Feb. 2005

[Blu06]
Bluetooth SIG. Assigned Numbers - Bluetooth Baseband.
https://www.bluetooth.org/. Mar. 2006

[BSM06]
B�rki, Reto ; Sch�rer, Raffael ; M�ller, Martin: J2ME-Objektserialisierung: Frameworks im Vergleich. In: Java Spektrum (2006), Feb., Nr. 1, S. 35–38

[Bv05]
Bachfeld, Daniel ; Zivadinovic, Dusan: Wurzelbehandlung – Sicherheitsl�cken bei Bluetooth-Handys. In: c't - magazin f�r computer technik (2005), Dez., Nr. 26, S. 212–216

[C+05]
Courtney, Jon et al. Connected Device Configuration (CDC) 1.1.
https://jcp.org/. Aug. 2005

[Fit05]
Fitton, Dan. Java Bluetooth HOWTO.
https://www.caside.lancs.ac.uk/. Dez. 2005

[For04]
Forum Nokia Global Web Site. Introduction To The FileConnection API (With Example) v1.1.
https://www.forum.nokia.com/. Nov. 2004

[FS06]
Frey, Jens ; Schwarz, Matthias. Kryptographie - Skriptum zur Vorlesung.
https://www.coffeecrew.org/. Mar. 2006

[Gho06]
Ghosh, Soma. J2ME record management store.
https://www-128.ibm.com/. Mar. 2006

[Has06]
Hasik, Lukas. Mobility Pack on Mac.
https://blogs.sun.com/. Mar. 2006

[HHT03]
Handy, M. ; Haase, M. ; Timmermann, D. Der Verlust der informationellen Selbstbestimmung? Anonymit�tsaspekte bei Bluetooth und WLAN.
https://www.vs.inf.ethz.ch/. 2003

[Hol03]
Holtmann, Marcel. Bluetooth und ISDN unter Linux.
https://www.holtmann.org/. Sep. 2003

[Hop05a]
Hopkins, Bruce. Bluetooth boogies, Part 1: File transfer with JSR-82 and OBEX.
https://www-128.ibm.com/. Sep. 2005

[Hop05b]
Hopkins, Bruce. Bluetooth boogies, Part 2: Creating the Bluetooth Music Store.
https://www-128.ibm.com/. Nov. 2005

[Jar05]
Jarvi, Keane. RXTX: The Prescription for Transmission.
https://users.frii.com/. Jan. 2005

[Kje05]
Kjell, J.H. Bluetooth - Part 9: Service Discovery.
https://www.vs.inf.ethz.ch/. Apr. 2005

[Kr�00]
Kr�ger, Guido: GoTo Java2.
2. Auflage. Addison-Wesley Verlag, 2000. – Studentenausgabe

[Lab06]
Labaye, Denis. Bluecove documentation.
https://bluecove.sourceforge.net/. Jan. 2006

[LN05]
Lund, Carl-Hendrik W. ; Norum, Michael S.: The Peer2Me Framework - A Framework for Mobile Collaboration on Mobile Phones, Norwegian University of Science and Technology, Diplomarbeit, Jun. 2005

[M+05]
Milikich, Mike et al. JavaAPIs for BluetoothWireless Technology (JSR 82) - Specification Version 1.1.
https://www.jcp.org/. Sep. 2005

[MO03]
Mehta, Pratik ; O'Connor, Clint H. Personal Area Connectivity with BluetoothWireless Technology.
https://www1.jp.dell.com/. 2003

[Net06]
Netbeans Community. NetBeans Mobility Pack 5.0 Quick Start Guide.
https://www.netbeans.org/. Mar. 2006

[Sch96]
Schneier, Bruce: Angewandte Kryptographie: Protokolle, Algorithmen und Sourcecode in C. Addison-Wesley, 1996

[Sin01]
Sintes, Tony. Speaking on the Observer pattern.
https://www.javaworld.com/. May 2001

[Sin06]
Sintes, Tony. Vector or ArrayList – which is better and why?
https://www.javaworld.com/. Jan. 2006

[Son04]
Sony Ericsson. Developing Applications with the Java APIs for Bluetooth(JSR-82).
https://www.microjava.com/. Jan. 2004

[Sun00]
Sun Microsystems, Inc. J2ME Building Blocks for Devices.
https://java.sun.com/. May 2000

[Sun05]
Sun Microsystems, Inc. CLDC HotSpot Implementation Virtual Machine.
https://java.sun.com/. Feb. 2005

[Sun06]
Sun Microsystems, Inc. Java 2 Platform, Micro Edition.
https://java.sun.com/. Mar. 2006

[T+00]
Taivalsaari, Antero et al.
Connected, Limited Device Configuration. https://www.jcp.org/. May 2000

[T+03]
Taivalsaari, Antero et al. Connected Limited Device Configuration 1.1.
https://www.jcp.org/. Mar. 2003

[Van00]
Van Peursem, Jim. Mobile Information Device Profile (JSR-37).
https://www.jcp.org/. Sep. 2000

[VW02]
Van Peursem, Jim ; Warden, James. Mobile Information Device Profile for Java - Version 2.0.
https://www.jcp.org/. Nov. 2002

[Wik06a]
Wikipedia Community. Basisband.
https://de.wikipedia.org/. Mar. 2006

[Wik06b]
Wikipedia Community. Bluetooth.
https://de.wikipedia.org/. Mar. 2006

[Wik06c]
Wikipedia Community. ISM-Band.
https://de.wikipedia.org/. Feb. 2006

[Wik06d]
Wikipedia Community. Multiplexverfahren.
https://de.wikipedia.org/. Feb. 2006

[Wik06e]
Wikipedia Community. Multiplexverfahren.
https://de.wikipedia.org/. Mar. 2006

[Xil05]
Xilinx. Bluetooth HCI Bridging.
https://www.xilinx.com/. 2005

[Zet04]
Zetter, Kim. Security Cavities Ail Bluetooth.
https://www.wired.com/. Aug. 2004

Index

OBEX Object Passing Home (PDF) CCGLogo
This document was translated from LATEX by HEVEA.