Previous Up Next
OBEX Object Passing Home (PDF)

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]
OBEX Object Passing Home (PDF) CCGLogo
Previous Up Next