Kapitel 1 - TU Dresden

Fakultät Informatik, Institut für Systemarchitektur, Professur für
Rechnernetze
KOMPLEXPRAKTIKUM
J2ME / SOAP - VERSUCH
Betreuer:
Dipl.-Inf. Anja Strunk
-0-
1
Inhaltsverzeichnis
INHALTSVERZEICHNIS
2
KAPITEL 1
4
Praktikumsbeschreibung
1.1 Versuchziel
1.2 Aufgabenstellung
1.3. Versuchsdurchführung
4
4
4
5
KAPITEL 2
14
J2ME – Tutorial
14
KAPITEL 3
15
SOAP - Web Service– Tutorial
3.1 Einführung
3.2 Architektur und Clientzugriff
3.3 Implementierungstechnische Umsetzung von Web Services
15
15
15
18
Projektdokumentation
1.1 Serverapplikation
1.2 Clientapplikation
1.3 Abgabe der Lösungen
20
20
21
25
ANHANG A
getBooking.xsd
getFlight.xsd
26
26
27
Abkürzungsverzeichnis
30
Glossar
31
Abbildungsverzeichnis
32
Tabellenverzeichnis
33
Literaturverzeichnis
34
http://www.bstuder.ch/sppmc/v20_Tutorial_J2ME_ohne_loe.pdf
34
Goyal V.: „J2ME Tutorial“
34
Java. NET, The Source for Java Technology Collaboration, 2005.
34
2
3
Kapitel 1
Praktikumsbeschreibung
1.1 Versuchziel
Die Integration drahtloser Endgeräte in verteilte Anwendungen ist heute eine
Standardanforderung bei der Entwicklung von Softwaresystemen. Aufgrund ihres
Verwendungszwecks sind drahtlose Endgeräte jedoch mit beschränkten System- und
Hardwareressourcen ausgestattet. Engpässe gibt es z.B. in einer geringen Anzahl unterstützter
Netzwerkprotokolle und knapper CPU Leistung. Zudem liegen die Ressourcen stark
heterogen vor. Dies bedeutet, dass für jedes Endgerät eine speziell auf dessen Fähigkeiten
zugeschnittene Clientanwendung entwickelt werden muss.
Vorteilhafter ist natürlich die Erstellung einer endgerätunabhängigen Applikation. Java 2
Standard Edition (J2SE) unterstützt dies für drahtgebundene Endgeräte. Für drahtlose
Endgeräte hat SUN die so genannte Java 2 Micro Edition (J2ME) entwickelt. Diese Java
Virtual Maschine (JVM) ist speziell an die beschränkten Ressourcen drahtloser Endgeräte
angepasst.
Selbstverständlich kann die J2ME-JVM dem Programmier nur ein Mindestmaß an
Funktionalität zur Verfügung stellen. So sind z.B. komplexe Middleware-Konzepte zur
Realisierung verteilter Anwendungen (z.B. RMI1) nicht enthalten. Für die Kopplung
heterogener Systeme wird daher häufig die plattform- und programmiersprachenunabhängige
SOAP– bzw. Web Service Architektur eingesetzt.
Ziel des Versuchs ist es, Kenntnisse über die Technologie SOAP bzw. Web Services und
deren praktischen Einsatz im Rahmen einer verteilten Java Anwendung zu vermitteln.
Zusätzlich dazu soll der Student befähigt werden, J2ME-Anwendungen zu erstellen.
1.2 Aufgabenstellung
Als Realisierungsbeispiel oben genannter Techniken dient der bereits in den Versuchen
„Sockets“, „RMI“, „Corba“ und „EJB“ vorgestellte Anwendungsfall eines Flugbuchungssystems.
Mittels eines drahtlosen Endgerätes soll der Nutzer die Möglichkeit haben:

Flüge, die seinen Kriterien entsprechen zu suchen und zu buchen sowie

bereits gebuchte Flüge zu stornieren
Hierfür wird die Serviceapplikation als Web Service realisiert. Client und Server
kommunizieren über SOAP. Die Serverapplikation wird im JWSDP fähigen Tomcat 5.0 zur
Verfügung gestellt. Als Implementierungssprache dient Java.
1
Remote Method Invocation
4
Die Verwaltung von Flügen und bereits durchgeführten Buchung erfolgt in der AccessDatenbank „flugbuchung2.mdb“. Abbildung 1 veranschaulicht die Struktur der
Beispielanwendung.
JWSDP-Tomcat 5.0
SOAP / HTTP
Access
Datenbank
J2ME-Client
Nutzer
Java Web Service
Abbildung 1: physische Struktur der Beispielanwendung
1.3. Versuchsdurchführung
Die Client- und Serveranwendung ist bereits vorimplementiert. Sie muss nur noch an
ausgewählten Stellen ergänzt werden. Diese Stellen sind im Quellcode mit TODO
gekennzeichnet. Die Quellcode-Dateien können auf der Praktikums-Webseite heruntergeladen
werden.
Im Kapitel 4 „Projektdokumentation“ werden die Quellcodedateien sowie die konkreten
Aufgaben erläutert. Die notwendigen Komponenten für die Versuchsdurchführung findet man
unter
http://www.inf.tu-dresden.de/index.php?node_id=1786&ln=de&data=KR/J2MESOAP.html
Installation der Entwicklungsumgebung
Java SDK 5
Java SDK 5.x installieren. Der Versuch ist mit höheren Java-Versionen nicht kompatibel.
Tomcat 5.0 und JWSDP (Java Web Service Development Pack)
Als Web Service Container wird Tomcat 5.0 für JWSDP verwendet.
Installation:
1. Tomcat für JWSDP herunterladen und entpacken.
2. JWSDP 2.0 herunterladen und installieren, dabei
a. als JDK Java 1.5.x auswählen
b. als Web-Container Tomcat auswählen.
c. sonstige Standardeinstellungen übernehmen
J2ME Wireless Toolkit 2.5.2
Das J2ME Wireless Toolkit enthält geeignete Emulatoren zum Test von J2ME Anwendungen.
Für den Test der Clientanwendung ist ausschließlich der WTK 2.5.2 „DefaultColorPhone“
Emulator zu benutzen.
5
Installation:
1. J2ME Wireless Toolkit herunterladen und installieren, dabei
a. als JDK Java 1.5.x auswählen
Eclipse 3.3.1
Eclipse ist eine Entwicklungsumgebung für Java Programme. Um ein ständiges Kopieren der
Quelltextdateien zwischen Eclipse und WTK zu vermeiden, empfiehlt sich die Verwendung
des Ant-Werkzeuges Antenna 1.0.0.
Zur Integration von Tomcat und Eclipse dient das Tomcat-Plug-In von Sysdeo. Es ermöglicht
das Starten und Stoppen von Tomcat aus Eclipse heraus.
Installation
1. Eclipse 3.3.1 oder höher, Eclipse Tomcat Plug-In und Antenna (antenna.jar)
herunterladen.
2. Eclipse in gewünschtes Verzeichnis entpacken
3. Eclipse starten
4. Menü  Windows  Preferences… öffnen
5. Java  Compiler in der Baumansicht auswählen
6. „Compiler compliance level” 5.0 einstellen. Achtung: 6.0 sorgt für eine
BadClassVersion Exception beim kompilieren. (Siehe Abbildung 2)
6
Abbildung 2: Einstellen des Compiler Levels
7. Java  Installed JRE in der Baumansicht auswählen
8. JDK 1.5.x hinfügen (siehe Abbildung 3)
7
Abbildung 3: Einstellen von JDK 1.5.x - 1
9. JDK 1.5.x als Standard setzen (siehe Abbildung 4)
8
Abbildung 4: Einstellen von JDK 1.5.x - 2
10. Im Menü Windows  Preferences  Ant  Runtime auswählen
11. antenna-bin-0.9.13.jar unter Eclipse unter "Ant Home Entries (Default)“ hinzufügen
(siehe Abbildung 5)
12. Fehlermeldung ignorieren
9
Abbildung 5: Einbinden von Antenna in Eclipse
13. Tomcat Plug-in in den Ordner „plugin“ im Eclipse Home Verzeichnis entpacken
14. Eclipse neu starten. Die Menüleiste enthält nun 3 Icons zum Starten, Stoppen und
erneutem Starten von Tomcat (siehe Abbildung 6)
Abbildung 6: Tomcat Integration in Eclipse - GUI
15. Menüeintrag Window  Preferences… aufrufen
16. In Dialog Eintrag „Tomcat“ auswählen“
17. Die installierte Tomcat Version auswählen, in unserem Fall 5.x und den Pfad auf das
Tomcat Installationsverzeichnis eintragen (siehe Abbildung 7)
10
Abbildung 7: Integration von Tomcat in Eclipse - Tomcat
Datenbank integrieren
Die Datenbank speichert verfügbare Flüge und getätigte Buchungen.
Installation:
1. Systemsteuerung  Verwaltung  Datenquellen (ODBC)
2. Registerkarte „DSN-Benutzer“ aktiveren
3. Hinzufügen… (siehe Abbildung 8)
11
Abbildung 8: Hinzufügen der Datenbank „flugbuchung2.mdb“ - 1
4. Treibers „Microsoft Access Driver (*.mdb)“ auswählen
5. Datenbankquelle„flugbuchung2.mdb“ (siehe Abbildung 9).
12
Abbildung 9: : Hinzufügen der Datenbank „flugbuchung2.mdb“ – 2
Achtung:
Bei der Nutzung von Windows für x64 Systeme, muss folgender Befehl ausgeführt werden:
„%WINDIR%\SysWOW64\odbcad32.exe“
13
Kapitel 2
J2ME – Tutorial
Im Rahmen der Praktikumsdokumentation wird nicht näher auf J2ME eingegangen. Ein
detailliertes Tutorial findet sich unter:
http://today.java.net/pub/a/today/2005/02/09/j2me1.html?page=1
14
Kapitel 3
SOAP - Web Service– Tutorial
3.1 Einführung
Ein Web Service ist ein Web Server Dienst, der über das Internet aufgerufen werden kann und
als Antwort statt HTML-Code eine für Maschinen lesbare XML-Datei generiert. Dies
ermöglicht neben der Nutzung von Internetangeboten durch den Menschen auch deren
Anspruchnahme von Maschinen.
Ein prominentes Beispiel ist die Suchmaschine „Google“, welche ihren Recherchedienst nicht
nur dem Web Browser und damit Anwendern zur Verfügung stellt, sondern auch
anderweitigen Softwarekomponenten. Statt eines Eingabefeldes und einer tabellarischen
Ausgabe der Suchergebnisse, wird für die Maschine Anfrage und Antwort in einer XMLNachricht kodiert. (Vergleiche Abbildung 10)
HTML-Antwort
XML-Antwort
HTML-Anfrage
XML-Anfrage
Abbildung 10: Suchdienst von Google für Mensch und Maschine
3.2 Architektur und Clientzugriff
Web Services folgen, gemäß Abbildung 11, einer service-orientierten Architektur (SOA –
Service Oriented Architecture) bei der der so genannte Service-Provider einen Dienst
inklusive seiner Beschreibung bei einem Verzeichnisdienst veröffentlicht. Der ServiceKonsument kann bei diesem nach Diensten, die seinen Anforderungen entsprechen suchen.
Während dieser Suche wird auf die Servicebeschreibung des Providers zurückgegriffen. Als
Ergebnis erhält der Konsument den oder die zutreffenden Dienste zuzüglich aller für die
Inanspruchnahme notwendigen Informationen (z.B. Adresse). Er kann nun die Angebote der
Service Provider nutzen.
he
n
uc
rg
e
he
Verzeichnisdienst3
.:
E
:S
2.
:V
1.
fe
öf
r
e
lic
nt
bn
is
5.: XML-Antwort
4.: XML-Anfrage
Service Provider
Service Konsument
Abbildung 11: Architektur von Web Services: Grundprinzip, nach [Sev03]
15
Um die Interoperabilität heterogener Anwendungen zu unterstützen, war die Plattform-,
Protokoll- und Programmiersprachenunabhängigkeit oberste Priorität bei der Realisierung von
Web Services. Aus diesem Grund greifen alle für Kommunikation und Dienstbeschreibung
entwickelten Standards auf XML zurück, die durch eben diese Eigenschaften gekennzeichnet
ist.
SOAP definiert den Aufbau aller zwischen den drei Akteuren der Web Service Architektur
auszutauschenden Nachrichten. Jede Nachricht basiert hierbei auf einem standardisiertem
XML-File, welches in ein „Header“- und ein „Body“-Element aufgeteilt ist. Beides befindet
sich im so genannten „Envelope“-Element. Der Header dient der Aufnahme von Metainformationen über die Nutzdaten, während sich letztere als dienstspezifisches XML-File kodiert
im Body befinden. Zusätzlich ist es möglich einen Anhang (engl. Attachement) an die SOAP
Nachricht anzufügen, der Binärdaten des MIME2-Standards enthält. Abbildung 12 visualisiert
den Aufbau einer SOAP-Nachricht.
SOAP-Nachricht
Envelope
Attachement
Header
….<Metainformationen>
Non-text
Body
….<Nutzdaten>
text
Abbildung 12: Aufbau einer SOAP-Nachricht, nach [Zel03]
SOAP beschreibt lediglich den Aufbau der Daten und ist daher völlig unabhängig vom
zugrunde liegenden Übertragungsprotokoll. D.h. obwohl meist HTTP genutzt wird, ist die
Verwendung anderer Internetprotokolle wie SSL, FTP oder SMTP möglich, sofern diese
XML-Nutzdaten akzeptieren. (Vergleiche Abbildung 13)
SOAP
Anwendung
HTTP
SMTP
TCP
Transport
UDP
IP
Vermittlung
Netzzugang
…
FTP
Ethernet
Token Ring
FDDI
…
Abbildung 13: SOAP mit TCP / IP Protokollstapel, [Wik05d]
WSDL (Web Services Description Language) bildet den Standard für Servicebeschreibungen.
Sie definiert eine eindeutige XML-Grammatik zur Dokumentation von Web Services, die im
Allgemeinen:
2

die austauschbaren Dokumente, d.h. SOAP-Nachrichten für Anfrage und Antwort (=
Interfacebeschreibung des Dienstes),

die verwendeten Übertragungsprotokolle (meist HTTP) und
Multipurpose Internet Mail Extensions
16

die Adresse des Service-Providers (meist eine URL)
umfasst. Aus der vom Verzeichnisdienst erhaltenen WSDL-Datei erlangt der potentielle
Service-Konsument alle für die Nutzung des Web Services notwendigen Informationen.
WSDL-Dateien werden ebenfalls mittels SOAP zum Verzeichnisdienst bzw. von diesem zum
Dienstnutzer übertragen.
Als dezentraler Verzeichnisdienst steht UDDI (Universal Description Discovery and
Integration) zur Verfügung. UDDI bildet nicht nur einen öffentlichen Ort zum Registrieren
und Aufsuchen von Diensten, sondern standardisiert auch die notwendigen SOAPNachrichten, um Web Services und ihre Beschreibung zu Finden, zu Ändern, Hinzuzufügen
oder zu Löschen.
Abbildung 14 fasst die 3 Standards SOAP, WSDL und UDDI bezüglich der Web Service
Architektur noch einmal übersichtlich zusammen.
ha
(W
SD
5.: SOAP - Antwort
L)
e
(W
SD
g
ra
nf
O
AP
uc
O
AP
-S
1.
:S
AP
O
L)
:S
2.
3.
:S
UDDI
4.: aus WDSL
Aufbau der SOAP
Nachrichten,
Adresse +
Übertragungsprotokoll
auslesen
4.: SOAP – Anfrage
Service Provider
Service Konsument
Abbildung 14: Web Service Architektur: konkret, nach [Wik05b]
Web Services haben, gegenüber anderen Lösungen zur Realisierung verteilter Anwendungen
den Vorteil ihrer Plattform-, Programmiersprachen- und Protokollunabhängigkeit, um zum
einen auf effiziente Weise verteilte Anwendungen auf Basis existierende Internetdienste zu
erstellen und zum anderen heterogene Softwarekomponenten zu verteilten Anwendungen zu
verknüpfen, ohne den Nachteil eines hohen Einarbeitungsaufwand, wie dies z.B. von CORBA
her bekannt ist. Während dies auch anfangs die Hauptmotivation von Web Services darstellte,
gestattet die reine Nutzung von SOAP und HTTP als Übertragungsprotokoll darüber hinaus
nicht nur die Realisierung verteilter Anwendungen hinter Firewalls, sondern auch die
Involvierung leistungsschwacher Endgeräte in diese (vergleiche Abbildung 15).
SOAP über HTTP
SOAP über HTTP
Client
Server
Firewall
Thin Client
Abbildung 15: verteilte Anwendungen auf Basis von SOAP über HTTP
Web Services besitzen jedoch auch gravierende Nachteile. Erstere äußern sich im
Sicherheitsproblem der verwendeten Übertragungsprotokolle. Es sind daher für sensitive
Daten unbedingt weitere Mechanismen, wie z.B. SSL, nötig um Vertraulichkeit, Integrität und
17
Authentizität zu gewährleisten. Zusätzlich stellen hohe Übertragungs-, Kodierungs- und
Decodierungszeiten der SOAP Nachrichten sowie Overhead für XML-Markup Performanceprobleme dar.
Ein weiteres großes Problem bildet das fehlende Transaktionsmanagement der zu Grunde
liegenden Transportprotokolle. Diese fundamentale Vorraussetzung verteilter Systeme kann
derzeit leider nur durch proprietäre Lösungen, wie z.B. Cookies, ermöglicht werden.
3.3 Implementierungstechnische Umsetzung von Web Services
Die Web Service Architektur wurde mit dem Ziel der Protokoll-, Plattform- und
Programmiersprachenunabhängigkeit geschaffen. Aus diesem Grund definiert sie lediglich
wie die Initialisierung und der Nachrichtenaustausch zwischen den Kommunikationspartner
erfolgt, die konkrete Realisierung von Web Service- und deren Clientimplementierung wird
jedoch nicht festgelegt.
Dem Programmier steht es demnach frei die nötige Funktionalität der SOAPNachrichteninteraktionen und Netzwerkaktivität selbst zu programmieren oder von einer der
diversen Programmierschnittstellen Gebrauch zu machen.
Für die Serverapplikation existieren hierfür zahlreiche Web Service Container und APIs. Im
Praktikumsversuch soll der Web Service Container „JWSDP-Tomcat 5.0“, die API „JAXRPC3“ und das JWSDP 2.0 genutzt werden.
JAX-RPC automatisiert die Netzwerkinteraktionen und das Mapping zwischen SOAP und
Java mit Hilfe so genannter Ties. Der Programmier braucht sich nur auf die Implementierung
der Fachlogik der als Web Service angebotenen Methoden zu konzentrieren, indem er die
Signatur der remote Methoden im so genannte Service Endpoint Interface definiert und deren
Fachlogik in der Implementierungsklasse des SEIs anschließend spezifiziert. Im einfachsten
Fall sind lediglich zwei .java–Files (Interface + Impl.-Klasse) notwendig.
Das JWSDP erstellt aus dem SEI die dazugehörige WSDL-Datei sowie die JAX-RPC Ties.
Notwendige Steuerungsinformationen befinden sich in der „config.xml“.
Die Informationen über Adresse, Name, Bezeichnung, SEI und Implementierungsklasse des
Web Services werden in den .xml Files

web.xml

jaxrpc-ri.xml
hinterlegt und zusammen mit dem Quellcode und den Ties in einem .war File
zusammengefasst. Auch diese Archiverstellung kann mittels der JWSDP-Funktionalität
durchgeführt werden.
Zur Laufzeit konvertiert Tomcat das .war File in ein Servlet, welches auf eingehende httpRequests der in den .xml Files hinterlegten Adresse reagiert, die entsprechenden Methode in
der Serviceimplementierung aufruft und auf diese Weise den Web Service realisiert.
Abbildung 16 visualisiert den Buildprozess eines Web Services.
3
Java API for XML-RPC
18
jaxrpc-ri.xml
SEI
config.xml
Service-Impl
web.xml
JWSDP 2.0
Servlet
SEI
jaxrpc-ri.xml
Tie
WSDL-Datei
Service-Impl
web.xml
JAX-RPC
Laufzeitumgebung
Tie
Ties
.war File
JWDP-Tomcat 5.0
Abbildung 16: Buildprozess der Serverapplikation
Auch auf Clientseite existieren zur Vereinfachung des Web Service Zugriffs diverse APIs.
Für mobile J2ME-Anwendungen steht die API „JSR 172“ zur Verfügung, welche wie auch
JAX-RPC, das Java-SOAP Mapping sowie die nötigen Netzwerkinteraktionen in so
genannten Stubs automatisiert. Die Stubs können automatische aus der WSDL Datei des
Servers gewonnen werden. Das WTK 2.2 bietet hierfür ein entsprechendes Tool an. (siehe
Abbildung 17)
WSDL-Datei
WTK 2.2
J2ME-Client
Stub
JSR 172
Laufzeitumgebung
Abbildung 17: Buildprozess der Clientapplikation
Durch die Stubs unterscheidet sich der Aufruf einer Web Service Methode nicht von der einer
lokalen, der originale Rückgabewert der Serverfunktion steht direkt zur Verfügung. Leider
sind aufgrund der eingeschränkten Funktonalität der J2ME JVM nur Strings als
Rückgabewerte möglich. Die zu übertragenden Informationen müssen daher auf geeignete
Weise kodiert werden. Idealerweise bietet sich hierfür XML an. Dies bedeutet, dass die
Informationen auf dem Server zunächst in ein entsprechendes .xml File kodiert und auf
Clientseite mit Hilfe eines XML-Parsers wieder extrahiert werden müssen.
Eine Beispielanwendung oben beschriebener Architektur findet
WTK/apps/JSR172Demo
oder
im
WWW
http://www.devx.com/wireless/Article/28046/1954?pf=true.
19
man
unter
unter
Kapitel 4
Projektdokumentation
Die Quellcodedateien als Eclipse Projekte können auf der Praktikumseite herunter geladen
werden.
1.1 Serverapplikation
Die äußerst einfach gestaltete Serveranwendung besteht aus dem einzigen Package
„flugbuchung“. Es enthält sowohl das SEI als auch dessen Implementierung. Die
Implementierung in der Klasse „ServerImpl.java“ ist zu vervollständigen.
Abbildung 18: Klassendiagramm des Servers
Die Serveranwendung kann mit der im Eclipse-Projet enthaltenen buildServer.bat erstellt
werden. Die .bat erzeugt die benötigte .war Datei und kopiert sie in das notwendige
Verzeichnis für Web Applikationen in Tomcat. Es sind keine weiteren Aktionen notwendig.
Der Web Service steht damit für Clientzugriffe zur Verfügung.
Achtung: in der buildServer.bat sind die Pfade auf die Variablen noch anzupassen!
Aufgabe 1: Implementierung des XML-Dokumentes als Rückgabewertes für die
Methode getBooking(…)
Remote Methoden dürfen lediglich String als Rückgabewerte besitzen. Einfache
Statusmeldungen können auf diese Weise ohne Probleme übertragen werden. Komplexe
Nachrichten, wie zum Beispiel eine gesuchte Buchung müssen als XML-Dokument kodiert
transportiert werden. In Aufgabe 1 ist die Methode „getBooking(String bookingNumber,
String
surName,
String
firstName)“
der
Serverimplementierungsklasse
20
„Server_Impl.java“ zu vervollständigen. Die Methode soll ein dem XML-Schema
„getBooking.xsd“ aus Anhang A konformes XML Dokument zurück geben. Es enthält die
Buchung, die an den Client zurückgesendet wird. Sollte keine Buchung vorhanden sein, so
fehlt das „booking“ Element in der XML-Antwort.
Nach erfolgreicher Implementierung der getBooking(…) – Methode ist die Entwicklung des
Servers abgeschlossen.
1.2 Clientapplikation
Die Clientanwendung besteht insgesamt aus 6 Packages, deren Inhalt Tabelle 1 entnommen
werden kann.
Packagename
Inhalt
businessLogic
Server-Proxy-Klasse, welche die Serverrequest absendet und die
Antworten aufbereitet an den Client weiterleitet.
businessLogic.parser
XML-Parser der getBooking und getFlight Serverantworten.
businessLogic.staticStubs Aus WSDL-Datei automatisch erzeugte Subs. Diese Klassen nicht
ändern!
gui
MIDlet der Clientanwendung. Diese Klassen nicht ändern!
gui.commands
Commands der Clientanwendung
gui.forms
Forms der der Clientanwendung.
Tabelle 1: Inhalt der einzelnen Clientpackages
Die für die Clientanwendung notwendigen Bibliotheken

midpapi20.jar

j2me-ws.jar

cldcapi11.jar
aus WTK_HOME/lib sind bereits in das Eclipse-Projekt integriert. Zum deployen und starten
der Clientanwendung ist die build.xml über den Kontextmenüeintrag „Run As/Ant Build“
auszuführen. (siehe Abbildung 19)
21
Abbildung 19: Starten von Antenna
Achtung: In der build.xml muss in der Anweisung
<property name="wtk.home" value="d:\WirelessToolkit" />
die Variable „wtk.home“ an das Homeverzeichnis der WTK 2.2 Installation angepasst
werden. Startet man die build.xml als Ant Task, so wird der Compilierungsprozess gestartet
und die Anwendung im Default-Emulator des WTK gestartet.
Achtung:
22
In der build.xml wird die Bibliothek „j2me-ws.jar“ aus WTK_HOME/lib referenziert. Die
Bibliothek ist allerdings unvollständig. Daher ist die j2me-ws.jar in WTK_HOME/lib mit der
j2me-ws.jar aus dem Eclipse-Projekt „JME_SOAP_Client“ zu überschrieben.
2. Aufgabe: Implementierung der Stubaufrufe
Die Klasse „businessLogic.Server.java“ besitzt für jede Web-Service-Operation (ServerMethode) eine gleichnamige Methode. Diese Methoden kapseln den technologiespezifischen
Code zum Aufruf der Servermethoden. Sie werden im Rahmen der Clientanwendung als
lokale Methoden benutzt. Auf diese Weise kann ohne Modifikation der restlichen Anwendung
auf alternative Server bzw. Übertragungsprotokolle zurückgegriffen werden kann. Die
Anwendung erhält einen generischen Aufbau.
Die Methoden der Klasse „businessLogic.Server.java“ sind um die JSR 172 spezifischen
Aufrufe der Stub-Methoden zu ergänzen.
3. Aufgabe: Erstellung eines xml-Parser für das Ergebnis der Methode getFlights(…)
Methode
„getFlights(String
startAirport,
String
destinationAirport, int smoker, int window, int fClass)“ werden serverseitig in
Die
Rückgabewerte
der
einem XML-Dokument kodiert. Das Dokument enthält alle verfügbaren Flüge, die den
Werten der eingegebenen Parameter entsprechen.
Aus dem XML-Rückgabewert müssen die gesuchten Informationen wieder extrahiert werden.
Hierfür
ist
ein
entsprechender
XML-Parser
in
der
Klasse
„businessLogic.parser.GetFlightParser.java“ zu implementieren
Als Ergebnis soll der Parser über die Funktion „getResult()“ einen Vector mit folgendem
Inhalt zurückgeben:

status der XML-Antwort (ok, oder failed)

flightsCG = ChoiceGroup mit den Namen aller Flüge

names = Vektor mit den Namen aller Flüge (Achtung selbe Reihenfolge wie in
flightsCG)

startAirports = Vektor mit den Startflughäfen aller Flüge (Achtung selbe Reihenfolge
wie in flightsCG)

destinationAirports = Vektor mit den Zielflughäfen aller Flüge (Achtung selbe
Reihenfolge wie in flightsCG)

times = Vektor mit den Abflugzeiten aller Flüge (Achtung selbe Reihenfolge wie in
flightsCG)

freeSeats = Vektor, der pro Flug eine ChoiceGroup enthält. Die ChoichGroup
speichert alle freien Sitze des Fluges.
Beispiel: Als Antwort werden folgende 2 Flüge zurückgegeben

DDK-BZO von Dresden-Klotsche nach Berlin-Zoo am 17.10.2001 um 10:00:00 mit
dem freien Sitz Nr. 1 (Raucher, Fenster), Kl.: 1

DDS-DDP von Dresden-Striesen nach Dresden-Prohlis am 7.10.2001 um 11:30:00 mit
dem freien Sitz Nr. 1 (Raucher, Fenster), Kl.: 1
23
Der Ergebnisvektor des XML-Parsers sieht dann wie folgt aus:

status = ok

flightsCG = {DDK-BZO, DDS-DDP}

names = {DDK-BZO, DDS-DDP}

startAirports = {Dresden-Klotsche, Dresden-Striesen}

destinationAirports = {Berlin-Zoo, Dresden-Prohlis}

times = {17.10.2001 10:00:00, 7.10.2001 11:30:00}

freeSeats = {{Nr.: 1 (Raucher, Fenster) Kl.: 1}, {Nr.: 1 (Raucher, Fenster) Kl.: 1}}
4. Aufgabe: Erstellung einer Bestätigungsanzeige für gebuchte Flüge
In Buchungsanwendungen ist es sinnvoll nach erfolgreicher Buchung diese dem Nutzer zu
bestätigen. Als 4. Aufgabe soll eine solche Bestätigungsanzeige (siehe Abbildung 20)
implementiert
werden.
Die
entsprechende
Klasse
„gui.froms
ConfirmationForm_Booking.java“ liegt bereits vor. Zusätzlich ist die Klasse
„gui.commands.MyCommandListener.java“ zu ergänzen.
Die Anzeige ist so zu gestallten, das dem Nutzer über einen Button die Möglichkeit gegeben
wird eine neue Buchung einzugeben.
Abbildung 20: Confirmation Form
24
1.3 Abgabe der Lösungen
Die Client- und Serveranwendung sind als Eclipse Projekte auf dem Praktikumsserver
abzulegen.
25
Anhang A
getBooking.xsd
<?xml version="1.0"?>
<xsi:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema">
<xsi:element name="root">
<xsi:complexType>
<xsi:sequence>
<xsi:element name = "state">
<xsi:complexType>
<xsi:attribute name = "value" type = "state" use = "required"/>
</xsi:complexType>
</xsi:element>
<xsi:element name = "booking" minOccurs = "0" maxOccurs = "1">
<xsi:complexType>
<xsi:attribute name = "bookingnumber" type = "number" use = "required"/>
<xsi:attribute name = "seatNumber" type = "number" use = "required"/>
<xsi:attribute name = "flightName" type = "xsi:string" use = "required"/>
<xsi:attribute name = "startAirport" type = "xsi:string" use = "required"/>
<xsi:attribute name = "destinationAirport" type = "xsi:string" use = "required"/>
<xsi:attribute name = "smoker" type = "xsi:boolean" use = "required"/>
<xsi:attribute name = "window" type = "xsi:boolean" use = "required"/>
<xsi:attribute name = "class" type = "xsi:int" use = "required"/>
</xsi:complexType>
</xsi:element>
</xsi:sequence>
</xsi:complexType>
</xsi:element>
<xsi:simpleType name = "time">
<xsi:restriction base ="xsi:string">
<xsi:pattern value = "\d{2}.\d{2}.\d{4} \d{2}:\d{2}"/>
</xsi:restriction>
</xsi:simpleType>
26
<xsi:simpleType name = "state">
<xsi:restriction base = "xsi:string">
<xsi:enumeration value = "ok"/>
<xsi:enumeration value = "failed"/>
</xsi:restriction>
</xsi:simpleType>
<xsi:simpleType name = "number">
<xsi:restriction base = "xsi:int">
<xsi:minInclusive value="1"/>
</xsi:restriction>
</xsi:simpleType>
</xsi:schema>
getFlight.xsd
<?xml version="1.0"?>
<xsi:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema">
<xsi:element name="root">
<xsi:complexType>
<xsi:sequence>
<xsi:element name = "state">
<xsi:complexType>
<xsi:attribute name = "value" type = "state" use = "required"/>
</xsi:complexType>
</xsi:element>
<xsi:element name = "flights">
<xsi:complexType>
<xsi:sequence>
<xsi:element name = "flight" minOccurs = "0" maxOccurs = "unbounded">
<xsi:complexType>
<xsi:sequence>
<xsi:element name = "seats">
<xsi:complexType>
27
<xsi:sequence>
<xsi:element name = "seat" maxOccurs = "unbounded">
<xsi:complexType>
<xsi:attribute name = "number" type = "seatNumber" use = "required"/>
<xsi:attribute name = "class" type = "xsi:int" use = "required"/>
<xsi:attribute name = "smoker" type = "xsi:boolean" use = "required"/>
<xsi:attribute name = "window" type = "xsi:boolean" use = "required"/>
</xsi:complexType>
</xsi:element>
</xsi:sequence>
</xsi:complexType>
</xsi:element>
</xsi:sequence>
<xsi:attribute name = "name" type = "xsi:string" use = "required"/>
<xsi:attribute name = "from" type = "xsi:string" use = "required"/>
<xsi:attribute name = "to" type = "xsi:string" use = "required"/>
<xsi:attribute name = "time" type = "time" use = "required"/>
</xsi:complexType>
</xsi:element>
</xsi:sequence>
</xsi:complexType>
</xsi:element>
</xsi:sequence>
</xsi:complexType>
</xsi:element>
<xsi:simpleType name = "time">
<xsi:restriction base ="xsi:string">
<xsi:pattern value = "\d{2}.\d{2}.\d{4} \d{2}:\d{2}"/>
</xsi:restriction>
</xsi:simpleType>
<xsi:simpleType name = "state">
<xsi:restriction base = "xsi:string">
<xsi:enumeration value = "ok"/>
<xsi:enumeration value = "failed"/>
28
</xsi:restriction>
</xsi:simpleType>
<xsi:simpleType name = "seatNumber">
<xsi:restriction base = "xsi:int">
<xsi:minInclusive value="1"/>
</xsi:restriction>
</xsi:simpleType>
</xsi:schema>
29
Abkürzungsverzeichnis
API
Application Programming Interface
J2ME
Java 2 Micro Edition
J2SE
Java 2 Standard Edition
JAX-RPC
Java API for XML-RPC
JVM
Java Virtual Machine
JWSDP
Java Web Service Developer Pack
RMI
Remote Method Invocation
SEI
Service Endpoint Interface
SOA
Service Orientated Architecture
UDDI
Universal Description and Discovery Interface
XML
Extensible Markup Language
WSDL
Web Service Description Language
WTK
Wireless Toolkit
30
Glossar
API - Application Programming Interface
Programmierschnittstelle.
JWSDP - Java Web Service Developer Pack
Entwicklungstool für Java Web Services.
JAX-RPC - Java API for XML-RPC
Web Service API, die das Java-SOAP-Mapping und den SOAP Nachrichtentransport
automatisiert.
JVM - Java Virtual Machine
Laufzeitumgebung für Java Programme.
RMI - Remote Method Invocation
Java Standard Technologie zur Realisierung verteilter Anwendungen auf Basis lokaler
Methodenaufrufe.
SEI – Service Endpoint Interface
Java Interface der Web Service API JAX-RPC, welches die Schnittstellenbeschreibung der
Web Service Implementierung enthält.
Stub
Clientseitiger Proxy der Web Service API JAX-PRC, der das Mapping zwischen SOAP und
Java-Objekten durchführt.
Tie
Serverseitiger Proxy der Web Service API JAX-PRC, der das Mapping zwischen SOAP und
Java-Objekten durchführt.
UDDI - Universal Description and Discovery Interface
Verzeichnisdienst der Web Service-Architektur.
WSDL - Web Service Description Language.
Beschreibungssprache für Web Services.
WTK -Wireless Toolkit
Einwicklungsumgebung von SUN für Implementierung und Test von J2ME-Clients.
XML - Extensible Markup Language
Auszeichnungssprache, die im Gegensatz zu HTML die Definition eigener Tags gestattet und
meist zur plattformunabhängigen Präsentation, Speicherung und Transport von Daten dient.
31
Abbildungsverzeichnis
Abbildung 1: physische Struktur der Beispielanwendung ......................................................... 5
Abbildung 2: Einstellen des Compiler Levels............................................................................ 7
Abbildung 3: Einstellen von JDK 1.5.x - 1 ................................................................................ 8
Abbildung 4: Einstellen von JDK 1.5.x - 2 ................................................................................ 9
Abbildung 5: Einbinden von Antenna in Eclipse ..................................................................... 10
Abbildung 6: Tomcat Integration in Eclipse - GUI.................................................................. 10
Abbildung 7: Integration von Tomcat in Eclipse - Tomcat...................................................... 11
Abbildung 8: Hinzufügen der Datenbank „flugbuchung2.mdb“ - 1 ........................................ 12
Abbildung 9: : Hinzufügen der Datenbank „flugbuchung2.mdb“ – 2 ..................................... 13
Abbildung 10: Suchdienst von Google für Mensch und Maschine ......................................... 15
Abbildung 11: Architektur von Web Services: Grundprinzip, nach [Sev03] .......................... 15
Abbildung 12: Aufbau einer SOAP-Nachricht, nach [Zel03] .................................................. 16
Abbildung 13: SOAP mit TCP / IP Protokollstapel, [Wik05d] ............................................... 16
Abbildung 14: Web Service Architektur: konkret, nach [Wik05b] ......................................... 17
Abbildung 15: verteilte Anwendungen auf Basis von SOAP über HTTP ............................... 17
Abbildung 16: Buildprozess der Serverapplikation ................................................................. 19
Abbildung 17: Buildprozess der Clientapplikation .................................................................. 19
Abbildung 18: Klassendiagramm des Servers ......................................................................... 20
Abbildung 19: Starten von Antenna ......................................................................................... 22
Abbildung 20: Confirmation Form .......................................................................................... 24
32
Tabellenverzeichnis
Tabelle 1: Inhalt der einzelnen Clientpackages ........................................................................ 21
33
Literaturverzeichnis
[Fer05]
Fergusson d.: „Introduction to Web Services Practical“
The 3rd International Summer School on Grid Computing, 2005
http://www.dma.unina.it/~murli/GridSummerSchool2005/reposito
ry/tuesday-12/notes.doc
[FWR04]
Frei M., Wittwer R., Studer B.: „J2ME-Tutorial“.
HTW Chur, Hochschule für Technik und Wirtschaft, Fachhochschule Ostwschweiz, 2004.
http://www.bstuder.ch/sppmc/v20_Tutorial_J2ME_ohne_loe.pdf
[Goy05]
Goyal V.: „J2ME Tutorial“
Java. NET, The Source for Java Technology Collaboration, 2005.
http://today.java.net/pub/a/today/2005/02/09/j2me1.html?page=1
[Sev03]
Severiens T.: „Tutorial: Web Services“.
Arbeitskreis Information (AKI), Institute for Science Networking,
IuK-Herbsttagung, Bad Honnef, 2003.
http://www.akidpg.de/Dokumente/Bad_Honnef_2003/webservicestutorial.pdf.
[Wik05d]
Wikipedia: „SOAP“. 2005.
http://de.wikipedia.org/wiki/SOAP.
[Wik05b]
Wikipedia: „Web Services“. 2005.
http://de.wikipedia.org/wiki/Web_Service.
[Whi]
White, J.: “Turn Your J2ME Mobile Devices into Web Service
Clients“.
Divx, Jupitermedia Corporation, 2005.
http://www.devx.com/wireless/Article/28046/1954?pf=true
Zeller H.: „Java Web Services – Entwicklung plattformübergreifender Dienste mit J2EE, XML und SOAP“.
Addison-Wesley Verlag, ISBN 3-8273-2071-2, 2003.
[Zel03]
34