Vergelijkende studie tussen JAVA en .NET voor mobiele...
113
Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse Vergelijkende studie tussen JAVA en .NET voor mobiele gedistribueerde toepassingen door Toon Coppens Promotor: Dr. Ir. F. Gielen Co-promotor: Prof. Dr. Ir. B. Dhoedt Thesisbeleiders: Ir. Sofie Van Hoecke Ir. Tom Verdickt Afstudeerwerk ingediend tot het behalen van de academische graad van licentiaat toegepaste informatica Academiejaar 2003-2004
Transcript of Vergelijkende studie tussen JAVA en .NET voor mobiele...
Faculteit Toegepaste Wetenschappen
Vakgroep Informatietechnologie
Voorzitter Prof Dr Ir P Lagasse
Vergelijkende studie tussen JAVA en NET voor
mobiele gedistribueerde toepassingen
door
Toon Coppens
Promotor Dr Ir F Gielen
Co-promotor Prof Dr Ir B Dhoedt
Thesisbeleiders
Ir Sofie Van Hoecke
Ir Tom Verdickt
Afstudeerwerk ingediend tot het behalen van de academische graad van
licentiaat toegepaste informatica
Academiejaar 2003-2004
i
Vergelijkende studie tussen JAVA en NET voor
mobiele gedistribueerde toepassingen door Toon Coppens
Afstudeerwerk ingediend tot het behalen van de academische graad van licentiaat
toegepaste informatica (Academiejaar 2003-2004)
Promotor Dr Ir F Gielen Co-promotor Prof Dr Ir B Dhoedt
Thesisbeleiders Ir Sofie Van Hoecke Ir Tom Verdickt
Faculteit Toegepaste Wetenschappen (Universiteit Gent)
Vakgroep Informatietechnologie (Voorzitter Prof Dr Ir P Lagasse)
Samenvatting
De keuze tussen het Compact FrameworkNET en J2ME is eacuteeacuten van de meest
gedebatteerde vragen in de mobiele industrie Hoewel beide technologieeumln sterk
gelijkend zijn wordt er via een uitgebreide featurevergelijking toch enkele duidelijke
verschillen aangetoond Daarnaast wordt in dit afstudeerwerk een proof-of-concept
applicatie geiumlmplementeerd Aan de hand hiervan wordt een evaluatie en voor wat
betreft de communicatieprotocols performantiestudie gemaakt van de twee
technologieeumln
Trefwoorden Gedistribueerde software Compact Framework NET J2ME JAVA client-server
mobiele applicatie Web Services SOAP XML-RPC performantie
ii
Toelating tot bruikleen
De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en
delen van de scriptie te kopieumlren voor persoonlijk gebruik
Elk ander gebruik valt onder de beperkingen van het auteursrecht in het bijzonder met
betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van
resultaten uit deze scriptie
Toon Coppens 31 mei 2004
iii
Dankwoord
Een thesis schrijven is een uitdagende opdracht Een uitdaging die niet vanzelfsprekend
is Een op gezondheidsvlak turbulent jaar maakte alles er niet gemakkelijker op Alle
hulp en steun zijn dan ook van onschatbare waarde gebleken
Zonder de deskundige begeleiding en richtinggevende adviezen van Sofie Van Hoecke
en Tom Verdickt was dit werk zeker niet tot stand kunnen komen Ook wens ik mijn
promotor Prof Dr Ir Frank Gielen en co-promotor Prof Dr Ir Bart Dhoedt te
bedanken voor de kans die me gegeven werd om dit interessant onderwerp te kunnen
bestuderen
Ik bedank ook in de eerste plaats mijn ouders voor hun onnavolgbare steun begrip en
liefde Zonder hen was deze studie en in het bijzonder dit afstudeerwerk nooit gelukt
De vele tik- en taalfouten die tijdens het schrijven in dit afstudeerwerk slopen werden
er geduldig uitgehaald door mijn goede vriend Lorenz Bogaert waarvoor dank
Verder wens ik al mijn vrienden en vriendinnen te bedanken voor de morele steun en
leuke tijden die ze me de afgelopen maanden en jaren gegeven hebben In het bijzonder
bedank ik mijn vriendin Astrid Jij zorgde steeds voor een liefdevolle lach wanneer ik
dat het meeste nodig had
iv
Acroniemen
ADO ActiveX Data Object
API Application Programming Interface
AWT Abstract Window Toolkit
CDC Connected Device Configuration
CF Compact Framework
CLDC Connected Limited Device Configuration
CLR Common Language Runtime
COM Component Object Model
COM Component Object Model
CORBA Common Object Request Broker Architecture
CVM Compact Virtual Machine
DCOM Distributed Component Object Model
DLL Dynamic Link Library
DOM Document Object Model
EE Execution Engine
EJB Enterprise Java Bean
GCF Generic Connection Framework
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile Communication
GUI Graphical User Interface
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IO InputOutput
IDE Integrated Development Enterprise
IIS Internet Information Services
J2EE Java 2 Enterprise Edition
J2ME Java 2 Micro Edition
J2SE Java 2 Standard Edition
JCP Java Community Process
JDBC Java Database Connectivity
v
JNI Java Native Interface
JVM Java Virtual Machine
KVM Kilobyte Virtual Machine
MIDP Mobile Information Device Profile
MSIL Microsoft Intermediate Language
NNTP Network News Transport Protocol
NSL Native Support Libraries
OEM Original Equipment Manufacturer
ORB Object Request Broker
OS Operating Service
OSGi Open Service Gateway initiative
OTA Over The Air
PInvoke Platform Invocation Services
PAL Platform Adaptation Layer
PDA Personal Digital Assistent
PDAP Personal Digital Assistent Profile
PE Portable Executable
Pm Personal Profile
RAM Read Access Memory
RMI Remote Method Invocation
SDK Software Development Kit
SDP Smart Device Project
SE Standard Edition
SOAP Simple Object Access Protocol
SQL Structured Query Language
TCPIP Transmission Control ProtocolInternet Protocol
UDDI Universal Description Discovery and Integration
UI User Interface
VM Virtual Machine
WAP Wireless Application Protocol
WBXML Wireless Binary XML
WebDAV Web-based Distributed Authoring and Versioning
WML Wireless Markup Language
WSDL Web Service Description Language
vi
XML Extensible Markup Language
XML-RPC Extensible Markup Language Remote Procedure Call
XSLT Extensible Stylesheet Language Transformations
vii
Inhoudstafel
Hoofdstuk 1 Inleiding 1
Hoofdstuk 2 Applicatieontwerp4
21 Mobiele Applicatie 4
211 Verbindingsvormen 4
212 Architecturale concepten 5
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen 6
22 Applicatievereisten 6
23 J2ME en CF 9
Hoofdstuk 3 Basistechnologieumln 10
31 J2ME 10
311 Configuraties en profielen 11
312 CDC vs CLDC 12
313 CLDC en MIDP 13
314 Connected Device Configuration 15
32 NET Compact Framework 18
321 Windows CE 18
322 Platform 19
323 NET Framework 20
324 NET Compact Framework 20
325 NET CF Platforms 22
33 Een eerste vergelijking 23
331 Algemeen theoretisch 23
332 Filosofie 28
333 Deployment en Area 28
334 Development Tools 29
335 Emulatie 30
336 Code 32
Hoofdstuk 4 Platformeigenschappen 33
41 Lokale data opslag 33
411 J2ME 33
viii
4111 MIDP en het Record Management System33
412 Compact Framework 38
4121 InputOutput 38
4122 XML38
4123 Relationele data opslag39
413 Conclusie 40
42 Netwerk 41
421 J2ME 41
4211 CLDC 42
4212 CDC 42
422 Compact Framework 43
4221 Web Services 43
4222 SQL Server en SQL Client44
4223 Pluggable Protocols44
4224 Low Level Sockets TCP UDP IrDa 45
423 Conclusie 45
43 Communicatieprotocols 45
431 Tekstformaat 46
432 XML 47
433 Webservices 47
4331 XML-RPC48
4332 SOAP48
434 Protocolvergelijkende testapplicatie in J2ME 49
4341 Opstelling 50
4342 Client-zijde 51
4343 Server-zijde 53
4344 Testmethode 55
4345 De resultaten 56
435 Protocolvergelijkende testapplicatie in CFNET 61
436 Conclusie 70
44 User Experience 70
441 J2ME 71
4411 MIDP71
4412 Personal Profile 71
442 NET 72
ix
443 Conclusie 73
Hoofdstuk 5 Implementatie van de applicatie74
51 Inleiding 74
52 Opstelling 75
53 WebService interface 77
54 Client applicatie 81
55 De totaalapplicatie en het illustratiebelang 85
56 Alternatieve opstelling 86
57 Uitbreidingen 88
Hoofdstuk 6 Besluit 90
61 Resultaten 90
62 Verder onderzoek 92
x
Lijst van figuren
Figuur 2-1 de flow van de applicatie 7
Figuur 2-2 de use cases van de demonstratie-applicatie 8
Figuur 3-1 Java toepassingsgebieden 10
Figuur 3-2 de edities en configuraties 11
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages 12
Figuur 3-4 de 2 configuraties CDC en CLDC 13
Figuur 3-5 de levenscyclus van MIDP 14
Figuur 3-6 Mobile Information Device Profile (MIDP) 14
Figuur 3-7 de levenscyclus van een Xlet 17
Figuur 3-8 De Windows CE architectuur 19
Figuur 3-9 NET Compact Framework versus het NET desktop Framework 21
Figuur 3-10 De architectuur van het Compact Framework 22
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21 31
Figuur 4-1 de afhankelijkheden van de communicatietypes 43
Figuur 4-2 de Java connectie test 51
Figuur 4-3 klassestructuur van het testprogramma 51
Figuur 4-4 de MIDP Connectie Tester Applicatie 56
Figuur 4-5 network monitor tools in Wireless Toolkit 58
Figuur 4-6 de tijden per uitvoering 59
Figuur 4-7 de grootten van de aanvragen en antwoorden 60
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie) 61
Figuur 4-9 de testopstelling 62
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002 63
Figuur 4-11 de meetresultaten op de emulator 67
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms) 69
Figuur 4-13 een vergelijking van de communicatieprotocols 70
Figuur 5-1 de demonstratie-opstelling 75
Figuur 5-2 de verbindingsmodellen 76
Figuur 5-3 webinterface voor de lesgever in Claroline 77
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
i
Vergelijkende studie tussen JAVA en NET voor
mobiele gedistribueerde toepassingen door Toon Coppens
Afstudeerwerk ingediend tot het behalen van de academische graad van licentiaat
toegepaste informatica (Academiejaar 2003-2004)
Promotor Dr Ir F Gielen Co-promotor Prof Dr Ir B Dhoedt
Thesisbeleiders Ir Sofie Van Hoecke Ir Tom Verdickt
Faculteit Toegepaste Wetenschappen (Universiteit Gent)
Vakgroep Informatietechnologie (Voorzitter Prof Dr Ir P Lagasse)
Samenvatting
De keuze tussen het Compact FrameworkNET en J2ME is eacuteeacuten van de meest
gedebatteerde vragen in de mobiele industrie Hoewel beide technologieeumln sterk
gelijkend zijn wordt er via een uitgebreide featurevergelijking toch enkele duidelijke
verschillen aangetoond Daarnaast wordt in dit afstudeerwerk een proof-of-concept
applicatie geiumlmplementeerd Aan de hand hiervan wordt een evaluatie en voor wat
betreft de communicatieprotocols performantiestudie gemaakt van de twee
technologieeumln
Trefwoorden Gedistribueerde software Compact Framework NET J2ME JAVA client-server
mobiele applicatie Web Services SOAP XML-RPC performantie
ii
Toelating tot bruikleen
De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en
delen van de scriptie te kopieumlren voor persoonlijk gebruik
Elk ander gebruik valt onder de beperkingen van het auteursrecht in het bijzonder met
betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van
resultaten uit deze scriptie
Toon Coppens 31 mei 2004
iii
Dankwoord
Een thesis schrijven is een uitdagende opdracht Een uitdaging die niet vanzelfsprekend
is Een op gezondheidsvlak turbulent jaar maakte alles er niet gemakkelijker op Alle
hulp en steun zijn dan ook van onschatbare waarde gebleken
Zonder de deskundige begeleiding en richtinggevende adviezen van Sofie Van Hoecke
en Tom Verdickt was dit werk zeker niet tot stand kunnen komen Ook wens ik mijn
promotor Prof Dr Ir Frank Gielen en co-promotor Prof Dr Ir Bart Dhoedt te
bedanken voor de kans die me gegeven werd om dit interessant onderwerp te kunnen
bestuderen
Ik bedank ook in de eerste plaats mijn ouders voor hun onnavolgbare steun begrip en
liefde Zonder hen was deze studie en in het bijzonder dit afstudeerwerk nooit gelukt
De vele tik- en taalfouten die tijdens het schrijven in dit afstudeerwerk slopen werden
er geduldig uitgehaald door mijn goede vriend Lorenz Bogaert waarvoor dank
Verder wens ik al mijn vrienden en vriendinnen te bedanken voor de morele steun en
leuke tijden die ze me de afgelopen maanden en jaren gegeven hebben In het bijzonder
bedank ik mijn vriendin Astrid Jij zorgde steeds voor een liefdevolle lach wanneer ik
dat het meeste nodig had
iv
Acroniemen
ADO ActiveX Data Object
API Application Programming Interface
AWT Abstract Window Toolkit
CDC Connected Device Configuration
CF Compact Framework
CLDC Connected Limited Device Configuration
CLR Common Language Runtime
COM Component Object Model
COM Component Object Model
CORBA Common Object Request Broker Architecture
CVM Compact Virtual Machine
DCOM Distributed Component Object Model
DLL Dynamic Link Library
DOM Document Object Model
EE Execution Engine
EJB Enterprise Java Bean
GCF Generic Connection Framework
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile Communication
GUI Graphical User Interface
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IO InputOutput
IDE Integrated Development Enterprise
IIS Internet Information Services
J2EE Java 2 Enterprise Edition
J2ME Java 2 Micro Edition
J2SE Java 2 Standard Edition
JCP Java Community Process
JDBC Java Database Connectivity
v
JNI Java Native Interface
JVM Java Virtual Machine
KVM Kilobyte Virtual Machine
MIDP Mobile Information Device Profile
MSIL Microsoft Intermediate Language
NNTP Network News Transport Protocol
NSL Native Support Libraries
OEM Original Equipment Manufacturer
ORB Object Request Broker
OS Operating Service
OSGi Open Service Gateway initiative
OTA Over The Air
PInvoke Platform Invocation Services
PAL Platform Adaptation Layer
PDA Personal Digital Assistent
PDAP Personal Digital Assistent Profile
PE Portable Executable
Pm Personal Profile
RAM Read Access Memory
RMI Remote Method Invocation
SDK Software Development Kit
SDP Smart Device Project
SE Standard Edition
SOAP Simple Object Access Protocol
SQL Structured Query Language
TCPIP Transmission Control ProtocolInternet Protocol
UDDI Universal Description Discovery and Integration
UI User Interface
VM Virtual Machine
WAP Wireless Application Protocol
WBXML Wireless Binary XML
WebDAV Web-based Distributed Authoring and Versioning
WML Wireless Markup Language
WSDL Web Service Description Language
vi
XML Extensible Markup Language
XML-RPC Extensible Markup Language Remote Procedure Call
XSLT Extensible Stylesheet Language Transformations
vii
Inhoudstafel
Hoofdstuk 1 Inleiding 1
Hoofdstuk 2 Applicatieontwerp4
21 Mobiele Applicatie 4
211 Verbindingsvormen 4
212 Architecturale concepten 5
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen 6
22 Applicatievereisten 6
23 J2ME en CF 9
Hoofdstuk 3 Basistechnologieumln 10
31 J2ME 10
311 Configuraties en profielen 11
312 CDC vs CLDC 12
313 CLDC en MIDP 13
314 Connected Device Configuration 15
32 NET Compact Framework 18
321 Windows CE 18
322 Platform 19
323 NET Framework 20
324 NET Compact Framework 20
325 NET CF Platforms 22
33 Een eerste vergelijking 23
331 Algemeen theoretisch 23
332 Filosofie 28
333 Deployment en Area 28
334 Development Tools 29
335 Emulatie 30
336 Code 32
Hoofdstuk 4 Platformeigenschappen 33
41 Lokale data opslag 33
411 J2ME 33
viii
4111 MIDP en het Record Management System33
412 Compact Framework 38
4121 InputOutput 38
4122 XML38
4123 Relationele data opslag39
413 Conclusie 40
42 Netwerk 41
421 J2ME 41
4211 CLDC 42
4212 CDC 42
422 Compact Framework 43
4221 Web Services 43
4222 SQL Server en SQL Client44
4223 Pluggable Protocols44
4224 Low Level Sockets TCP UDP IrDa 45
423 Conclusie 45
43 Communicatieprotocols 45
431 Tekstformaat 46
432 XML 47
433 Webservices 47
4331 XML-RPC48
4332 SOAP48
434 Protocolvergelijkende testapplicatie in J2ME 49
4341 Opstelling 50
4342 Client-zijde 51
4343 Server-zijde 53
4344 Testmethode 55
4345 De resultaten 56
435 Protocolvergelijkende testapplicatie in CFNET 61
436 Conclusie 70
44 User Experience 70
441 J2ME 71
4411 MIDP71
4412 Personal Profile 71
442 NET 72
ix
443 Conclusie 73
Hoofdstuk 5 Implementatie van de applicatie74
51 Inleiding 74
52 Opstelling 75
53 WebService interface 77
54 Client applicatie 81
55 De totaalapplicatie en het illustratiebelang 85
56 Alternatieve opstelling 86
57 Uitbreidingen 88
Hoofdstuk 6 Besluit 90
61 Resultaten 90
62 Verder onderzoek 92
x
Lijst van figuren
Figuur 2-1 de flow van de applicatie 7
Figuur 2-2 de use cases van de demonstratie-applicatie 8
Figuur 3-1 Java toepassingsgebieden 10
Figuur 3-2 de edities en configuraties 11
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages 12
Figuur 3-4 de 2 configuraties CDC en CLDC 13
Figuur 3-5 de levenscyclus van MIDP 14
Figuur 3-6 Mobile Information Device Profile (MIDP) 14
Figuur 3-7 de levenscyclus van een Xlet 17
Figuur 3-8 De Windows CE architectuur 19
Figuur 3-9 NET Compact Framework versus het NET desktop Framework 21
Figuur 3-10 De architectuur van het Compact Framework 22
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21 31
Figuur 4-1 de afhankelijkheden van de communicatietypes 43
Figuur 4-2 de Java connectie test 51
Figuur 4-3 klassestructuur van het testprogramma 51
Figuur 4-4 de MIDP Connectie Tester Applicatie 56
Figuur 4-5 network monitor tools in Wireless Toolkit 58
Figuur 4-6 de tijden per uitvoering 59
Figuur 4-7 de grootten van de aanvragen en antwoorden 60
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie) 61
Figuur 4-9 de testopstelling 62
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002 63
Figuur 4-11 de meetresultaten op de emulator 67
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms) 69
Figuur 4-13 een vergelijking van de communicatieprotocols 70
Figuur 5-1 de demonstratie-opstelling 75
Figuur 5-2 de verbindingsmodellen 76
Figuur 5-3 webinterface voor de lesgever in Claroline 77
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
ii
Toelating tot bruikleen
De auteur geeft de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en
delen van de scriptie te kopieumlren voor persoonlijk gebruik
Elk ander gebruik valt onder de beperkingen van het auteursrecht in het bijzonder met
betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van
resultaten uit deze scriptie
Toon Coppens 31 mei 2004
iii
Dankwoord
Een thesis schrijven is een uitdagende opdracht Een uitdaging die niet vanzelfsprekend
is Een op gezondheidsvlak turbulent jaar maakte alles er niet gemakkelijker op Alle
hulp en steun zijn dan ook van onschatbare waarde gebleken
Zonder de deskundige begeleiding en richtinggevende adviezen van Sofie Van Hoecke
en Tom Verdickt was dit werk zeker niet tot stand kunnen komen Ook wens ik mijn
promotor Prof Dr Ir Frank Gielen en co-promotor Prof Dr Ir Bart Dhoedt te
bedanken voor de kans die me gegeven werd om dit interessant onderwerp te kunnen
bestuderen
Ik bedank ook in de eerste plaats mijn ouders voor hun onnavolgbare steun begrip en
liefde Zonder hen was deze studie en in het bijzonder dit afstudeerwerk nooit gelukt
De vele tik- en taalfouten die tijdens het schrijven in dit afstudeerwerk slopen werden
er geduldig uitgehaald door mijn goede vriend Lorenz Bogaert waarvoor dank
Verder wens ik al mijn vrienden en vriendinnen te bedanken voor de morele steun en
leuke tijden die ze me de afgelopen maanden en jaren gegeven hebben In het bijzonder
bedank ik mijn vriendin Astrid Jij zorgde steeds voor een liefdevolle lach wanneer ik
dat het meeste nodig had
iv
Acroniemen
ADO ActiveX Data Object
API Application Programming Interface
AWT Abstract Window Toolkit
CDC Connected Device Configuration
CF Compact Framework
CLDC Connected Limited Device Configuration
CLR Common Language Runtime
COM Component Object Model
COM Component Object Model
CORBA Common Object Request Broker Architecture
CVM Compact Virtual Machine
DCOM Distributed Component Object Model
DLL Dynamic Link Library
DOM Document Object Model
EE Execution Engine
EJB Enterprise Java Bean
GCF Generic Connection Framework
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile Communication
GUI Graphical User Interface
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IO InputOutput
IDE Integrated Development Enterprise
IIS Internet Information Services
J2EE Java 2 Enterprise Edition
J2ME Java 2 Micro Edition
J2SE Java 2 Standard Edition
JCP Java Community Process
JDBC Java Database Connectivity
v
JNI Java Native Interface
JVM Java Virtual Machine
KVM Kilobyte Virtual Machine
MIDP Mobile Information Device Profile
MSIL Microsoft Intermediate Language
NNTP Network News Transport Protocol
NSL Native Support Libraries
OEM Original Equipment Manufacturer
ORB Object Request Broker
OS Operating Service
OSGi Open Service Gateway initiative
OTA Over The Air
PInvoke Platform Invocation Services
PAL Platform Adaptation Layer
PDA Personal Digital Assistent
PDAP Personal Digital Assistent Profile
PE Portable Executable
Pm Personal Profile
RAM Read Access Memory
RMI Remote Method Invocation
SDK Software Development Kit
SDP Smart Device Project
SE Standard Edition
SOAP Simple Object Access Protocol
SQL Structured Query Language
TCPIP Transmission Control ProtocolInternet Protocol
UDDI Universal Description Discovery and Integration
UI User Interface
VM Virtual Machine
WAP Wireless Application Protocol
WBXML Wireless Binary XML
WebDAV Web-based Distributed Authoring and Versioning
WML Wireless Markup Language
WSDL Web Service Description Language
vi
XML Extensible Markup Language
XML-RPC Extensible Markup Language Remote Procedure Call
XSLT Extensible Stylesheet Language Transformations
vii
Inhoudstafel
Hoofdstuk 1 Inleiding 1
Hoofdstuk 2 Applicatieontwerp4
21 Mobiele Applicatie 4
211 Verbindingsvormen 4
212 Architecturale concepten 5
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen 6
22 Applicatievereisten 6
23 J2ME en CF 9
Hoofdstuk 3 Basistechnologieumln 10
31 J2ME 10
311 Configuraties en profielen 11
312 CDC vs CLDC 12
313 CLDC en MIDP 13
314 Connected Device Configuration 15
32 NET Compact Framework 18
321 Windows CE 18
322 Platform 19
323 NET Framework 20
324 NET Compact Framework 20
325 NET CF Platforms 22
33 Een eerste vergelijking 23
331 Algemeen theoretisch 23
332 Filosofie 28
333 Deployment en Area 28
334 Development Tools 29
335 Emulatie 30
336 Code 32
Hoofdstuk 4 Platformeigenschappen 33
41 Lokale data opslag 33
411 J2ME 33
viii
4111 MIDP en het Record Management System33
412 Compact Framework 38
4121 InputOutput 38
4122 XML38
4123 Relationele data opslag39
413 Conclusie 40
42 Netwerk 41
421 J2ME 41
4211 CLDC 42
4212 CDC 42
422 Compact Framework 43
4221 Web Services 43
4222 SQL Server en SQL Client44
4223 Pluggable Protocols44
4224 Low Level Sockets TCP UDP IrDa 45
423 Conclusie 45
43 Communicatieprotocols 45
431 Tekstformaat 46
432 XML 47
433 Webservices 47
4331 XML-RPC48
4332 SOAP48
434 Protocolvergelijkende testapplicatie in J2ME 49
4341 Opstelling 50
4342 Client-zijde 51
4343 Server-zijde 53
4344 Testmethode 55
4345 De resultaten 56
435 Protocolvergelijkende testapplicatie in CFNET 61
436 Conclusie 70
44 User Experience 70
441 J2ME 71
4411 MIDP71
4412 Personal Profile 71
442 NET 72
ix
443 Conclusie 73
Hoofdstuk 5 Implementatie van de applicatie74
51 Inleiding 74
52 Opstelling 75
53 WebService interface 77
54 Client applicatie 81
55 De totaalapplicatie en het illustratiebelang 85
56 Alternatieve opstelling 86
57 Uitbreidingen 88
Hoofdstuk 6 Besluit 90
61 Resultaten 90
62 Verder onderzoek 92
x
Lijst van figuren
Figuur 2-1 de flow van de applicatie 7
Figuur 2-2 de use cases van de demonstratie-applicatie 8
Figuur 3-1 Java toepassingsgebieden 10
Figuur 3-2 de edities en configuraties 11
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages 12
Figuur 3-4 de 2 configuraties CDC en CLDC 13
Figuur 3-5 de levenscyclus van MIDP 14
Figuur 3-6 Mobile Information Device Profile (MIDP) 14
Figuur 3-7 de levenscyclus van een Xlet 17
Figuur 3-8 De Windows CE architectuur 19
Figuur 3-9 NET Compact Framework versus het NET desktop Framework 21
Figuur 3-10 De architectuur van het Compact Framework 22
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21 31
Figuur 4-1 de afhankelijkheden van de communicatietypes 43
Figuur 4-2 de Java connectie test 51
Figuur 4-3 klassestructuur van het testprogramma 51
Figuur 4-4 de MIDP Connectie Tester Applicatie 56
Figuur 4-5 network monitor tools in Wireless Toolkit 58
Figuur 4-6 de tijden per uitvoering 59
Figuur 4-7 de grootten van de aanvragen en antwoorden 60
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie) 61
Figuur 4-9 de testopstelling 62
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002 63
Figuur 4-11 de meetresultaten op de emulator 67
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms) 69
Figuur 4-13 een vergelijking van de communicatieprotocols 70
Figuur 5-1 de demonstratie-opstelling 75
Figuur 5-2 de verbindingsmodellen 76
Figuur 5-3 webinterface voor de lesgever in Claroline 77
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
iii
Dankwoord
Een thesis schrijven is een uitdagende opdracht Een uitdaging die niet vanzelfsprekend
is Een op gezondheidsvlak turbulent jaar maakte alles er niet gemakkelijker op Alle
hulp en steun zijn dan ook van onschatbare waarde gebleken
Zonder de deskundige begeleiding en richtinggevende adviezen van Sofie Van Hoecke
en Tom Verdickt was dit werk zeker niet tot stand kunnen komen Ook wens ik mijn
promotor Prof Dr Ir Frank Gielen en co-promotor Prof Dr Ir Bart Dhoedt te
bedanken voor de kans die me gegeven werd om dit interessant onderwerp te kunnen
bestuderen
Ik bedank ook in de eerste plaats mijn ouders voor hun onnavolgbare steun begrip en
liefde Zonder hen was deze studie en in het bijzonder dit afstudeerwerk nooit gelukt
De vele tik- en taalfouten die tijdens het schrijven in dit afstudeerwerk slopen werden
er geduldig uitgehaald door mijn goede vriend Lorenz Bogaert waarvoor dank
Verder wens ik al mijn vrienden en vriendinnen te bedanken voor de morele steun en
leuke tijden die ze me de afgelopen maanden en jaren gegeven hebben In het bijzonder
bedank ik mijn vriendin Astrid Jij zorgde steeds voor een liefdevolle lach wanneer ik
dat het meeste nodig had
iv
Acroniemen
ADO ActiveX Data Object
API Application Programming Interface
AWT Abstract Window Toolkit
CDC Connected Device Configuration
CF Compact Framework
CLDC Connected Limited Device Configuration
CLR Common Language Runtime
COM Component Object Model
COM Component Object Model
CORBA Common Object Request Broker Architecture
CVM Compact Virtual Machine
DCOM Distributed Component Object Model
DLL Dynamic Link Library
DOM Document Object Model
EE Execution Engine
EJB Enterprise Java Bean
GCF Generic Connection Framework
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile Communication
GUI Graphical User Interface
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IO InputOutput
IDE Integrated Development Enterprise
IIS Internet Information Services
J2EE Java 2 Enterprise Edition
J2ME Java 2 Micro Edition
J2SE Java 2 Standard Edition
JCP Java Community Process
JDBC Java Database Connectivity
v
JNI Java Native Interface
JVM Java Virtual Machine
KVM Kilobyte Virtual Machine
MIDP Mobile Information Device Profile
MSIL Microsoft Intermediate Language
NNTP Network News Transport Protocol
NSL Native Support Libraries
OEM Original Equipment Manufacturer
ORB Object Request Broker
OS Operating Service
OSGi Open Service Gateway initiative
OTA Over The Air
PInvoke Platform Invocation Services
PAL Platform Adaptation Layer
PDA Personal Digital Assistent
PDAP Personal Digital Assistent Profile
PE Portable Executable
Pm Personal Profile
RAM Read Access Memory
RMI Remote Method Invocation
SDK Software Development Kit
SDP Smart Device Project
SE Standard Edition
SOAP Simple Object Access Protocol
SQL Structured Query Language
TCPIP Transmission Control ProtocolInternet Protocol
UDDI Universal Description Discovery and Integration
UI User Interface
VM Virtual Machine
WAP Wireless Application Protocol
WBXML Wireless Binary XML
WebDAV Web-based Distributed Authoring and Versioning
WML Wireless Markup Language
WSDL Web Service Description Language
vi
XML Extensible Markup Language
XML-RPC Extensible Markup Language Remote Procedure Call
XSLT Extensible Stylesheet Language Transformations
vii
Inhoudstafel
Hoofdstuk 1 Inleiding 1
Hoofdstuk 2 Applicatieontwerp4
21 Mobiele Applicatie 4
211 Verbindingsvormen 4
212 Architecturale concepten 5
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen 6
22 Applicatievereisten 6
23 J2ME en CF 9
Hoofdstuk 3 Basistechnologieumln 10
31 J2ME 10
311 Configuraties en profielen 11
312 CDC vs CLDC 12
313 CLDC en MIDP 13
314 Connected Device Configuration 15
32 NET Compact Framework 18
321 Windows CE 18
322 Platform 19
323 NET Framework 20
324 NET Compact Framework 20
325 NET CF Platforms 22
33 Een eerste vergelijking 23
331 Algemeen theoretisch 23
332 Filosofie 28
333 Deployment en Area 28
334 Development Tools 29
335 Emulatie 30
336 Code 32
Hoofdstuk 4 Platformeigenschappen 33
41 Lokale data opslag 33
411 J2ME 33
viii
4111 MIDP en het Record Management System33
412 Compact Framework 38
4121 InputOutput 38
4122 XML38
4123 Relationele data opslag39
413 Conclusie 40
42 Netwerk 41
421 J2ME 41
4211 CLDC 42
4212 CDC 42
422 Compact Framework 43
4221 Web Services 43
4222 SQL Server en SQL Client44
4223 Pluggable Protocols44
4224 Low Level Sockets TCP UDP IrDa 45
423 Conclusie 45
43 Communicatieprotocols 45
431 Tekstformaat 46
432 XML 47
433 Webservices 47
4331 XML-RPC48
4332 SOAP48
434 Protocolvergelijkende testapplicatie in J2ME 49
4341 Opstelling 50
4342 Client-zijde 51
4343 Server-zijde 53
4344 Testmethode 55
4345 De resultaten 56
435 Protocolvergelijkende testapplicatie in CFNET 61
436 Conclusie 70
44 User Experience 70
441 J2ME 71
4411 MIDP71
4412 Personal Profile 71
442 NET 72
ix
443 Conclusie 73
Hoofdstuk 5 Implementatie van de applicatie74
51 Inleiding 74
52 Opstelling 75
53 WebService interface 77
54 Client applicatie 81
55 De totaalapplicatie en het illustratiebelang 85
56 Alternatieve opstelling 86
57 Uitbreidingen 88
Hoofdstuk 6 Besluit 90
61 Resultaten 90
62 Verder onderzoek 92
x
Lijst van figuren
Figuur 2-1 de flow van de applicatie 7
Figuur 2-2 de use cases van de demonstratie-applicatie 8
Figuur 3-1 Java toepassingsgebieden 10
Figuur 3-2 de edities en configuraties 11
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages 12
Figuur 3-4 de 2 configuraties CDC en CLDC 13
Figuur 3-5 de levenscyclus van MIDP 14
Figuur 3-6 Mobile Information Device Profile (MIDP) 14
Figuur 3-7 de levenscyclus van een Xlet 17
Figuur 3-8 De Windows CE architectuur 19
Figuur 3-9 NET Compact Framework versus het NET desktop Framework 21
Figuur 3-10 De architectuur van het Compact Framework 22
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21 31
Figuur 4-1 de afhankelijkheden van de communicatietypes 43
Figuur 4-2 de Java connectie test 51
Figuur 4-3 klassestructuur van het testprogramma 51
Figuur 4-4 de MIDP Connectie Tester Applicatie 56
Figuur 4-5 network monitor tools in Wireless Toolkit 58
Figuur 4-6 de tijden per uitvoering 59
Figuur 4-7 de grootten van de aanvragen en antwoorden 60
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie) 61
Figuur 4-9 de testopstelling 62
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002 63
Figuur 4-11 de meetresultaten op de emulator 67
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms) 69
Figuur 4-13 een vergelijking van de communicatieprotocols 70
Figuur 5-1 de demonstratie-opstelling 75
Figuur 5-2 de verbindingsmodellen 76
Figuur 5-3 webinterface voor de lesgever in Claroline 77
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
iv
Acroniemen
ADO ActiveX Data Object
API Application Programming Interface
AWT Abstract Window Toolkit
CDC Connected Device Configuration
CF Compact Framework
CLDC Connected Limited Device Configuration
CLR Common Language Runtime
COM Component Object Model
COM Component Object Model
CORBA Common Object Request Broker Architecture
CVM Compact Virtual Machine
DCOM Distributed Component Object Model
DLL Dynamic Link Library
DOM Document Object Model
EE Execution Engine
EJB Enterprise Java Bean
GCF Generic Connection Framework
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile Communication
GUI Graphical User Interface
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IO InputOutput
IDE Integrated Development Enterprise
IIS Internet Information Services
J2EE Java 2 Enterprise Edition
J2ME Java 2 Micro Edition
J2SE Java 2 Standard Edition
JCP Java Community Process
JDBC Java Database Connectivity
v
JNI Java Native Interface
JVM Java Virtual Machine
KVM Kilobyte Virtual Machine
MIDP Mobile Information Device Profile
MSIL Microsoft Intermediate Language
NNTP Network News Transport Protocol
NSL Native Support Libraries
OEM Original Equipment Manufacturer
ORB Object Request Broker
OS Operating Service
OSGi Open Service Gateway initiative
OTA Over The Air
PInvoke Platform Invocation Services
PAL Platform Adaptation Layer
PDA Personal Digital Assistent
PDAP Personal Digital Assistent Profile
PE Portable Executable
Pm Personal Profile
RAM Read Access Memory
RMI Remote Method Invocation
SDK Software Development Kit
SDP Smart Device Project
SE Standard Edition
SOAP Simple Object Access Protocol
SQL Structured Query Language
TCPIP Transmission Control ProtocolInternet Protocol
UDDI Universal Description Discovery and Integration
UI User Interface
VM Virtual Machine
WAP Wireless Application Protocol
WBXML Wireless Binary XML
WebDAV Web-based Distributed Authoring and Versioning
WML Wireless Markup Language
WSDL Web Service Description Language
vi
XML Extensible Markup Language
XML-RPC Extensible Markup Language Remote Procedure Call
XSLT Extensible Stylesheet Language Transformations
vii
Inhoudstafel
Hoofdstuk 1 Inleiding 1
Hoofdstuk 2 Applicatieontwerp4
21 Mobiele Applicatie 4
211 Verbindingsvormen 4
212 Architecturale concepten 5
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen 6
22 Applicatievereisten 6
23 J2ME en CF 9
Hoofdstuk 3 Basistechnologieumln 10
31 J2ME 10
311 Configuraties en profielen 11
312 CDC vs CLDC 12
313 CLDC en MIDP 13
314 Connected Device Configuration 15
32 NET Compact Framework 18
321 Windows CE 18
322 Platform 19
323 NET Framework 20
324 NET Compact Framework 20
325 NET CF Platforms 22
33 Een eerste vergelijking 23
331 Algemeen theoretisch 23
332 Filosofie 28
333 Deployment en Area 28
334 Development Tools 29
335 Emulatie 30
336 Code 32
Hoofdstuk 4 Platformeigenschappen 33
41 Lokale data opslag 33
411 J2ME 33
viii
4111 MIDP en het Record Management System33
412 Compact Framework 38
4121 InputOutput 38
4122 XML38
4123 Relationele data opslag39
413 Conclusie 40
42 Netwerk 41
421 J2ME 41
4211 CLDC 42
4212 CDC 42
422 Compact Framework 43
4221 Web Services 43
4222 SQL Server en SQL Client44
4223 Pluggable Protocols44
4224 Low Level Sockets TCP UDP IrDa 45
423 Conclusie 45
43 Communicatieprotocols 45
431 Tekstformaat 46
432 XML 47
433 Webservices 47
4331 XML-RPC48
4332 SOAP48
434 Protocolvergelijkende testapplicatie in J2ME 49
4341 Opstelling 50
4342 Client-zijde 51
4343 Server-zijde 53
4344 Testmethode 55
4345 De resultaten 56
435 Protocolvergelijkende testapplicatie in CFNET 61
436 Conclusie 70
44 User Experience 70
441 J2ME 71
4411 MIDP71
4412 Personal Profile 71
442 NET 72
ix
443 Conclusie 73
Hoofdstuk 5 Implementatie van de applicatie74
51 Inleiding 74
52 Opstelling 75
53 WebService interface 77
54 Client applicatie 81
55 De totaalapplicatie en het illustratiebelang 85
56 Alternatieve opstelling 86
57 Uitbreidingen 88
Hoofdstuk 6 Besluit 90
61 Resultaten 90
62 Verder onderzoek 92
x
Lijst van figuren
Figuur 2-1 de flow van de applicatie 7
Figuur 2-2 de use cases van de demonstratie-applicatie 8
Figuur 3-1 Java toepassingsgebieden 10
Figuur 3-2 de edities en configuraties 11
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages 12
Figuur 3-4 de 2 configuraties CDC en CLDC 13
Figuur 3-5 de levenscyclus van MIDP 14
Figuur 3-6 Mobile Information Device Profile (MIDP) 14
Figuur 3-7 de levenscyclus van een Xlet 17
Figuur 3-8 De Windows CE architectuur 19
Figuur 3-9 NET Compact Framework versus het NET desktop Framework 21
Figuur 3-10 De architectuur van het Compact Framework 22
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21 31
Figuur 4-1 de afhankelijkheden van de communicatietypes 43
Figuur 4-2 de Java connectie test 51
Figuur 4-3 klassestructuur van het testprogramma 51
Figuur 4-4 de MIDP Connectie Tester Applicatie 56
Figuur 4-5 network monitor tools in Wireless Toolkit 58
Figuur 4-6 de tijden per uitvoering 59
Figuur 4-7 de grootten van de aanvragen en antwoorden 60
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie) 61
Figuur 4-9 de testopstelling 62
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002 63
Figuur 4-11 de meetresultaten op de emulator 67
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms) 69
Figuur 4-13 een vergelijking van de communicatieprotocols 70
Figuur 5-1 de demonstratie-opstelling 75
Figuur 5-2 de verbindingsmodellen 76
Figuur 5-3 webinterface voor de lesgever in Claroline 77
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
v
JNI Java Native Interface
JVM Java Virtual Machine
KVM Kilobyte Virtual Machine
MIDP Mobile Information Device Profile
MSIL Microsoft Intermediate Language
NNTP Network News Transport Protocol
NSL Native Support Libraries
OEM Original Equipment Manufacturer
ORB Object Request Broker
OS Operating Service
OSGi Open Service Gateway initiative
OTA Over The Air
PInvoke Platform Invocation Services
PAL Platform Adaptation Layer
PDA Personal Digital Assistent
PDAP Personal Digital Assistent Profile
PE Portable Executable
Pm Personal Profile
RAM Read Access Memory
RMI Remote Method Invocation
SDK Software Development Kit
SDP Smart Device Project
SE Standard Edition
SOAP Simple Object Access Protocol
SQL Structured Query Language
TCPIP Transmission Control ProtocolInternet Protocol
UDDI Universal Description Discovery and Integration
UI User Interface
VM Virtual Machine
WAP Wireless Application Protocol
WBXML Wireless Binary XML
WebDAV Web-based Distributed Authoring and Versioning
WML Wireless Markup Language
WSDL Web Service Description Language
vi
XML Extensible Markup Language
XML-RPC Extensible Markup Language Remote Procedure Call
XSLT Extensible Stylesheet Language Transformations
vii
Inhoudstafel
Hoofdstuk 1 Inleiding 1
Hoofdstuk 2 Applicatieontwerp4
21 Mobiele Applicatie 4
211 Verbindingsvormen 4
212 Architecturale concepten 5
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen 6
22 Applicatievereisten 6
23 J2ME en CF 9
Hoofdstuk 3 Basistechnologieumln 10
31 J2ME 10
311 Configuraties en profielen 11
312 CDC vs CLDC 12
313 CLDC en MIDP 13
314 Connected Device Configuration 15
32 NET Compact Framework 18
321 Windows CE 18
322 Platform 19
323 NET Framework 20
324 NET Compact Framework 20
325 NET CF Platforms 22
33 Een eerste vergelijking 23
331 Algemeen theoretisch 23
332 Filosofie 28
333 Deployment en Area 28
334 Development Tools 29
335 Emulatie 30
336 Code 32
Hoofdstuk 4 Platformeigenschappen 33
41 Lokale data opslag 33
411 J2ME 33
viii
4111 MIDP en het Record Management System33
412 Compact Framework 38
4121 InputOutput 38
4122 XML38
4123 Relationele data opslag39
413 Conclusie 40
42 Netwerk 41
421 J2ME 41
4211 CLDC 42
4212 CDC 42
422 Compact Framework 43
4221 Web Services 43
4222 SQL Server en SQL Client44
4223 Pluggable Protocols44
4224 Low Level Sockets TCP UDP IrDa 45
423 Conclusie 45
43 Communicatieprotocols 45
431 Tekstformaat 46
432 XML 47
433 Webservices 47
4331 XML-RPC48
4332 SOAP48
434 Protocolvergelijkende testapplicatie in J2ME 49
4341 Opstelling 50
4342 Client-zijde 51
4343 Server-zijde 53
4344 Testmethode 55
4345 De resultaten 56
435 Protocolvergelijkende testapplicatie in CFNET 61
436 Conclusie 70
44 User Experience 70
441 J2ME 71
4411 MIDP71
4412 Personal Profile 71
442 NET 72
ix
443 Conclusie 73
Hoofdstuk 5 Implementatie van de applicatie74
51 Inleiding 74
52 Opstelling 75
53 WebService interface 77
54 Client applicatie 81
55 De totaalapplicatie en het illustratiebelang 85
56 Alternatieve opstelling 86
57 Uitbreidingen 88
Hoofdstuk 6 Besluit 90
61 Resultaten 90
62 Verder onderzoek 92
x
Lijst van figuren
Figuur 2-1 de flow van de applicatie 7
Figuur 2-2 de use cases van de demonstratie-applicatie 8
Figuur 3-1 Java toepassingsgebieden 10
Figuur 3-2 de edities en configuraties 11
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages 12
Figuur 3-4 de 2 configuraties CDC en CLDC 13
Figuur 3-5 de levenscyclus van MIDP 14
Figuur 3-6 Mobile Information Device Profile (MIDP) 14
Figuur 3-7 de levenscyclus van een Xlet 17
Figuur 3-8 De Windows CE architectuur 19
Figuur 3-9 NET Compact Framework versus het NET desktop Framework 21
Figuur 3-10 De architectuur van het Compact Framework 22
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21 31
Figuur 4-1 de afhankelijkheden van de communicatietypes 43
Figuur 4-2 de Java connectie test 51
Figuur 4-3 klassestructuur van het testprogramma 51
Figuur 4-4 de MIDP Connectie Tester Applicatie 56
Figuur 4-5 network monitor tools in Wireless Toolkit 58
Figuur 4-6 de tijden per uitvoering 59
Figuur 4-7 de grootten van de aanvragen en antwoorden 60
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie) 61
Figuur 4-9 de testopstelling 62
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002 63
Figuur 4-11 de meetresultaten op de emulator 67
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms) 69
Figuur 4-13 een vergelijking van de communicatieprotocols 70
Figuur 5-1 de demonstratie-opstelling 75
Figuur 5-2 de verbindingsmodellen 76
Figuur 5-3 webinterface voor de lesgever in Claroline 77
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
vi
XML Extensible Markup Language
XML-RPC Extensible Markup Language Remote Procedure Call
XSLT Extensible Stylesheet Language Transformations
vii
Inhoudstafel
Hoofdstuk 1 Inleiding 1
Hoofdstuk 2 Applicatieontwerp4
21 Mobiele Applicatie 4
211 Verbindingsvormen 4
212 Architecturale concepten 5
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen 6
22 Applicatievereisten 6
23 J2ME en CF 9
Hoofdstuk 3 Basistechnologieumln 10
31 J2ME 10
311 Configuraties en profielen 11
312 CDC vs CLDC 12
313 CLDC en MIDP 13
314 Connected Device Configuration 15
32 NET Compact Framework 18
321 Windows CE 18
322 Platform 19
323 NET Framework 20
324 NET Compact Framework 20
325 NET CF Platforms 22
33 Een eerste vergelijking 23
331 Algemeen theoretisch 23
332 Filosofie 28
333 Deployment en Area 28
334 Development Tools 29
335 Emulatie 30
336 Code 32
Hoofdstuk 4 Platformeigenschappen 33
41 Lokale data opslag 33
411 J2ME 33
viii
4111 MIDP en het Record Management System33
412 Compact Framework 38
4121 InputOutput 38
4122 XML38
4123 Relationele data opslag39
413 Conclusie 40
42 Netwerk 41
421 J2ME 41
4211 CLDC 42
4212 CDC 42
422 Compact Framework 43
4221 Web Services 43
4222 SQL Server en SQL Client44
4223 Pluggable Protocols44
4224 Low Level Sockets TCP UDP IrDa 45
423 Conclusie 45
43 Communicatieprotocols 45
431 Tekstformaat 46
432 XML 47
433 Webservices 47
4331 XML-RPC48
4332 SOAP48
434 Protocolvergelijkende testapplicatie in J2ME 49
4341 Opstelling 50
4342 Client-zijde 51
4343 Server-zijde 53
4344 Testmethode 55
4345 De resultaten 56
435 Protocolvergelijkende testapplicatie in CFNET 61
436 Conclusie 70
44 User Experience 70
441 J2ME 71
4411 MIDP71
4412 Personal Profile 71
442 NET 72
ix
443 Conclusie 73
Hoofdstuk 5 Implementatie van de applicatie74
51 Inleiding 74
52 Opstelling 75
53 WebService interface 77
54 Client applicatie 81
55 De totaalapplicatie en het illustratiebelang 85
56 Alternatieve opstelling 86
57 Uitbreidingen 88
Hoofdstuk 6 Besluit 90
61 Resultaten 90
62 Verder onderzoek 92
x
Lijst van figuren
Figuur 2-1 de flow van de applicatie 7
Figuur 2-2 de use cases van de demonstratie-applicatie 8
Figuur 3-1 Java toepassingsgebieden 10
Figuur 3-2 de edities en configuraties 11
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages 12
Figuur 3-4 de 2 configuraties CDC en CLDC 13
Figuur 3-5 de levenscyclus van MIDP 14
Figuur 3-6 Mobile Information Device Profile (MIDP) 14
Figuur 3-7 de levenscyclus van een Xlet 17
Figuur 3-8 De Windows CE architectuur 19
Figuur 3-9 NET Compact Framework versus het NET desktop Framework 21
Figuur 3-10 De architectuur van het Compact Framework 22
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21 31
Figuur 4-1 de afhankelijkheden van de communicatietypes 43
Figuur 4-2 de Java connectie test 51
Figuur 4-3 klassestructuur van het testprogramma 51
Figuur 4-4 de MIDP Connectie Tester Applicatie 56
Figuur 4-5 network monitor tools in Wireless Toolkit 58
Figuur 4-6 de tijden per uitvoering 59
Figuur 4-7 de grootten van de aanvragen en antwoorden 60
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie) 61
Figuur 4-9 de testopstelling 62
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002 63
Figuur 4-11 de meetresultaten op de emulator 67
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms) 69
Figuur 4-13 een vergelijking van de communicatieprotocols 70
Figuur 5-1 de demonstratie-opstelling 75
Figuur 5-2 de verbindingsmodellen 76
Figuur 5-3 webinterface voor de lesgever in Claroline 77
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
vii
Inhoudstafel
Hoofdstuk 1 Inleiding 1
Hoofdstuk 2 Applicatieontwerp4
21 Mobiele Applicatie 4
211 Verbindingsvormen 4
212 Architecturale concepten 5
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen 6
22 Applicatievereisten 6
23 J2ME en CF 9
Hoofdstuk 3 Basistechnologieumln 10
31 J2ME 10
311 Configuraties en profielen 11
312 CDC vs CLDC 12
313 CLDC en MIDP 13
314 Connected Device Configuration 15
32 NET Compact Framework 18
321 Windows CE 18
322 Platform 19
323 NET Framework 20
324 NET Compact Framework 20
325 NET CF Platforms 22
33 Een eerste vergelijking 23
331 Algemeen theoretisch 23
332 Filosofie 28
333 Deployment en Area 28
334 Development Tools 29
335 Emulatie 30
336 Code 32
Hoofdstuk 4 Platformeigenschappen 33
41 Lokale data opslag 33
411 J2ME 33
viii
4111 MIDP en het Record Management System33
412 Compact Framework 38
4121 InputOutput 38
4122 XML38
4123 Relationele data opslag39
413 Conclusie 40
42 Netwerk 41
421 J2ME 41
4211 CLDC 42
4212 CDC 42
422 Compact Framework 43
4221 Web Services 43
4222 SQL Server en SQL Client44
4223 Pluggable Protocols44
4224 Low Level Sockets TCP UDP IrDa 45
423 Conclusie 45
43 Communicatieprotocols 45
431 Tekstformaat 46
432 XML 47
433 Webservices 47
4331 XML-RPC48
4332 SOAP48
434 Protocolvergelijkende testapplicatie in J2ME 49
4341 Opstelling 50
4342 Client-zijde 51
4343 Server-zijde 53
4344 Testmethode 55
4345 De resultaten 56
435 Protocolvergelijkende testapplicatie in CFNET 61
436 Conclusie 70
44 User Experience 70
441 J2ME 71
4411 MIDP71
4412 Personal Profile 71
442 NET 72
ix
443 Conclusie 73
Hoofdstuk 5 Implementatie van de applicatie74
51 Inleiding 74
52 Opstelling 75
53 WebService interface 77
54 Client applicatie 81
55 De totaalapplicatie en het illustratiebelang 85
56 Alternatieve opstelling 86
57 Uitbreidingen 88
Hoofdstuk 6 Besluit 90
61 Resultaten 90
62 Verder onderzoek 92
x
Lijst van figuren
Figuur 2-1 de flow van de applicatie 7
Figuur 2-2 de use cases van de demonstratie-applicatie 8
Figuur 3-1 Java toepassingsgebieden 10
Figuur 3-2 de edities en configuraties 11
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages 12
Figuur 3-4 de 2 configuraties CDC en CLDC 13
Figuur 3-5 de levenscyclus van MIDP 14
Figuur 3-6 Mobile Information Device Profile (MIDP) 14
Figuur 3-7 de levenscyclus van een Xlet 17
Figuur 3-8 De Windows CE architectuur 19
Figuur 3-9 NET Compact Framework versus het NET desktop Framework 21
Figuur 3-10 De architectuur van het Compact Framework 22
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21 31
Figuur 4-1 de afhankelijkheden van de communicatietypes 43
Figuur 4-2 de Java connectie test 51
Figuur 4-3 klassestructuur van het testprogramma 51
Figuur 4-4 de MIDP Connectie Tester Applicatie 56
Figuur 4-5 network monitor tools in Wireless Toolkit 58
Figuur 4-6 de tijden per uitvoering 59
Figuur 4-7 de grootten van de aanvragen en antwoorden 60
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie) 61
Figuur 4-9 de testopstelling 62
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002 63
Figuur 4-11 de meetresultaten op de emulator 67
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms) 69
Figuur 4-13 een vergelijking van de communicatieprotocols 70
Figuur 5-1 de demonstratie-opstelling 75
Figuur 5-2 de verbindingsmodellen 76
Figuur 5-3 webinterface voor de lesgever in Claroline 77
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
viii
4111 MIDP en het Record Management System33
412 Compact Framework 38
4121 InputOutput 38
4122 XML38
4123 Relationele data opslag39
413 Conclusie 40
42 Netwerk 41
421 J2ME 41
4211 CLDC 42
4212 CDC 42
422 Compact Framework 43
4221 Web Services 43
4222 SQL Server en SQL Client44
4223 Pluggable Protocols44
4224 Low Level Sockets TCP UDP IrDa 45
423 Conclusie 45
43 Communicatieprotocols 45
431 Tekstformaat 46
432 XML 47
433 Webservices 47
4331 XML-RPC48
4332 SOAP48
434 Protocolvergelijkende testapplicatie in J2ME 49
4341 Opstelling 50
4342 Client-zijde 51
4343 Server-zijde 53
4344 Testmethode 55
4345 De resultaten 56
435 Protocolvergelijkende testapplicatie in CFNET 61
436 Conclusie 70
44 User Experience 70
441 J2ME 71
4411 MIDP71
4412 Personal Profile 71
442 NET 72
ix
443 Conclusie 73
Hoofdstuk 5 Implementatie van de applicatie74
51 Inleiding 74
52 Opstelling 75
53 WebService interface 77
54 Client applicatie 81
55 De totaalapplicatie en het illustratiebelang 85
56 Alternatieve opstelling 86
57 Uitbreidingen 88
Hoofdstuk 6 Besluit 90
61 Resultaten 90
62 Verder onderzoek 92
x
Lijst van figuren
Figuur 2-1 de flow van de applicatie 7
Figuur 2-2 de use cases van de demonstratie-applicatie 8
Figuur 3-1 Java toepassingsgebieden 10
Figuur 3-2 de edities en configuraties 11
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages 12
Figuur 3-4 de 2 configuraties CDC en CLDC 13
Figuur 3-5 de levenscyclus van MIDP 14
Figuur 3-6 Mobile Information Device Profile (MIDP) 14
Figuur 3-7 de levenscyclus van een Xlet 17
Figuur 3-8 De Windows CE architectuur 19
Figuur 3-9 NET Compact Framework versus het NET desktop Framework 21
Figuur 3-10 De architectuur van het Compact Framework 22
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21 31
Figuur 4-1 de afhankelijkheden van de communicatietypes 43
Figuur 4-2 de Java connectie test 51
Figuur 4-3 klassestructuur van het testprogramma 51
Figuur 4-4 de MIDP Connectie Tester Applicatie 56
Figuur 4-5 network monitor tools in Wireless Toolkit 58
Figuur 4-6 de tijden per uitvoering 59
Figuur 4-7 de grootten van de aanvragen en antwoorden 60
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie) 61
Figuur 4-9 de testopstelling 62
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002 63
Figuur 4-11 de meetresultaten op de emulator 67
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms) 69
Figuur 4-13 een vergelijking van de communicatieprotocols 70
Figuur 5-1 de demonstratie-opstelling 75
Figuur 5-2 de verbindingsmodellen 76
Figuur 5-3 webinterface voor de lesgever in Claroline 77
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
ix
443 Conclusie 73
Hoofdstuk 5 Implementatie van de applicatie74
51 Inleiding 74
52 Opstelling 75
53 WebService interface 77
54 Client applicatie 81
55 De totaalapplicatie en het illustratiebelang 85
56 Alternatieve opstelling 86
57 Uitbreidingen 88
Hoofdstuk 6 Besluit 90
61 Resultaten 90
62 Verder onderzoek 92
x
Lijst van figuren
Figuur 2-1 de flow van de applicatie 7
Figuur 2-2 de use cases van de demonstratie-applicatie 8
Figuur 3-1 Java toepassingsgebieden 10
Figuur 3-2 de edities en configuraties 11
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages 12
Figuur 3-4 de 2 configuraties CDC en CLDC 13
Figuur 3-5 de levenscyclus van MIDP 14
Figuur 3-6 Mobile Information Device Profile (MIDP) 14
Figuur 3-7 de levenscyclus van een Xlet 17
Figuur 3-8 De Windows CE architectuur 19
Figuur 3-9 NET Compact Framework versus het NET desktop Framework 21
Figuur 3-10 De architectuur van het Compact Framework 22
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21 31
Figuur 4-1 de afhankelijkheden van de communicatietypes 43
Figuur 4-2 de Java connectie test 51
Figuur 4-3 klassestructuur van het testprogramma 51
Figuur 4-4 de MIDP Connectie Tester Applicatie 56
Figuur 4-5 network monitor tools in Wireless Toolkit 58
Figuur 4-6 de tijden per uitvoering 59
Figuur 4-7 de grootten van de aanvragen en antwoorden 60
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie) 61
Figuur 4-9 de testopstelling 62
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002 63
Figuur 4-11 de meetresultaten op de emulator 67
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms) 69
Figuur 4-13 een vergelijking van de communicatieprotocols 70
Figuur 5-1 de demonstratie-opstelling 75
Figuur 5-2 de verbindingsmodellen 76
Figuur 5-3 webinterface voor de lesgever in Claroline 77
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
x
Lijst van figuren
Figuur 2-1 de flow van de applicatie 7
Figuur 2-2 de use cases van de demonstratie-applicatie 8
Figuur 3-1 Java toepassingsgebieden 10
Figuur 3-2 de edities en configuraties 11
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages 12
Figuur 3-4 de 2 configuraties CDC en CLDC 13
Figuur 3-5 de levenscyclus van MIDP 14
Figuur 3-6 Mobile Information Device Profile (MIDP) 14
Figuur 3-7 de levenscyclus van een Xlet 17
Figuur 3-8 De Windows CE architectuur 19
Figuur 3-9 NET Compact Framework versus het NET desktop Framework 21
Figuur 3-10 De architectuur van het Compact Framework 22
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21 31
Figuur 4-1 de afhankelijkheden van de communicatietypes 43
Figuur 4-2 de Java connectie test 51
Figuur 4-3 klassestructuur van het testprogramma 51
Figuur 4-4 de MIDP Connectie Tester Applicatie 56
Figuur 4-5 network monitor tools in Wireless Toolkit 58
Figuur 4-6 de tijden per uitvoering 59
Figuur 4-7 de grootten van de aanvragen en antwoorden 60
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie) 61
Figuur 4-9 de testopstelling 62
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002 63
Figuur 4-11 de meetresultaten op de emulator 67
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms) 69
Figuur 4-13 een vergelijking van de communicatieprotocols 70
Figuur 5-1 de demonstratie-opstelling 75
Figuur 5-2 de verbindingsmodellen 76
Figuur 5-3 webinterface voor de lesgever in Claroline 77
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
xi
Figuur 5-4 klassediagram van de applicatie 82
Figuur 5-5 de flow met screenshots 84
Figuur 5-6 de gatewayproxy server opstelling 87
Figuur 5-7 gecombineerde opstelling 88
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
xii
Lijst van tabellen
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME 24
Tabel 3-2 de belangrijkste besturingssystemen per type toestel 28
Tabel 4-1 de testresultaten in J2ME 57
Tabel 4-2 de grootte van de berichten 59
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie 60
Tabel 4-4 de meetresultaten op de emulator (in ms) 66
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms) 68
Tabel 4-6 de ondersteunde Controls in CF 72
1
Hoofdstuk 1
Inleiding
Inherent aan de mens is de behoefte om informatie te delen en te vergaren Informatie
wil immers verspreid worden onder diegenen waarvoor het bedoeld is In onze tijd van
overvloed aan informatiestromen is het adagium van Francis Bacon kennis is macht
zeker niet minder waar geworden De juiste informatie op het juiste moment en op
gebruiksvriendelijke wijze aanbieden en verwerven is in de 21ste eeuw een belangrijke
sleutel tot succes geworden
Zo ook voor studenten Reeds vanouds worden belangrijke mededelingen aan de
universiteitsvalven gehangen Na een bezoekje aan de advalvasmuren zijn de studenten
steeds ingelicht over alle mogelijke belangrijke mededelingen zoals examenroosters
lessenroosters wijzigingen afwezigheden etc Daar het leven en zo ook het
studentenleven steeds jachtiger en individueel verschillender wordt groeit de behoefte
om de advalvasinformatie rechtstreekser en sneller te kunnen raadplegen Dankzij de
opmars van geavanceerde mobiele toestellen wordt het mogelijk deze informatie overal
en ten alle tijde te raadplegen
Vandaar zal in dit afstudeerwerk een proof-of-concept elektronische advalvasapplicatie
voor mobiele toestellen ontwikkeld worden Nadat de studenten zich hebben
ingeschreven voor een cursus zullen zij automatisch op de hoogte worden gehouden
van de advalvasberichten die de docenten of assistenten plaatsen
De aard van de mobiele toestellen alsook de kosten en mogelijkheden van de
netwerkverbindingen brengen verschillende factoren met zich mee waar zeker rekening
mee dient te worden gehouden
2
Hoewel de gekozen applicatie zich situeert in de academische wereld en wat betreft
functionaliteit bewust eenvoudig gehouden werd blijft het basisidee van toepassing op
eender welke subscriber-subscribe gedistribueerde toepassing
Wat betreft de ontwikkelmogelijkheden voor dergelijke mobiele toepassingen voor
gelimiteerde omgevingen ontwikkelde Microsoft het Compact Framework (CF) en Sun
het Java 2 Micro Edition platform (J2ME) De beoogde applicatie dient dan ook als
testbank om de NET strategie die Microsoft voorstelt en de Java-omgeving van Sun
met elkaar te vergelijken
Doorheen dit afstudeerwerk zal de lezer vertrouwd gemaakt worden met de twee
gebruikte technologieeumln Tegelijk wordt de uitwerking van de applicatie op beide
platformen van naderbij bestudeerd en getest Daarna wordt een bespreking gegeven
van de bekomen bevindingen waarmee de sterkten en zwakten van beide technologieeumln
genuanceerd vergeleken worden
3
Het afstudeerwerk wordt als volgt opgedeeld
Hoofdstuk 1 Inleiding vormt de inleiding U bevindt zich hier
Hoofdstuk 2 Applicatieontwerp stelt de te ontwikkelen applicatie voor en belicht de
aandachtspunten Zo wordt de scope van het vergelijkend onderzoek afgelijnd
Hoofdstuk 3 Basistechnologieumln introduceert de basistechnologieumln Zowel J2ME als
het Compact Framework worden belicht Dit resulteert in een theoretische vergelijking
Hoofdstuk 4 Platformeigenschappen bespreekt de platformeigenschappen De
aandachtspunten uit hoofdstuk 2 worden hier in detail besproken voor zowel J2ME als
het Compact Framework
Hoofdstuk 5 Implementatie van de applicatie beschouwt de geiumlmplementeerde
toepassing Tevens worden hier een aantal scenario s voor de totaaloplossing
besproken
Hoofdstuk 6 Besluit geeft de besluitende conclusies en schetst de ruimte voor
eventueel toekomstig werk
4
Hoofdstuk 2
Applicatieontwerp
De advalvas applicatie stelt als doel de studenten te informeren van de laatste on-the-
minute informatie betreffende de door hun gevolgde cursussen Eerst zal in dit
hoofdstuk geiumlllustreerd worden dat deze applicatie een typische mobiele applicatie is
Daarna wordt geschetst wat de vereisten zijn Daaruit volgen enkele beschouwingen qua
applicatieontwerp zoals connectiviteit lokale data opslag en andere aandachtspunten
dewelke dan in de hiernavolgende hoofdstukken in detail belicht worden
21 Mobiele Applicatie
Laten we eerst definieumlren wat we verstaan onder een mobiele applicatie Een
applicatie is mobiel als deze resideert op een draagbaar computertoestel en is hetzij niet
hetzij altijd hetzij occasioneel verbonden met een netwerk Dit omvat applicaties die
draaien op notebooks personal digital assistants (PDA s) GSM s smartphones en
andere Het impliceert ook een zekere vorm van client-server architectuur de applicatie
die draait op het draagbaar toestel is dan de client van een service die beschikbaar is
op het netwerk
211 Verbindingsvormen
Toegang tot de service op het netwerk vereist een verbinding met het netwerk Deze
verbinding moet echter niet permanent te zijn We maken volgend onderscheid
- Niet verbonden De applicatie maakt nooit een verbinding met het netwerk
- Occasioneel verbonden De applicatie werkt vooral in offline modus Maar op
vooraf geplande tijdstippen of op vraag van de gebruiker wordt er een connectie
gemaakt met het netwerk Een klassiek voorbeeld is Palm synchronisatie
5
- Steeds beschikbare verbinding De applicatie verwacht een beschikbare
netwerkverbinding maar kan functioneren wanneer dit niet zo blijkt te zijn (en
dit gebrek tijdelijk opvangen) Hoewel sterk verwant met de eerste vorm schuilt
het verschil in de verwachting van de applicatie
- Altijd verbonden De applicatie vereist een netwerkconnectie Een typisch
voorbeeld is een browser die een websiteapplicatie draait op een GSM Hoewel
er een cache aanwezig kan zijn ligt de functionaliteit van de applicatie op de
server en is een verbinding dus absoluut noodzakelijk
Welke vorm er gebruikt wordt is vooral afhankelijk van het verwachte gebruik van de
applicatie en de capaciteiten van het doeltoestel Wij wensen de studenten de
mogelijkheid te geven advalvasberichten ook te bekijken wanneer hun toestel niet
verbonden is We kozen dus voor occasioneel verbonden Deze stelt immers de minste
eisen betreffende de connectievorm en laat in beperkte mate offline functionaliteit toe
212 Architecturale concepten
Occasioneel verbonden zijn impliceert dat de gebruiker de opdracht moet geven om de
informatie die zich op zijn toestel bevindt te synchroniseren met de informatie op de
server
Voor dergelijke applicaties zijn de volgende architecturale concepten belangrijk
- De behandeling van lokale data hoe kan lokale data ingelezen en opgeslagen
worden op beide platformen Welke technieken bestaan voor het behandelen
van zowel niet-verbonden data als data die gedownload wordt
- Toegang tot gegevens op een server verscheidene architecturen worden
geschetst om data op een geconnecteerde server te behandelen De aspecten in
verband met de synchronisatie worden toegelicht
- Gegevens weergeven aan gebruiker en interactie toelaten er is een interface
nodig tussen de gebruiker en de applicatie de gebruikersinterface
Deze zullen de belangrijkste aandachtspunten vormen voor de vergelijking tussen J2ME
en het Compact Framework Aangevuld met voldoende aandacht voor punten zoals
6
veiligheid het in gebruik nemen van de applicatie (deployment) en de uitdagingen en
leercurve voor de ontwikkelaar zullen we tot een gewogen conclusie kunnen komen
213 Aandachtspunten bij het ontwikkelen voor mobiele toestellen
Naast de conceptuele en architecturale aandachtspunten zijn er ook bijzondere
aandachtspunten eigen aan mobiele toestellen Hoewel Pocket PC-toestellen minder
beperkt zijn dan Palm en andere mobiele toestellen (GSM s pagers Smartphones)
worden ze toch allen beschouwd als gelimiteerd Men moet dit beschouwen in
vergelijking met de desktop toestellen Op een draagbaar toestel zijn de standaard
ontwerptechnieken die we kennen uit de desktop wereld niet altijd de beste keus De
prioriteiten zijn immers gewijzigd Uitvoeringssnelheid en het gebruik van het geheugen
en het scherm worden belangrijker dan elegante softwaredesignpatterns
22 Applicatievereisten
Een gebruiker heeft een login-naam en een wachtwoord Met deze unieke combinatie
kan de gebruiker zich identificeren op de server De identificatiegegevens moeten dus
opgeslagen worden op het toestel zodat automatische verificatie kan gebeuren Een
gebruiker heeft een selectie gemaakt van vakken Deze selectie bepaalt voor welke
vakken de advalvas dient te worden geraadpleegd De vakselectie is dus
gebruikerafhankelijk en wordt opgeslagen op de server Wanneer een lesgever een
advalvasbericht plaatst wordt dit op de server opgeslagen De verschillende gebruikers
kunnen dan de server bevragen en indien het desbetreffende vak in hun selectie
opgenomen is de advalvasberichten lezen
De beoogde core-applicatie flow is weergegeven in Figuur 2-1
7
M-VALVAS
- identify-help
X
LOGIN
PWD
X GO
USER DATA STORED ON
DEVICENO
IDENTIFY
M-VALVAS
- read valvas- post valvas-synchronize-re-identify
X
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
Show list of valvas msgs
X menu
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO
YES
Write msg
choose course
X POST
Figuur 2-1 de flow van de applicatie
Wanneer de applicatie gestart wordt moet bekeken worden of er lokaal
identificatieparameters van de gebruiker aanwezig zijn Indien niet dan wordt de
identificatie gevraagd van de gebruiker Deze parameters worden op de server
gevalideerd Indien de validatie toereikend is kan er alvast informatie (extra parameters
de laatste advalvasberichten) gedownload en op het toestel opgeslagen worden zodat de
gebruikersparameters gekend zijn voor een volgende sessie
Nu heeft de gebruiker verschillende opties
- Raadplegen van de advalvas De advalvas wordt beschouwd als een lijst waar
steeds de laatste x berichten aanwezig zijn De gebruiker moet controle hebben
over welke berichten hij wenst op te slaan en welke vervangen mogen worden
door nieuwere
- Plaatsen van berichten (indien voldoende rechten aanwezig)
- Synchroniseren van de data op het toestel en de data op de server
Synchronisatie kan handmatig of automatisch gebeuren Hierbij wordt aan de
server gevraagd of er nieuwe data is voor de gebruiker
8
- Identificatieparameters opnieuw instellen Dit komt neer op het verwijderen
van de huidige data specifiek voor de ingestelde gebruiker en een andere
gebruiker aanmelden
Mocht de applicatie ook daadwerkelijk gebruikt worden zijn naast voormelde
basisfunctionaliteiten tevens volgende functionaliteiten belangrijk
- registratie van gebruiker
- maken van vakselectie
- beheren van vakken en advalvaslijsten (voor lesgevers)
Deze functionaliteiten leveren echter geen nieuwe vergelijkingspunten en zijn
vergelijkbaar met de core-functionaliteiten Zij leveren dus geen nieuwe
discussiepunten Om die reden werden ze niet opgenomen in de demonstratieapplicatie
en bespreking
mobiele student
synchroniseeradvalvas
plaats bericht
mobiele lesgever
beheer (lokale)advalvas
identificatie
identificatie
AdvalvasSysteem op server
Lokaal AdvalvasSysteem
lees (lokale)advalvas
Figuur 2-2 de use cases van de demonstratie-applicatie
9
23 J2ME en CF
Zowel Java als NET hebben zoals zal blijken in het volgende hoofdstuk een limited
edition voor gelimiteerde toestellen repectievelijk Java 2 Micro Edition (J2ME) en het
Compact Framework (CF) Het applicatie-ontwerp wordt dus beiumlnvloed door de keuze
voor Java of NET In welke mate deze keuze bepalend is en welke consequenties dit
impliceert zal beschreven worden in volgende hoofdstukken
10
Hoofdstuk 3
Basistechnologieumln
31 J2ME
Java werd ontwikkeld door Sun Microsystems en is zowel een platform als een
programmeertaal Het Java platform kan opgedeeld worden in drie categorieeumln of
edities Java 2 Standard Edition (J2SE) Java 2 Enterprise Editition (J2EE) en Java 2
Micro Edition (J2ME) Figuur 3-1 (gebaseerd op referentie 31 en 32) toont de
verschillende toepassingsgebieden
Server
J2SEJ2ME
Workstations
PC Laptop
Cellphone
communicator
PDA
Smart phone
J2EE CLDCCDC
Set top box net TV
Figuur 3-1 Java toepassingsgebieden
Zoals uit de benaming reeds blijkt is J2SE het standaard Java platform Zij omvat de
Java 2 SDK SE en de Java 2 Runtime Environment SE J2SE is vooral bedoeld voor
11
desktop-applicaties J2EE is eerder een uitbreiding op J2SE en biedt extra
functionaliteit bovenop de Java 2 SDK SE voor enterprise applicaties J2EE bevat
API s zoals Enterprise Java Beans (EJB s) die enkel nuttig zijn op een server J2ME
daarentegen werd speciaal ontworpen voor mobiele toestellen Het heeft een beperktere
Java Virtual Machine en een erg beperkte set van API s Figuur 3-2 gebaseerd op
referentie 311 en 312 toont hoe de Java edities en configuraties onderling in
verhouding staan
J2EE
J2SE
J2MECDC
CLDC
Figuur 3-2 de edities en configuraties
311 Configuraties en profielen
Als we spreken over Java 2 Micro Editions (J2ME) spreken we in termen van
configuraties en profielen Een configuratie vormt de fundering voor de
basisfunctionaliteit Een profiel bouwt hierop verder zodat voor een specifiek toestel de
functionaliteit uitgebreid kan worden Daarboven kunnen nog optionele pakketten
(packages) gedefinieerd worden Fout Verwijzingsbron niet gevonden (gebaseerd op
referentie 31 en 33) toont de relaties tussen configuraties profielen en packages
12
J2ME
Optionele Packages
Optionele Packages
J2EE
J2SE
JVM
CDC
Foundation Profile
Personal Basis Profile
Personal Profile
KVM
CLDC
MID Profile
Optionele Packages
CVM
RMI
PDAProfile
Figuur 3-3 de positie van J2ME met de configuraties profielen en packages
Een configuratie bestaat uit een Java virtuele machine en een collectie van Application
Programming Interfaces (API s) dewelke samen een run-time omgeving vormen voor
het toestel Een profiel moet deze implementeren en kan er profielspecifieke API s aan
toevoegen Door het toevoegen van nieuwe profielen en optionele packages kan de
J2ME architectuur in de toekomst steeds uitgebreidere functionaliteit aanbieden aan
krachtigere toestellen
312 CDC vs CLDC
In J2ME zijn er momenteel twee configuraties gedefinieerd de Connected Limited
Device Configuration (CLDC) en de Connected Device Configuration (CDC) CDC
is bedoeld voor behoorlijk krachtige toestellen met een degelijke netwerkverbinding
(32-bit processoren met minimaal 2 MB geheugen) CLDC voor toestellen met
beperktere netwerk- geheugen- en CPU-capaciteiten (16- en 32-bit processoren met
minder dan 256KB geheugen) Elk beschrijft een minimaal aantal features die elk toestel
in de configuratie moet ondersteunen Figuur 3-4 toont dat CDC de klassieke virtuele
machine (CVM) gebruikt waar CLDC een kleinere java virtual machine de KVM
gebruikt (referentie 34)
13
Java Application
KVM + CLDCAPIs
Native APIs
Native OS
Device
Connected Limited Device Configuration
Java Application
CVM + CDC APIs
Native APIs
Native OS
Device
Connected Device Configuration
Figuur 3-4 de 2 configuraties CDC en CLDC
313 CLDC en MIDP
CLDC 10 definieert een basis voor pagers GSM s PDA s enz voor wat betreft basis
Java packages taaleigenschappen mogelijkheden van de virtuele machine netwerk en
IO veiligheid en internationalisatie Toestelspecifieke functies worden gedefinieerd
door profielen De Java virtuele machine vormt het hart van CLDC en voldoet aan de
Java Virtual Machine Specification en de Java Language Specification Er zijn echter
een belangrijk aantal uitzonderingen zoals geen bijstand voor floating point geen
finalisatie een beperkt aantal foutklassen om uitzonderingen op te vangen geen Java
Native Interface geen gebruikers gedefinieerde klasse laders geen thread groups
noch deamon threads Behalve enkele CLDC-specifieke klassen erven de meeste
van J2SE In maart 2003 werd de meest recente versie namelijk CLDC 11
goedgekeurd Deze heeft wel floating point ondersteuning en enkele andere
uitbreidende verbeteringen (zie referentie 35 en 36)
Momenteel is in CLDC het belangrijkste profiel het Mobile Information Device Profiel
(MIDP) Dit profiel is vooral bedoeld voor beperkte toestellen zoals GSM s en pagers
Er bestaat echter ook een implementatie voor Palm MIDP bereikt dus een heel scala
aan toestellen MIDP 10 heeft extra systeemvereisten voor het toestel bovenop de
onderliggende CLDC vereisten Maar het voorziet ook extra functionaliteiten beheer
van de levensloop van de applicatie (zie Figuur 3-5 gebaseerd op referentie 38)
gebruikersinterface gegevensopslag (persistent storage) netwerkfunctionaliteiten en
timers
14
Constructed
Paused Active
Destroyed
User endsMIDlet
MIDlet callsnotify Destroyed()
User endsMIDlet
Suspended by deviceMIDlet calls notify Paused ()
Started or resumed by device or MIDlet calls resume Request()
Figuur 3-5 de levenscyclus van MIDP
MIDP voorziet echter niet in API s op systeemniveau en levert geen extra veiligheid
bovenop wat CLDC specificeert zoals blijkt uit Figuur 3-6 (referentie 38) MIDP 20
voegt hier nog packages voor ontwikkeling van spelletjes geluid en certificaten voor
veilige netwerken bovenop (zie referentie 37)
Host platform operating system
MIDlets OEM Code
CLDC
MID
let e
nviro
nmen
t
Use
r In
terf
ace
Ne
twor
kin
g
Per
sist
ent s
tora
ge
= MIDP
Figuur 3-6 Mobile Information Device Profile (MIDP)
15
Naast MIDP zijn er nog een aantal andere profielen in ontwikkeling Zo is bijvoorbeeld
hoewel de eerste drafts dateren van juli 2000 het veelbesproken Personal Digital
Assistant Profile (PDAP) nog steeds in ontwikkeling (referentie 314)
314 Connected Device Configuration
CDC is een superset van CLDC en werd ontworpen voor toestellen met meer geheugen
en een betere netwerkverbinding Een CDC implementatie voldoet aan de Java
Language Specification en de Java Virtual Machine Specification en vormt dus een
complete set van API s om een virtuele machine te ondersteunen CDC ondersteunt ook
IO en datagrammen Er zijn momenteel drie belangrijke profielen beschikbaar die op
elkaar verder bouwen (als een stapel)
- Foundation Profile
Samen met CDC vormt dit profiel een ontwikkelomgeving voor beperkte
toestellen (zie referentie 39) De praktische toepassing van dit profiel alleen is
echter heel beperkt Het Foundation Profile definieert immers geen interface
features Het breidt CDC uit met een betere IO functionaliteit netwerk features
tekstverwerkingsmogelijkheden beveiliging en nog enkele andere javautil
classes (referentie 311)
- Personal Basis Profile
Dit profiel is bedoeld voor interactieve televisie en de automarkt Het
ondersteunt een eenvoudige gebruikersinterface In sommige gevallen is het
voor de fabrikanten interessant om enkel deze laag te implementeren zeker
indien het toestel geen rijkere user interface nodig heeft Dit profiel definieert
slechts een aantal van de basis AWT (Abstract Window Toolkit) klassen voor
bijvoorbeeld vensters knoppen en scroll bars Het definieert ook de Xlet (zie
later)
- Personal Profile (PP)
Dit profiel werd ontwikkeld als migratiepiste voor PersonalJava toepassingen
16
Het biedt ook extra Web-mogelijkheden PP is vooral bedoeld voor PDA s Het
specifieert drie applicatiemodellen Applets Xlets en Applications (zie
referentie 310) Personal Profile voegt volledige AWT functionaliteit toe voor de
gebruikersinterface Omdat PP geen JVM beperkingen heeft lijkt het op J2SE
De CVM
is echter wel geoptimaliseerd om te draaien in een kleinere
geheugenruimte
De CVM heeft een statische footprint van 256 KB De footprint in ROM voor CDC is
1011KB en het Foundation-profiel (met de CDC footprint geiumlncludeerd) is 1564 KB
(referentie 333)
CDCPP doelt op toestellen die zich niet thuis voelen in het gelimiteerde MID-profiel
Het kan gebruikt worden om applets Java-applicaties en Xlets aan te maken Applets en
Java applicaties zijn erfgoed van J2SE en gedragen zich niet anders op PP Xlets is een
nieuwe alternatieve manier om PP applicaties te maken
Een Xlet is meer een interface dan een klasse Dus eender welke klasse kan overerven
van de Xlet Het heeft vier mogelijke toestanden Loaded Active Paused en Destroyed
Figuur 3-7 (referentie 311) illustreert de mogelijke toestandsovergangen
17
Paused Active
Destroyed
Xlet callsnotify Destroyed()
orUser ends Xlet
Suspended by deviceXlet calls notify Paused ()
Started or resumed by device or Xlet calls resume Request()
Loaded
Constructed
Figuur 3-7 de levenscyclus van een Xlet
Het is dus duidelijk dat het Personal Profile meer features aanbiedt dan CLDCMIDP
De belangrijkste verschillen
- Collections
- Interface Capabilities
- Networking Features
- Local data storage
18
32 NET Compact Framework
321 Windows CE
Hoewel Microsoft reeds sinds 1992 investeert in mobiele technologieeumln duurde het tot
1996 wanneer Microsoft zijn eerste besturingssysteem voor mobiele toestellen
lanceerde Windows CE Omdat het gebaseerd is op de desktopversie ondersteunt
Windows CE een API die aldus heel vertrouwd is voor Windows-ontwikkelaars Het
werd ontwikkeld voor minder krachtige CPU s die geschikter zijn voor mobiele
toestellen Het ontwerp van Windows CE voldoet in het algemeen aan de volgende
principes
- weinig geheugenvereisten
- modulaire aanpak
- overdraagbaar op verschillende processoren
- compatibiliteit met Win32
- connectiviteit
- ware-tijdsverwerking
Omwille van de modulaire aanpak kan de laatste versie van Windows CE NET
opgesplitst worden in ongeveer 300 modules Hieruit kan gekozen worden om een OS
te bouwen De kleinst mogelijke versie is ongeveer 4 MB en past in ongeveer 200Kb
RAM (volgens referentie 315 en 316) De architectuur wordt geschetst in Figuur 3-8
(gebaseerd op referentie 316)
19
Toepassingen
Embedded Shell
Windows CE Shell ServicesRemote Connectivity
Win 32 APIsCoreDLL WinSock OLE CommCtrl CommDlg WinInet TAPI
Kernel Library
Graphic Windowing
Event Subsystem
Device Manager
File Manager
DriversDevice Drivers
File Drivers
OEM Hardware
TCPIPIrDA
OAL Bootloader
Microsoft
ISV OEM
ISV Developpers
OEM
Figuur 3-8 De Windows CE architectuur
Omdat Windows CE vanouds ontwikkeld werd voor PDA s bleef Microsoft ook
werken aan een verkleinde Windows versie voor gespecialiseerde toestellen Deze
resulteerden in Windows NT Embedded 40 en Windows XP Embedded Deze zijn
eigenlijk gemodulariseerde versies van de besturingsystemen voor de desktop Het
Compact Framework wordt op deze echter (nog) niet ondersteund (referentie 316
320)
322 Platform
Er is een verschil tussen Microsoft s definitie van een platform en een
besturingssysteem Een platform wordt gedefinieerd door de combinatie van de
hardware de programma s de modules de UI-componenten en een besturingssysteem
Een platform bepaalt aldus de karakteristieken van een reeks toestellen (analoog met
profielen in J2ME) Voorbeelden van dergelijke platformen zijn Handheld PC (Pro)
Platform Pocket PC Platform SmartPhone Platform Tablet PC
20
323 NET Framework
In dezelfde periode als de opkomst van XML Web Services als technologie voor
integratie tussen platformen ontwikkelde Microsoft de ontwikkelingomgeving Visual
StudioNET (VSNET) en het MS Windows NET Framework Het Framework bestaat
uit een nieuwe infrastructuur om programma s uit te voeren Het bevat een
uitvoeringsmotor de execution engine (EE) genaamd die als een soort virtuele machine
kan beschouwd worden Deze is in essentie de common language runtime (CLR) en een
hoop klassebibliotheken De CLR beheert het geheugen garbage collection behandelt
exceptions interageert met de onderliggende runtime services en garandeert
typeveiligheid
Als ontwikkelaar heb je de keuze om de applicatie te schrijven in een NET taal naar
keuze zoals VBNET of Visual C NET Bij het bouwen van de applicatie compileren
de NET compilers de code tot Microsoft Intermediate Language (MSIL) Deze
representatie van de code is onafhankelijk van het doelplatform De linker maakt
hiervan een Portable Executable (PE) bestand Deze bestanden kunnen uitgevoerd
worden op eender welk platform zolang er een NET CLR en alle benodigde NET
Framework klassebibliotheken aanwezig zijn
324 NET Compact Framework
Voor applicaties op toestellen uitgerust met het NET Compact Framework gebruikt
men dezelfde compilers als bij het volledige NET Framework Beide CLRs voeren
bestanden in hetzelfde PE-formaat (Portable Executable) uit Toch is de CF CLR een
totaal verschillende implementatie namelijk eacuteeacuten die geoptimaliseerd werd voor
beperktere toestellen De verschillen die zichtbaar zijn voor een ontwikkelaar blijven
echter relatief beperkt De belangrijkste verschillen zitten in de klassen die irrelevant of
zinloos zijn in Windows CE (ten opzichte van desktop versies) klassen die te groot zijn
of teveel rekenkracht vereisen en klassen waarvoor alternatieven bestaan Hierdoor
ondersteunt CF onder andere geen functionaliteiten zoals Remoting Xpath en XSLT
De vlakken met een zwarte achtergrond in figuur 3-9 (gebaseerd op referentie 316)
tonen de delen uit het desktop framework die niet geiumlmplementeerd werden in het
Compact Framework
21
SystemWeb SystemWinForms
SystemDrawing
SystemData SystemXml
System
ServicesDescriptionDiscoveryProtocols
Security
Configuration SessionState
UIHtmlControlsWebControls
Caching
ADONET
Design
SqlClient
SqlServerCE XsltXpath ReaderWriters
XmlDocument Serialization
Imaging Text
Drawing2D Printing
DesignComponent
Model
ConfigurationCollections
Security
Text
Globalization
IO
Ne
Reflection
Resources
Diagnostics
Threading
ServiceProcessRuntime
InteropServicesRemoting
Serialization
Figuur 3-9 NET Compact Framework versus het NET desktop Framework
De grootte van het CF geiumlnstalleerd op een toestel varieert van 17MB tot 26MB en kan
geplaatst worden in RAM ROM of FlashROM (volgens referentie 317 en 316)
Momenteel draait CF enkel op Windows CE 30 en Windows CE NET 41 Echter door
de aanwezigheid van de Platform Adaption Layer (PAL zie Figuur 3-10 gebaseerd op
referentie 316) en de Native Support Libraries (NSLs) leent CF zich ook tot andere
besturingssystemen De PAL zorgt ervoor dat de onderliggende functionaliteit van het
besturingssysteem en de hardware in een consistente manier bereikbaar is voor de NSL
en de EE zoals getoond in Figuur 3-10 De PAL is eigenlijk vergelijkbaar met een
driver voor een toestel Omdat niet alle toestellen dezelfde diensten aanbieden heeft CF
een groep van NSLs die de eigenschappen die CF vereist implementeren Deze diensten
maken dan aanroepen naar de PAL en worden zelf opgeroepen door de EE Op deze
manier kan CF draaien op een grote varieumlteit van toestellen
22
NET CF Toepassingen
Platform specifieke klassebibliotheken BCL s
EE (mscoreedll)
Host Besturingssysteem
PAL
NSL s
Figuur 3-10 De architectuur van het Compact Framework
325 NET CF Platforms
Het NET Compact Framework versie 1 wordt ondersteund op oa Pocket PC 2000
Pocket PC 2002 Pocket PC Phone Edition Pocket PC NET en Windows CENET
vanaf versie 41 (zie referentie 318) Onlangs werd dit lijstje ook aangevuld met het
SmartPhone 2003 Platform Er zullen er zeker nog vele volgen
23
33 Een eerste vergelijking
Zowel J2ME als Net CF zijn platformen voor mobiele smart clients Als men ze
vergelijkt met technologieeumln die micro-browsing toelaten zoals Wireless Application
Protocol (WAP) bieden smart clients veel betere GUI-mogelijkheden en ondersteunen
toestelspecifieke uitbreidingen (bijvoorbeeld Global Positioning System (GPS)) Als
men ze vergelijkt met smart clients op originele platformen (zoals eMbedded Visual
C++) verbeteren de Java en Net omgevingen de productiviteit van de ontwikkelaar de
betrouwbaarheid van de applicatie en de veiligheid van de code
Hoewel het Java-platform ouder en volwassener is zijn J2ME en het Compact
Framework op heel wat punten gelijkaardig Toch zijn er een aantal belangrijke
verschillen Deze zullen in dit deel besproken worden
331 Algemeen theoretisch
Zoals blijkt uit vorige paragrafen is CFNET een lichtere versie van het Net Framework
en draait het enkel op high-end PDAs met Windows CE of Pocket PC Bij J2ME ligt dat
enigszins anders J2ME bevat gestandaardiseerde configuraties en profielen Deze
zoeken het beste compromis tussen prestaties en overdraagbaarheid op een hele reeks
mobiele toestellen J2ME CDC richt zich dus naar high-end toestellen die vergelijkbaar
zijn met de hardware mogelijkheden op NET CF toestellen Het Personal Profile in
CDC heeft ongeveer dezelfde functionaliteiten als de oudere PersonalJava omgeving
J2ME CLDC richt zich daarentegen naar de low-end PDA s en kleine mobiele
telefoons CLDC heeft een kleine specifieke virtual machine die niet compatibel is met
J2SE of CDC
Volgende tabel gebaseerd op de white papers van Michael Juntao Yuan zoals
gepubliceerd in JavaWorld (zie referentie 319) geeft een overzicht van de belangrijkste
verschillen tussen Net CF en J2ME-CDCJ2ME-CLDC Deze tabel wordt hieronder
verder verklaard
24
Net CF J2ME CDC J2ME CLDC
Hardware vereisten van het toestel Hoog Hoog Relatief laag
Kost van het toestel Hoog Hoog Medium
Doelmarkt Bedrijven Bedrijven Consument
Platformen
Windows CE Pocket PC
Windows Mobile SmartPhone
Alle belangrijke mobiele platformen Alle mobiele platformen
Virtuele Machine NET CLR CVM KVM
Byte code compatibiliteit Standaard net CLR Standaard Java 2
Niet compatibel met J2SE of CDC
API compatibility Subset van Net Subset van J2SE en standaard optionele
packages
Gedeeltelijke compatibiliteit met CDC met extra optionele packages
Native APIs
PInvoke consistentie bij ondersteunde
toestellen
JNI specifiek voor toestel en besturingssysteem geen
Ontwikkel-omgevingen VSNet 2003
Command line vendor SDKs CodeWarrior
WebSphere
Command line vendor SDKs alle grote Java IDEs
Specificatie proces 1 bedrijf gemeenschap gemeenschap
Service gateway niet beschikbaar
Draai gateways als OSGi servlets draai gateway clients met verkoper-
specifieke SDKs
Draai gateway clients via verkoper-specifieke SDKs
Security model Vereenvoudigd Net
model Volledige Java
veiligheidsmanager
Beperkte Java 2 model uitgebreid met de OTA
specificatie
Client installatie ActiveSync Internet Explorer download Sync download
formele over-the-air (OTA1) specificatie
Life cycle management niet beschikbaar
OSGi2 voor gateway apps J2EE Client
Provisioning Specification voor generieke clients
Zit in de OTA spec werkt met J2EE Client
Provisioning Specificatie
Tabel 3-1 de belangrijkste verschillen tussen CFNet en J2ME
1 Over-The-Air 2 Open Service Gateway initiatief zie verder
25
Hardwarevereisten en kost van het toestel
Zowel CF als J2MECDC hebben relatief hoge vereisten aan de hardware van het
toestel in vergelijking met J2MECLDC Daaruit volgt uiteraard dat de kost van het
toestel lager is voor J2MECLDC
Doelmarkt
Hoewel de prijzen en de markten steeds dichter bij elkaar komen te liggen werd CLDC
MIDP vooral ontwikkeld met de consument in het achterhoofd waar CF en de CDC
configuratie eerder gericht waren naar een professioneel gebruik J2ME biedt ook als
enige een oplossing met zijn CLDC profielen voor de meest beperkte mobiele
toestellen
Platformen
Hier is er een groot verschil op te merken Het Compact Framework is enkel gericht op
Windows toestellen (en besturingssystemen) Men zou echter kunnen zeggen dat
dankzij de CLR Net code toch overdraagbaar is Er zijn echter nog geen niet-Windows
implementaties beschikbaar J2ME draait daarentegen op alle belangrijke platformen (er
zijn zo bijvoorbeeld implementaties beschikbaar voor Pocket PC Palm )
Virtuele Machine en byte code compatibiliteit
Dit werd behandeld in 31 en 32 Zowel CF als J2ME maken gebruik van een virtuele
machine De CFNET Common Language Runtime (CLR) draait standaard Net byte
code applicaties
API compatibiliteit
Zowel J2MECDC als CFNET gedragen zich als een subset van respectievelijk J2SE en
het desktop NET Framework Binnen J2ME is CLDC een gedeeltelijke subset van
CDC met een aantal standaard optionele packages (zie ook 31)
Native APIs
Het Compact Framework biedt de ontwikkelaar de mogelijkheid om op een consistente
manier (op alle ondersteunde toestellen) rechtstreeks native APIs te gebruiken Dit
gebeurt via Platform Invocation Services (PInvoke) Dit is een typische NET manier
26
om via managed code in de CLR calls te maken naar unmanaged DLLs
(bijvoorbeeld diegene die Win32 API implementeren)
J2ME biedt in CDC Java Native Interface (JNI) (zie referentie 332) aan Dit is een
standaard programmeerinterface om Java native methods te schrijven Hoewel het
eigenlijk hetzelfde doel deelt met PInvoke is JNI toestel- en
besturingssysteemspecifiek J2MECLDC heeft geen native API ondersteuning Hier
moeten de fabrikanten de specifieke functionaliteiten inbouwen in de run-time
Omdat Microsoft zowel het besturingssysteem als het platform bepaalt heeft Net CF in
vergelijking met J2ME een betere ondersteuning voor native methodes Men moet
echter sowieso het gebruik van native methodes zoveel mogelijk vermijden Enkel zo
kan men voordeel halen uit de robuustheid en veiligheid van een beheerde omgeving
Bij J2ME zorgt het gebruik van native methodes er zelfs voor dat de applicatie niet
meer overdraagbaar wordt
Ontwikkelomgevingen
Dit bespreken we meer in detail in 334
Specificatieproces
Over de vernieuwingen inzake de CFNET technologie wordt gewaakt door eacuteeacuten bedrijf
Microsoft Microsoft heeft echter wel veel oog voor de ontwikkelaargemeenschap en
beweert zich open op te stellen en dialoog aan te moedigen Echter de beslissing blijft
bij eacuteeacuten enkel bedrijf Aangezien CF enkel draait op Windows machines heeft het
bedrijf ook hier controle over J2ME werd echter ontworpen om crossplatform te zijn
De specificatie en de implementatie zijn dus twee afzonderlijke processen J2ME
specificaties worden gevolgd door een hele gemeenschap (het Java Community Process
(JCP)) Referentie 331 geeft een lijst met deelnemers (en deelnemende bedrijven) ter
illustratie Hoewel dit een bredere kijk op de dingen garandeert lijkt dit logge
specificatieapparaat wel voor behoorlijk wat vertraging te zorgen (bijvoorbeeld
referentie 314 die eigenlijk veel te laat klaar is) Wanneer de specificatie klaar is
kunnen de bedrijven deze implementeren Op die manier wordt de standaardisatie
gewaarborgd Microsoft kan daarentegen heel snel inspelen op nieuwe technologieeumln
27
Service gateway en life cycle management
Het Open Service Gateway initiatief (OSGi) is een Framework die een container vormt
voor dynamische software componenten (volledig J2ME-compatibel) Het framework
regelt de interacties tussen de componenten en laat de ontwikkelaars toe om op afstand
de hele levensloop van de MIDP-applicatie te beheren Dit omvat ook deployment
(plaatsing) en updaten over een netwerk (zie ook referentie 320)
De J2EE Client Provisioning laat de ontwikkelaar toe om applicaties en inhoud over een
netwerk te beheren Zie referentie 322 voor meer informatie
Dit is een eigenschap die enkel in J2MECDC ondersteund wordt
Security model
Veiligheid is een belangrijk aspect op mobiele toestellen Het beveiligen van het toestel
kan zo bijvoorbeeld omvatten power-on identificatie antivirus bescherming en het
toestel afsluiten Dit zijn echter opties die geen deel zijn van CF of J2ME maar die
geiumlmplementeerd moeten worden door het onderliggend besturingssysteem Hoewel er
veel te zeggen valt over de beveiliging van de connectieprotocols (bijvoorbeeld met
SOAP headers) en welke specifieke mogelijkheden J2ME en CF biedt zullen we hier
niet verder op ingaan Het belangrijkste is dat zowel CF als J2ME het
beveiligingsmodel van de desktop versies ongeveer overnemen Op deze manier zijn de
meeste concepten uit de desktop behouden
Zie ook referentie 334 voor een uitgebreid artikel over beveiliging
Client installatie
De J2ME Wireless Toolkit simuleert over-the-air (OTA) provisioning Dit laat de
ontwikkelaar toe de functionaliteit van de applicatie te testen en de volledige
provisioning uit te testen vanaf een webserver
Zie referentie 321 voor meer informatie over de recommended practice on Over The
Air User Initiated Provisioning
De deployment en area wordt in detail besproken in 333
28
332 Filosofie
J2ME is platformonafhankelijk maar taalafhankelijk Enkel de Java programmeertaal
kan gebruikt worden CFNET is taalonafhankelijk maar platformafhankelijk He draait
immers enkel op Windows CE (tot op heden althans via de PAL kan dit snel
veranderen) en laat meerdere programmeertalen toe Zo kunnen de bestaande Visual
Basic programmeurs nog steeds hun taal blijven spreken terwijl de C programmeurs
heel snel gewend zullen worden aan C
333 Deployment en Area
CFNet ondersteunt slechts eacuteeacuten besturingssysteem Windows En hoewel Windows CE
en Pocket PC OS op meer dan 250 toestellen draait maken de Windowstoestellen
slechts een beperkt deel van de markt uit
GSM
Motorola iDEN Nokia Symbian OS Qualcomm Brew + vendor
specific platforms (bv Nokia Series 40)
Low-end PDA Palm OS
Embedded
toestellen
Real Time OS (RTOS) zoals QNX Software Systems en Wind
River s VxWorks
High-end PDA s Windows + Symbian OS en Linux
Tabel 3-2 de belangrijkste besturingssystemen per type toestel
Het is dus vaak essentieel dat de applicatie kan draaien op zoveel mogelijk toestellen
En omdat veel van de toestellen uit Tabel 3-2 de belangrijkste besturingssystemen per
type toestel Java ondersteuning ingebouwd hebben en er third-party J2ME-runtimes
(van oa IBM) beschikbaar zijn voor alle mobiele platformen (ook Windows) is Java
hier de grote winnaar
Toch is de write once run anywhere ook op Java niet zo vanzelfsprekend vervuld
Daarvoor zijn de eigenschappen van de verschillende mobiele toestellen te divers En
hoewel er strikte J2ME-standaarden beschreven zijn toch zijn er kleine verschillen in
de beschikbare implementaties
29
Net heeft daartegen als voordeel dat het meerdere programmeertalen ondersteunt Op
die manier kunnen ontwikkelaars hun bestaande kennis makkelijker gebruiken om ook
mobiele oplossingen te gaan bouwen Toch moet de ontwikkelaar object georieumlnteerd
kunnen denken want de Net CLR heeft zelf een sterk object georieumlnteerde aard
334 Development Tools
Microsoft biedt de ontwikkelaar VSNET (Visual Studio Net) aan Dit is een enorm
krachtige IDE die eenzelfde interface heeft voor het ontwikkelen van zowel mobiele-
als desktopapplicaties Op die manier wordt het erg makkelijk om de
gebruikersinterface van een desktopapplicatie over te zetten in NET CF Zoals uit
hoofdstuk 4 zal blijken is ook ondersteuning voor Web Services en toegang tot
relationele data volledig geiumlntegreerd in de ontwikkelomgeving VSNET ondersteunt
ook het debuggen op emulatoren en op echte toestellen (via ActiveSync)
Hoewel VSNET een excellent product is is het niet goedkoop Er zijn nauwelijks
third-party IDE alternatieven of gratis command-line tools Wel zijn er een aantal
handige commercieumlle uitbreidingen en plug-ins verkrijgbaar Het Mono-project
(Referentie 323) gaat toch de concurrentie aan door een gratis ontwikkelomgeving voor
NET aan te bieden
Er zijn daarentegen een hele reeks J2ME command-line tools en toolkits beschikbaar
Sun J2ME Wireless ToolKit (referentie 324) is een veelgebruikte MIDP-
ontwikkelingstool Alle belangrijke Java IDE s hebben J2ME modules of plug-ins Om
de ruime keuze te illustreren maken we hier een lijstje (gebaseerd op referentie 319)
- Sun ONE Studio Community Edition met wireless modules (referentie 325) is
gratis en biedt heel goede ondersteuning voor enterprise features
- JBuilder met MobileSet (referentie 325) heeft een goede visuele UI-designer en
UML-ondersteuning
- CodeWarrior Wireless Studio (referentie 327) heeft veel nuttige third-party
tools Men kan zowel voor CLDC als op CDC ontwikkelen
- Eclipse IDE platform met J2ME plug-in (referentie 329 en 326) Dankzij de
plug-in kan men op deze gratis en populaire IDE draadloze software
ontwikkelen
30
- IBM WebSphere Studio Device Developer (referentie 328) is gebaseerd op het
Eclipse IDE platform Het ondersteunt debuggen van de code zowel in de
emulator als op het toestel (zoals VSNET) WebSphere wordt door velen
beschouwd als de beste beschikbare tool
- Voor een uitgebreidere lijst zie referentie 330
De grote moeilijkheid voor de IDE s is om de verkopers SDK s te integreren Elke
toestelfabrikant levert immers SDK s voor hun emulatoren en hebben een eigen set aan
J2ME uitbreidingen
335 Emulatie
Emulatie is het nabootsen ( emuleren ) van de functionaliteit van een toestel In dit
geval het emuleren van bijvoorbeeld een J2ME omgeving op Windows XP Emulatie is
niet gemakkelijk om juist te doen In een ideale emulatie zou het gedrag van het toestel
volledig nagebootst worden Maar de ontwikkelaars hebben vaak de tijd (of kennis) niet
om dit volledig accuraat te doen
Men kan de emulatoren opsplitsen in twee klassen
- concept emulatoren deze vertegenwoordigen geen specifiek toestel maar
dienen eerder om de algemene karakteristieken van een zeker soort toestel te
demonstreren Zo bijvoorbeeld de J2ME Wireless Toolkit emulator
- real-life emulatoren deze worden ontworpen om het uitzicht en gedrag van een
echt toestel na te bootsen De emulator kan daarvoor binaire code die op het
toestel zelf draait gebruiken
Vele fabrikanten van mobiele toestellen brengen eerst een concept emulator uit zodat
ontwikkelaars zich kunnen voorbereiden op het toestel Wanneer het toestel dan
uiteindelijk gelanceerd wordt verspreidt men een real-life emulator
De belangrijkste fabrikanten van GSMs bieden gratis emulatoren voor hun toestellen
aan
31
De Compact Framework ontwikkelaar heeft met Visual StudioNET twee excellente
emulatoren in zijn bezit de Pocket PC 2002 emulator en Windows CE emulator Deze
bieden true emulation ze bevatten exact dezelfde versie van het besturingssysteem de
EE en klassebibliotheken net zoals (beheerde) code op het toestel Deze emulatoren
draaien geiumlsoleerd van het gastheerbesturingssysteem en kunnen dus niet rechtstreeks de
gastheermachine betreden Interessant is dat men enkele instellingen kan maken in de
emulator om de applicatie te testen onder verschillende omstandigheden
Naast de Wireless Toolkit zijn er voor Java (en zeker in CLDC) een hele hoop
emulatoren beschikbaar Ook de Wireless Toolkit laat door middel van een aantal
instellingen verdere simulaties toe Zo kan men bijvoorbeeld de network throughput
simuleren de snelheid van de virtuele machine
Figuur 3-11 screenshot van de instellingen van de Wireless Toolkit 21
32
336 Code
Om de verschillen voor de ontwikkelaar duidelijk te illustreren zal in het volgende
hoofdstuk met fragmenten code geiumlllustreerd worden hoe men data lokaal opslaat welke
netwerkfunctionaliteit aanwezig is hoe de standaard communicatieprotocols
aangesproken kunnen worden en hoe we de gebruikersinterface kunnen opbouwen
Hiernaast zullen we ook enkele andere taaleigen aspecten belichten zoals thread-support
en XML-handling
33
Hoofdstuk 4
Platformeigenschappen
41 Lokale data opslag
Omdat mobiele toestellen niet steeds verbonden zijn met een netwerk (occasioneel
verbonden) is het lokaal opslaan en inlezen van data onontbeerlijk JAVA biedt
standaard in het J2ME MIDP-profiel het Record Management System (RMS) aan Deze
API is niet aanwezig in het J2ME Personal Profile In het Personal Profile heeft de
ontwikkelaar net zoals CFNET de mogelijkheid om bestanden en folders rechtstreeks te
lezen en schrijven (als er een bestandssysteem aanwezig is) Op het Compact
Framework wordt daarnaast standaard ADONET ondersteund waardoor relationele
data eenvoudig benaderd kan worden
411 J2ME
4111 MIDP en het Record Management System
De RMS API s zitten in javaxmicroeditionrms Centraal staat de
RecordStore-klasse die gebruikt wordt om alle operaties op de store uit te voeren
RecordStore Store = RecordStoreopenRecordStore( storenaam
true)
doe dingen met de store
StoreCloseRecordStore()
Informatie wordt in de record store opgeslagen in records en elke record is een array
van bytes We maken gebruik van ByteArrayOutputStream en
ByteArrayInputStream en de corresponderende DataOutputStream en
34
DataInputStream om eenvoudig te kunnen voldoen aan de verplichting om data op te
slaan als een array van bytes
ByteArrayOutputStream bos = new ByteArrayOutputStream()
DataOutputStream dos = new DataOutputStream(bos)
Omdat MIDP geen serialisatieschema aanbiedt is het opslaan van objecten niet
onmiddellijk mogelijk De objecten een serialisatie-interface laten implementeren is een
mogelijke oplossing
public abstract interface Serializable
public void writeObject(DataOutputStream dos)
throws IOException
public void readObject(DataInputStream dis)
throws IOException
Objecten die deze interface implementeren moeten dus twee extra methodes hebben
writeObject(DataOutputStream dos) en readObject(DataInputStream
dis)
public class User implements Serializable
private
String username
String password
public User(String username String password)
thisusername = username
thispassword = password
getters en setters
public void writeObject(DataOutputStream dos) throws
IOException
doswriteUTF(thisusername)
doswriteUTF(thispassword)
35
public void readObject(DataInputStream dis) throws
IOException
thisusername = disreadUTF()
thispassword = disreadUTF()
We kunnen vervolgens dit object opslaan in de store met volgende code
User u = new User( naam wachtwoord )
uwriteObject(dos)
byte[] byteArray = bostoByteArray()
storeaddRecord(byteArray 0 byteArraylength)
Bijzonder nuttig zijn de record listeners die de RMS API bevat Een object die de
RecordListener interface implementeert kan immers als een record listener
toegevoegd worden aan de store
storeaddRecordListener(this)
this moet interface implementeren
Op deze manier wordt het object gepolst bij het veranderen van de record store De
methodes recordAdded recordChanged en recordDeleted worden gedefinieerd
in de RecordListener interface
De fysieke opslag van de record store op het toestel is implementatieafhankelijk De
implementatie van de record store en waar het is opgeslaan varieert van platform tot
platform en is niet bepaald door de CLDCMIDP-specificaties Op PalmOS gebruikt de
MIDP-implementatie bijvoorbeeld een PalmOS database om zijn record store op te
slaan Dit is echter voor de ontwikkelaar onbelangrijk omdat het sowieso niet
aangeraden is rechtstreeks deze databasefunctionaliteiten te gebruiken maar steeds te
gebruik te maken van het RMS-systeem Het formaat van de database is immers niet
gespecificeerd en kan dus veranderen
36
De record store is gebonden aan de MIDlet suite en wordt ook verwijderd als de suite
verwijderd wordt Er zijn ook geen locking -operaties mogelijk
4112 Personal Profile
Personal Profile ondersteunt de RMS API niet Men kan echter interageren met het
bestandssysteem via klassen als File RandomAccessFile FileInputStream en
FileOutputStream
File file = new File( map bestandsnaam )
BufferedReader in = new BufferedReader(new FileReader(file)
for ()
String fileLine = inreadLine()
if (fileLine == null) break
doe iets met fileLine
Hoewel PP deze API s ondersteunt blijft het gevaar dat er geen bestandssysteem
aanwezig is op het toestel Als er wel een bestandssysteem is zoals bijvoorbeeld op de
Pocket PC 2002 kan er volledig gebruik gemaakt worden van de API s Er treedt dan
wel een portabiliteitsprobleem op De ontwikkelaar weet immers niet met zekerheid dat
de applicatie op elk beschikbaar toestel gaat werken Er bestaan immers ook toestellen
zonder bestandssysteem
4113 Relationele data opslag
Voor het MID-profiel zijn er verschillende third-party databases beschikbaar die meer
functionaliteiten bieden dan het RMS Hier enkele (commercieumlle) voorbeelden
- ReqwirelessDB (referentie 41) levert een JDBC API-package die lokaal is voor
de MIDP-toepassing Op de server is er een servlet component die de
databasetoegang uitvoert Op deze manier is er toegang mogelijk tot eender
welke JDBC-database vanuit een MIDP-applicatie
37
- PointBase Micro (referentie 42) is een implementatie van een subset van
J2SE s JDBC API Standaard SQL wordt gebruikt als querytaal Met een subset
van minder dan 45 KB (referentie 41) kan de database stand-alone op het
toestel fungeren of gesynchroniseerd worden via HTTP met PointBase UniSync
die op de server resideert De onderstaande code illustreert hoe de ontwikkelaar
met de DriverManager makkelijk toegang krijgt tot deze extra
functionaliteiten
ClassforName( compointbasemejdbcjdbcDriver )
Connection connection =
DriverManagergetConnection( jdbcpointbasemicrodemo
PBuser PBpass )
Statement statement = conncreateStatement()
DatabaseMetaData meta = conngetMetaData()
Resultset rs = metagetTables (null null TESTDBASE
null)
statexecute( INSERT INTO TESTDBASE VALUES(0) ) query
- IBM Cloudscape (ongeveer 2MB groot)
- Oracle 9i Lite (ongeveer 1MB groot)
- Sysbase UltraLite (ongeveer 150kb groot)
-
Ook in het Personal Profile is JDBC-ondersteuning (javasql packages) niet standaard
beschikbaar Deze interfaces zitten echter wel vervat in een aparte specificatie de
JDBC Optional Package voor CDCFoundation Profile (referentie 43) Net zoals bij
CLDC MIDP zijn er ook aantal commercieumlle pakketten beschikbaar die extra JDBC
functionaliteiten aanbieden Zo bijvoorbeeld PointBase Micro voor CDC met een
footprint van 89Kb
38
412 Compact Framework
4121 InputOutput
Ontwikkelaars kunnen op het Compact Framework gebruik maken van de klassen in de
SystemIO namespace De Stream klasse vormt het fundament in deze namespace en
representeert de stroom van bytes die gelezen of geschreven moet worden
FileStream is voor fysieke bestanden MemoryStream voor toegang tot het fysieke
geheugen Beiden erven over van Stream wat het mogelijk maakt het voordeel van
polymorfisme uit te buiten
De tweede component van SystemIO zijn de Reader en Writer klassen gebruikt
om bytes in en naar een Stream te schrijven en lezen SystemIO heeft ook enkele
klassen die specifiek met het bestandssysteem omgaan en interactie verzorgen met de
FileStream klasse
FileStream fs = new FileStream( filename FileModeCreate
FileAccessWrite FileShareNone)
StreamWriter sr = new StreamWriter(fs
SystemTextEncodingDefault 1024)
srWriteLine( dit is een eerste lijn in het bestand )
srClose()
CF ondersteunt ook asynchrone IO via directe draadmanipulatie (threadmanipulation)
en een elegante manier om de UI te updaten wanneer het werk verricht is Hiervoor
moet de ontwikkelaar de draden rechtstreeks manipuleren door gebruik te maken van de
SystemThreading namespace
4122 XML
Het Compact Framework heeft een subset van de XML-handling ondersteuning die men
terugvindt in het desktop Framework Deze zit in de SystemXml namespace Ondanks
enkele beperkingen (oa Xpath en Xsl is niet ondersteund) is er een rijke functionaliteit
voor handen om XML-documenten te schrijven en te lezen En dit kan zowel met de
DOM als met stream-based readers en writers
39
gebruik maken van DOM
Dim xmld As XmlDocument
laad xml bestand
xmldload(filename)
lees value van key
Value = xmldDocumentElementAttributes( key )Value
Omdat de DOM boom moet geladen worden vergt DOM meer verwerkingskracht en
extra geheugen om de boom op te slaan Zelfs de kleinste XML-documenten verlagen
alzo de performantie Net daarom werd de XmlReader-klasse ontworpen Deze
combineert de beste aspecten van DOM met de op gebeurtenissen gebaseerde XML-
API (SAX) in MSXML XmlReader is een abstracte basis voor XmlTextReader en
XmlNodeReader-klassen
Dim xmlr As XmlTextReader
xmlr = new XmlTextReader(filename)
Do While xmlrRead()
If xmlrIsStartElement Then
Value = xmlrGetAttribute( key ) lees de value
End If
Volgens tests is zelfs voor bijzonder kleine XML-documenten de XmlReader sneller
dan DOM Zo meldt referentie 316 voor eenvoudige documenten tussen 4KB en 8KB
een snelheidswinst van 25 door XmlReader te gebruiken
4123 Relationele data opslag
Het programmeermodel dat in het desktop framework gebruikt wordt om relationele
data te manipuleren heet ADONET en bestaat uit de klassen in de SystemData
namespace Ook in het Compact Framework is ADONET fundamenteel opgedeeld in
de DataSet en de gerelateerde klassen (de NET Data Providers) De data set wordt
gebruikt om de relationele data in eacuteeacuten of meerdere DataTable-objecten te plaatsen
Deze zijn allen volledig afgesloten van de brondata en zijn aldus ideaal voor
40
occasioneel verbonden scenario s De DataSet en de geassocieerde klassen zijn
volledig opgenomen in het Compact Framework
CF levert ook twee NET Data Providers de SqlClient provider om een SQL server (via
een verbinding) te bereiken en SqlServerCe voor de rechtstreekse toegang tot SQL
Server 2000 CE op het toestel Deze providers leveren alle functionaliteit om
commando s uit te voeren en data te bekomen Doordat elke provider steunt op dezelfde
grondklassen en interfaces (IdbConnection en DbDataAdapter) wordt consistentie
en polymorfisme aangeboden aan de ontwikkelaar Via hun respectievelijke adapters
kunnen NET Data Providers de functionaliteit aanbieden om data te lezen te schrijven
en te updaten in een DataSet Op deze manier kan DataSet gebruikt worden om
zowel met lokale als remote data te werken
Dim dataset As new DataSet()
haal gegevens uit xml naar dataset
datasetWriteXml(filename)
413 Conclusie
J2MECDC en CFNET laten beiden toe om rechtstreeks het bestandssysteem van het
toestel te benaderen Beiden bieden basis bestands-IO aan Voor wat betreft deze
functionaliteiten is er voor de desktopprogrammeur weinig verschil CF biedt echter
standaard ondersteuning voor XML-documenten en maakt polymorfisme erg handig
door een goed uitgekiend klassesysteem In J2ME moet men voor XML ondersteuning
beroep doen op third-party packages zoals kXML en NanoXML Relationele
gegevenstoegang is in CF standaard ondersteund met ADONET en SQL Server 2000
CE J2ME heeft ook hier nood aan third-party oplossingen zoals PointBase Micro die
JDBC-functionaliteiten toereiken
J2MECLDC MIDP heeft een eigen record store systeem (RMS) dat gekoppeld wordt
aan de suite Hier kan men enkel bytearrays naar schrijven en lezen Directe
bestandstoegang heeft op de meeste toestellen waar CLDC voor bedoeld is sowieso
geen zin omdat er geen bestandssysteem aanwezig is Net hier geeft CDC een
portabiliteitsprobleem Het gaat immers uit van de aanwezigheid van een
41
bestandssysteem Aangezien CF enkel draait op Windows-systemen treedt dit probleem
hier niet op
Hoewel de functionaliteiten in CF standaard groter zijn dan in J2MECDC voor wat
betreft lokale data manipulatie is er niets wat CDC niet kan door de juiste third-party
producten te gebruiken
Applicaties willen op afstand gelegen bronnen kunnen bevragen en er data van
ontvangen Daarvoor is een netwerkverbinding nodig In het volgende deel onderzoeken
we hoe dit zowel in J2ME als in CFNET in zijn gang gaat
42 Netwerk
Echte mobiele applicaties gaan overal mee met de gebruiker en laten het toe om
onderweg gegevens op te slaan en te bekijken Net hiervoor is toegang tot een netwerk
om die data op te halen of centraal op te slaan een belangrijke eigenschap Stand-alone
computers zijn voor wat het is maar mobiele applicaties komen pas echt tot hun recht
wanneer ze gegevens kunnen uitwisselen met andere toestellen en computers op een
netwerk
Het is dus geen verrassing dat zowel J2ME als het Compact Framework standaard een
ruime netwerk-API bieden We bekijken hier welke functionaliteit beide technologieeumln
standaard aanbieden In een volgend deel gaan we verder in hoe we bepaalde
communicatietechnologieeumln kunnen implementeren
421 J2ME
J2SE heeft een hele gevarieerde set van netwerkklassen Veel van die klassen bieden
veel meer functionaliteit dan een eenvoudig draagbaar toestel vereist J2SE bevat
klassen zoals Socket DatagramSocket HttpURLConnection ServerSocket
MulticastSocket InetAddress URL en URLConnection uit de javanet
package Elk protocol wordt dus benaderd door een verschillende klasse
42
4211 CLDC
J2ME CLDC heeft geen van deze netwerkklassen maar bevat een set van netwerk
API s het Generic Connection Framework (GCF) in javaxmicroeditionio In
het GCF handelt eacuteeacuten enkele klasse de Connector klasse alle ondersteunde
netwerkprotocollen af De code van de applicatie is dus steeds dezelfde onafhankelijk
van welk protocol gebruikt wordt
De CLDC configuratie definieert de basis netwerk API s die een CLDC-gebaseerd
profiel moet hebben Een profiel bepaalt hierboven specificaties inzake de protocols
MIDP moet zo bijvoorbeeld het HTTP protocol ondersteunen (en dat alleen)
Try
HttpConnection connection =
(HttpConnection)
Connectoropen( httpwwwugentbe
ConnectorREAD_WRITE)
catch (IOException x)
Systemerrprintln( Problems opening HTTP connection )
4212 CDC
Het J2ME CDC Personal Profile biedt naast de GCF ook een tweede API-set aan om
een netwerkconnectie te maken Deze is compatibel met de J2SE APIs (zoals
javanet HttpURLConnection zie boven) en garandeert op deze manier backward
compatibility met PersonalJava3 en upward compatibility met J2SE
try
URL url = new URL( httpwwwugentbe )
3 De voorloper van het Personal Profile Sun heeft deze met end-of-life bestempeld
43
HttpURLConnection conn = (HttpURLConnection)
urlopenConnection()
catch (IOException x)
Systemerrprintln(
Problems opening HTTP Connection )
Het Personal Profile vereist dat HTTP File TCPIP Socket en Datagram protocols
aanwezig zijn op elke Personal Profile implementatie Andere protocols zijn optioneel
422 Compact Framework
Net zoals het desktop Framework biedt het Compact Framework een varieumlteit aan
mechanismen voor netwerkcommunicatie Deze bestaan op verschillende
complexiteitsniveaus De meest complexe steunen op de aanwezigheid van lager
gelegen functionaliteiten (zie Figuur 4-1 gebaseerd op referentie 316)
SOAP SQL Server
HTTP Custom
TCP UDP IrDA
Sockets
Figuur 4-1 de afhankelijkheden van de communicatietypes
4221 Web Services
Microsoft stond mee aan de basis van de ontwikkeling van XML Web Services (zie ook
deel 43) Web Services zijn dan ook sterk in CFNET en VSNET geiumlntegreerd Het
Compact Framework ondersteunt standaard de consumptie van Web Services De
ontwikkelsnelheid ligt in het feit dat een Web Reference aanmaken in een Smart Device
Project (SDP) identiek is aan hoe je werkt in Windows Forms of een ASPNET-
applicatie VSNET neemt de taak van de XML-conversie van de data en de berichten
44
op zich Daarnaast handelt het ook de transmissie en authenticatie af Dit alles gebeurt
door middel van een Code-generation tool
ServiceHostNeededService webService = new
ServiceHostNeededService()
DataSet ds = WebServiceGetSomething( )
4222 SQL Server en SQL Client
Men kan data op een SQL Server van op afstand bereiken door gebruik te maken van de
NET Data Providers in CF uit de SystemDataSqlClient namespace Omdat SQL
Server zo bekend is voor desktop en server NET programmeurs kan ook hier voor hen
een behoorlijke leercurvewinst bekomen worden Wanneer de mobiele applicatie
gemaakt wordt in een bedrijf die veel gebruik maakt van Microsoft technologie zal
toegang op smart device architecturen aanbieden tot deze bestaande databronnen erg
snel kunnen
Omdat dit echter niet het doel vormt van dit afstudeerwerk zullen we niet dieper ingaan
op de functionaliteiten van SQLclient en zijn Provider architectuur
Het gebruik van SQLClient is vooral een goede keuze als er toegang tot data moet zijn
die groter is dan de client kan opslaan Het vereist ook meestal een full-time en
betrouwbare snelle verbinding
4223 Pluggable Protocols
Het compact Framework biedt een gelaagd en uitbreidbaar mechanisme voor
eenvoudige interacties met servers Dit klassemodel is gebaseerd op WebRequest en
WebResponse twee abstracte klassen in de SystemNet namespace De enige
pluggable protocols in het Compact Framework zijn HttpWebRequest en
HttpWebResponse Het model laat echter wel toevoeging van andere protocols toe
zoals FTP WebDAV4 of NNTP5
4 Web-based Distributed Authoring and Versioning Het is een set HTTP extensies die gebruikers de
mogelijkheid biedt om collectief bestanden op web servers te wijzigen en te beheren
45
WebRequest req = WebRequestCreate(new Uri(url))
WebResponse resp = reqGetResponse() vraag het antwoord
StreamReader r = new StreamReader(respGetResponseStream())
result = rReadToEnd() lees stream
rClose()
4224 Low Level Sockets TCP UDP IrDa
Soms is het nodig om te kunnen communiceren met andere systemen via low-level
protocols Sockets-based protocols geven de mogelijkheid in CF om op het laagste
niveau te werken De ontwikkelaar heeft de mogelijkheid om de methodes van de
Socket klasse te gebruiken of een van de klassen die erop gebaseerd zijn zoals
bijvoorbeeld TcpClient UdpClient of IrDAClient respectievelijk voor het TCP
het UDP en infraroodcommunicatie Er zijn ook steeds listeners mogelijk
Deze functionaliteiten zijn bijvoorbeeld uitermate handig voor het controleren of er een
verbinding aanwezig is zonder echt een verbinding te maken
423 Conclusie
J2ME en CF verschillen niet zozeer qua mogelijkheden Het Compact Framework biedt
echter een ruimere basismogelijkheid omwille van de standaard XML parsing
functionaliteiten en Web Services Omwille van de doordachte opbouw in CF is ook
polymorfisme met de ADONET providers mogelijk
43 Communicatieprotocols
De evolutie inzake softwareontwikkeling heeft reeds een lange weg afgelegd Van de
primordiale machinetalen tot de componentgebaseerde gedistribueerde
applicatieontwikkeling van hoger niveau Mobiele applicaties vertegenwoordigen de
ultieme gedistribueerde omgeving de clients draaien op een veelheid aan
5 Network News Transport Protocol een protocol voor de distributie aanvraag en plaatsen van nieuws
berichten dmv een betrouwbare stroomgebaseerde transmissie tussen de ARPA-internet community
46
besturingssystemen en kunnen overal gelocaliseerd zijn Desondanks moeten ze
interageren met servers om data te verkrijgen of up te daten
Objectgebaseerde gedistribueerde technologieeumln (zoals Java RMI Microsoft DCOM en
OMG s CORBA) berusten op een stuk software een Object Request Broker (ORB)6
Elk van deze ORB s interageren enkel met ORB s die dezelfde taal spreken Dit maakt
het uitermate moeilijk om een service te bouwen die door iedereen kan gebruikt worden
Omdat ORB s de ultieme thick clients zijn (vb op desktops) hebben ze niet
noodzakelijk veel zin op toestellen die sterk gelimiteerd in opslag en rekenkracht zijn
Voeg daarbij dat vele firewalls CORBA- en DCOM-berichten blokkeren Net om deze
problemen op te lossen werden protocols zoals XML-RPC en SOAP en het concept
Web Services ontwikkeld
We zullen een overzicht geven beginnende bij de eenvoudige
en zoals zal blijken -
efficieumlntste protocols om te eindigen bij de complexere berichtformaten
431 Tekstformaat
Het aanvraagantwoord-formaat kan erg eenvoudig gegenereerd worden Het is zuiver
het versturen van een HTTP GET en HTTP POST aanvraag naar een server Deze
server stuurt het antwoord terug
Het belangrijkste verschil tussen GET en POST is dat bij HTTP GET alle gegevens die
naar de server verstuurd moeten worden in de URL vervat moeten zijn Op die manier
kan men dus rechtstreeks naar een server een call doen enkel via de URL en de
parameters die erin zitten De parameters zijn echter eenvoudig tekstformaat en de
lengte ervan is beperkt tot de maximale request-lengte van de Web Server (8190bytes
bij standaard configuratie van Apache Web Server7)
6 Een Object Request Broker fungeert als middleware tussen de client en de server 7 Men kan echter de maximale request lengte instellen op de Apache Web Server en alzo grotere waarden
toelaten
47
De POST-methode is dus beter geschikt om grote hoeveelheden data (mogelijks binair)
van een mobiel toestel naar een server te sturen De data wordt immers onafhankelijk
van de URL naar de server meegestuurd
432 XML
De ontwikkelaar kan een berichtformaat opbouwen op basis van XML om data uit te
wisselen tussen client en server Zo kunnen de voordelen van XML het is een standaard
en aldus overdraagbaar ten volle benut worden XML is gebaseerd op tekst en de
gestructureerde gegevens kunnen eenvoudig geiumlnterpreteerd worden XML heeft om die
redenen een standaard-status in de industrie verworven Er wordt niet voor niets al sinds
1996 in diverse werkgroepen van het World Wide Web Consortium (W3C) gewerkt aan
deze standaard
Extra geheugen en berekeningskracht is essentieel om XML documenten te parsen De
beperkte capaciteit van het toestel kan dus leiden tot een vertraging bij het verzenden en
ontvangen
Een oplossing om de grootte van de XML-berichten te beperken is gebruik maken van
binaire compressie met XML Het WBXML formaat dat ook gebruikt wordt om WML-
pagina s te versturen (WAP) moet dan wel ondersteund worden door zowel de parser
op de client als de server8
433 Webservices
Web Services worden al jaren gehyped als agenten die de aard van software zullen
veranderen Elke applicatiecomponent kan immers beschikbaar gemaakt worden op het
internet als een service Maar voor een ontwikkelaar zijn Web Services slechts een
eenvoudige extensie op bestaande componentmodellen zoals Sun s Enterprise Java
Bean (EJB) of Microsoft s Component Object Model (COM) Het unieke is de
standaard set van protocollen die het mogelijk maken om de componenten te publiceren
in een directory terwijl ze zichzelf beschrijven en onderling communiceren via XML-
gebaseerde berichten over HTTP
Zowel XML-RPC als SOAP zijn twee XML-gebaseerde RPC-protocols die een extra
gestandaardiseerde laag toevoegen aan het XML-formaat
8 kXML van Enhydra ondersteunt WBXML
48
4331 XML-RPC
XML-RPC is een lichtgewicht berichtenprotocol die het mogelijk maakt om remote
procedures uit te voeren over een netwerk via HTTP De client zendt een XML-bericht
via HTTP POST De server parsed het bericht en voert de procedure uit De server geeft
dan een antwoord dat ook een XML bericht is terug aan de client XML-RPC maakt
gebruik van de voordelen van de eigenschappen van XML en creeumlert een minimale
functionaliteit door de parameters voor de remote procedures op een
platformonafhankelijk wijze te laten specificeren Om de scope zo klein als mogelijk te
houden werden de datatypes beperkt tot zes primitieve en uitgebreid met twee
complexe Net door deze compactheid is het protocol erg geschikt voor de meest
beperkte toestellen met trage en beperkte netwerken
4332 SOAP
Web Services onderscheidt zich van eerdere gedistribueerde componentarchitecturen
zoals CORBA DCOM of Java RMI door de platformonafhankelijkheid en de
universele overeenkomst qua standaarden Web Services op zich is tekstgebaseerde
XML en omdat het HTTP protocol gebruikt wordt voor het transport zijn er geen
problemen met firewalls
Drie open gespecificeerde XML-protocols vormen de steunpilaren voor Web Services
- Simple Object Access Protocol (SOAP)
SOAP definieert de enveloppe die de inhoud van een XML-bericht beschrijft
en hoe deze behandeld moet worden Hiernaast zijn er nog een aantal optionele
delen een aantal encodeerregels een standaardmethode voor RPC s en een
definitie van het uitzicht van een HTTP-bericht (met een SOAP-bericht)
- Web Service Description Language (WSDL)
WSDL geeft ontwikkelaars de mogelijkheid de karakteristieken van Web
Services te beschrijven Dit formaat is verstaanbaar voor andere Web Services
en vormt het contract tussen de Web Service en het oproepend programma
Men kan het vergelijken met de Interface Description Language bij CORBA
- Universal Description Discovery and Integration (UDDI)
UDDI is het protocol dat nog het minst ontwikkeld werd Het is een directory
die bedrijven toe zal laten elkaar te ontdekken en over het Internet met elkaar te
49
interageren zonder menselijke tussenkomst De specificatie is nog niet finaal en
de directory is niet nodig om Web Services te creeumlren en in gebruik te nemen
Een Webservice kan dus geschreven worden in eender welke taal en op eender welk
platform draaien zolang het maar een XML wrapper heeft die voldoet aan SOAP en
WSDL
Het grote voordeel ligt dus in de integratie Met Web Services kunnen loosely coupled
systems communiceren en functioneren onafhankelijk van het platform of de
programmeertaal Web Services bieden aldus een universele XML-interface aan
machines zodat ze gegevens kunnen uitwisselen in stateless op bericht gebaseerde
conversaties
Web Services kunnen dus beschouwd worden als een vernieuwing van XML-RPC
SOAP is echter steeds meer aan het evolueren naar een literal document approach
zodat Web Services meer een rich messaging stack vormen XML-RPC had als doel een
eenvoudige methode te zijn voor het gebruik van op afstand gelegen objecten SOAP
wil eerder een rijke berichten laag bieden
Voor mobiele toepassingen bieden Web Services aldus een mogelijkheid om zeer snel
de interactie te verzekeren tussen de client applicatie op het mobiele toestel en de
serverapplicatie Aldus kan de keuze voor het platform gebruikt op het mobiele toestel
onafhankelijk gemaakt worden van wat reeds beschikbaar is qua serverarchitectuur
Het nadeel ligt in het feit dat Webservices behoorlijk wat overhead hebben en features
die maar heel zelden gebruikt worden Deze verbruiken dan ook heel wat
systeembronnen Dit wordt onderzocht in de volgende delen
434 Protocolvergelijkende testapplicatie in J2ME
Zoals bleek uit 421 biedt J2ME enkel het GCF aan in CLDC CDC voegt daar nog de
J2SE API bij Deze functionaliteiten ondersteunen echter standaard geen XML parsing
en aldus ook geen XML-RPC of Web Services De J2ME ontwikkelaar is aldus
verplicht zelf in te staan voor deze functionaliteiten of om bestaande externe packages
50
te importeren Verschillende vrij beschikbare en commercieumlle oplossingen zijn hiervoor
echter wel beschikbaar (zie referentie 47- 410)
Onlangs in april 04 publiceerde Sun JSR 172 (referentie 44) Deze specificatie heeft
als doel een optioneel package te definieumlren dat een standaard toegang voorziet voor
J2ME-applicaties naar Web Services
Wij zullen echter de kSOAP implementatie (referentie 48) die gebaseerd is op kXML
(referentie 49) hier beknopt bespreken en door middel van een testimplementatie de
relatieve verschillen aantonen met de lower level protocols
4341 Opstelling
Voor de server wordt Tomcat (referentie 413) gebruikt Tomcat is de referentie
implementatie voor Java Server Pages (JSP) en de Servlet-specificaties Voor wat
betreft de SOAP-functionaliteit werd er gebruik gemaakt van Axis (referentie 414)
Axis is een Java implementatie van een SOAP-server en client Axis draait op een
applicatieserver of een servlet engine (zoals Tomcat)
Voor de client werd gekozen voor een MIDP 20 implementatie
De client wordt ge-emuleerd op dezelfde machine als waar de server draait
De testmachine is een Intel Pentium M processor 1500Mhz met 1 GB RAM
De emulator is de DefaultColorPhone uit de Sun Wireless Toolkit (WTK) 20
Er is dus geen sprake van netwerkvertragingen behalve eventuele beperkingen die door
de emulator opgelegd worden
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
Get Text Post Stream Text Get Stream Text Post XML-RPC en SOAP getest Dit
wordt schematisch weergegeven in Figuur 4-2
51
Tomcat ServerEmulator
AXIS
HTTP Post amp Get
Stream Text POST amp GET
XML-RPC
SOAP
Figuur 4-2 de Java connectie test
Zoals eerder beschreven ondersteunt CLDC MIDP standaard het HTTP-protocol Voor
wat betreft XML-parsing XML-RPC en SOAP moet er beroep gedaan worden op third-
party bibliotheken In deze testapplicatie werd er gekozen voor Enhydra kXML kXML-
RPC en kSOAP
4342 Client-zijde
kXML
+startApp()+pauseApp()+destroyApp()-test()
ConnectionTesterMIDlet
+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
+getRequest() Request
RequestFactory
TextRequest TextPostRequest StreamTextRequest
StreamTextPostRequest
SOAPRequest
XMLRPCRequest
kSOAP kXMLRPC
Figuur 4-3 klassestructuur van het testprogramma
52
Figuur 4-3 schetst het gebruik van de klassen in de connectie testapplicatie
ConnectionTesterMIDlet implementeert de MIDlet Wanneer de gebruiker op de
start knop drukt wordt de testprocedure gestart Deze vraagt voor elk protocol aan de
RequestFactory de klasse die Request interface implementeert Op deze manier
kan de testapplicatie makkelijk uitgebreid worden met extra tests
Elke connectiemethode implementeert de Request-interface Met de methodes
setOperation() en setParameter() kan respectievelijk ingesteld worden wat er
moet gebeuren (welke operatie) en welke de parameters zijn Execute() voert
vervolgens de request uit en zet het resultaat in de lokale private datamembers Met
getResult() kan het resultaat van de operatie opgevraagd worden
TextRequest en TextPostRequest duiden op het gebruik van InputStream en
OutputStream waar StreamTextRequest en StreamTextPostRequest doelen
op het gebruik van DataInputStream en DataOutputStream
Text GET
HttpConnection conn =
(HttpConnection) Connectoropen(URL + URLParam)
definieer de request methode als GET
connsetRequestMethod(HttpConnectionGET)
definieer HTTP header attributen
connsetRequestProperty( User-Agent ProfileMIDP-10
ConfigurationCLDC-10 )
connsetRequestProperty( Accept applicationoctetstream )
connsetRequestProperty( Connection close )
Haal het antwoord
InputStream is = connopenInputStream()
int contentlength = (int) conngetLength()
byte [] byteArray = new byte[contentlength]
53
if (contentlength gt 0) isread(byteArray)
result =
for (int I=0 IltbyteArraylength I++)
result += (char) byteArray[I]
isclose()
connclose()
Text POST
definieer de request methode als POST
connsetRequestMethod(HttpConnectionPOST)
definieer HTTP header attributen
idem als bij GET
byte[] data = URLParamgetBytes()
connsetRequestProperty( Content-Length
IntegertoString(datalength))
OutputStream os = connopenOutputStream()
oswrite(data)
osclose()
Haal het antwoord
idem als bij GET
4343 Server-zijde
Voor de serverzijde zijn er een aantal benodigde klassen en eenvoudige servlets die de
aanvragen van de Connectie Tester MIDlet moeten afhandelen en beantwoorden
- AdvalvasDBjava deze klasse stelt de database voor waaruit de informatie die
teruggegeven wordt moet komen De methode initDatabase() simuleert het
initialiseren van de database De methode getAdvalvasMessages() leidt in
54
deze testopstelling enkel tot een string met daarin de parameters die ze
meekrijgt since (long) username (string) en max (int) Deze stellen
respectievelijk de datum voor om nieuwe berichten moet worden op te halen de
gebruikersnaam en het maximaal aantal advalvasberichten dat mag
teruggestuurd worden
- AdvalvasServletTextjava deze klasse breidt HttpServlet uit Omdat het dus
een servlet is moet deze minimaal de volgende methodes implementeren
o init() initialisatie van de servlet
o getServletInfo() functie om informatie over de servlet te bekomen
o doPost() deze methode wordt opgeroepen door Tomcat wanneer er een
POST request op de servlet komt
o doGet() deze methode wordt opgeroepen wanneer er een GET request
op de servlet binnenkomt
Wanneer de servlet aangeroepen wordt worden de parameters zowel via GET
als POST gelezen en wordt hiermee de database (AdvalvasDB) opgevraagd
met getAdvalvasMessages() Het resultaat wordt als antwoord op de (GET
of POST) aanvraag teruggegeven en uitgeschreven op de output-stream
- AdvalvasWsXmlRpcjava deze klasse fungeert als wrapper klasse voor de
XML-RPC servlet (zie onder) Naast een constructor implementeert deze klasse
de functionaliteiten die via XML-RPC aangeboden zullen worden Wij
implementeren dus de functie getAdvalvasMessages Voor de eenvoud geeft
deze functie een string terug en verwacht ze drie strings als parameters (since
user en max) Dit vormt de semantiek van de remote procedure call
- AdvalvasServletWsXmlRpcjava deze klasse is net zoals
AdvalvasServletText een servlet maar heeft geen doGet() methode In de
init() functie wordt een XmlRpcServer() (uit orgapachexmlrpc)
gecreeumlerd en de wrapperclass AdvalvasWsXmlRpc (zie boven) er aan
toegekend De doPost() methode voert dan met de inputstroom de XML-RPC
uit Het resultaat van deze call wordt op de aanvraag teruggestuurd
- AdvalvasWsSoapjava deze klasse vormt net zoals de XML-RPC wrapper
klasse de semantiek van de SOAP web service De functie
55
getAdvalvasMessages() haalt ook hier met de parameters zijn antwoord uit
AdvalvasDB
De Servlets worden samen met de andere noodzakelijke klassen en bibliotheken
geplaatst onder de webapps -folder van Tomcat Na ze toe te voegen in de webxml
descriptor en de server te herstarten zijn ze bereikbaar
De SOAP web service moet in de Axis -folder geplaatst worden onder Tomcat Men
kan de webservice klassen bundelen in een JAR-bestand en die in de lib -folder zetten
zodat Axis ze kan vinden Of men kan de webserviceklasse een een jws extentie geven
en samen met de benodigde gecompileerde klassen plaatsen in de AxisWEB-INF -
folder Bij het herstarten van de server deployed Axis automatisch de webservice
Voor wat betreft de uitvoeringstijden werd er geen onderscheid gemaakt tussen de
latentie van het netwerk en de tijd die nodig is om de verzonden data te parsen Om dit
te doen zouden we de broncode van kSOAP en kXML-RPC implementaties moeten
wijzigen wat niet de bedoeling is
4344 Testmethode
De testmethode bestaat erin een testprocedure uit te voeren en voor elke actie de tijd te
meten De metingen zijn in milliseconden en worden als volgt bekomen
Get system time
long startTime = SystemcurrentTimeMillis()
Voer actie uit
timeGoneBy = SystemcurrentTimeMillis() startTime
De testprocedure bestaat uit een aantal keer een request uit te voeren en de tijd te meten
We gebruiken volgend algoritme
- Maak een eerste verbinding met het netwerk bij het starten van de
testprocedure wordt een eerste maal een enkele connectie gemaakt met het
netwerk Het blijkt immers dat dit de netwerkfunctionaliteiten activeert
56
waardoor hierna volgende acties een snellere tijd laten opmeten De eerste
verbinding wordt dus apart beschouwd in de metingen
- Voor elk protocolconnectiemethode
o Voer de actie 11 keer uit
o Schrijf tijd eerste keer uit
o Schrijf de gemiddelde tijd van de daarna volgende 10 keren uit
Bij elke actie worden de parameters aangepast zodat caching uitgesloten wordt
Figuur 4-4 de MIDP Connectie Tester Applicatie
De grootte van de berichten wordt gemeten door middel van de Network Monitor
(Figuur 4-5) die in de Wireless Toolkit 21 meegeleverd wordt
4345 De resultaten
De bovenstaande testprocedure werd drie keer herhaald De opgemeten tijden (in
milliseconden zijn samengebracht in Tabel 3-1)
57
J2ME MIDP (ms)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 1032 171 181
1st run avg 1st avg 1st avg
TextGet 50 32 50 42 60 41
TextPost 20 25 30 36 30 39
StreamTextGet 30 25 30 30 40 31
StreamTextPost 20 29 30 38 40 39
XML-RPC 167 161 210 209 211 216
SOAP 295 281 300 292 300 289
Tabel 4-1 de testresultaten in J2ME
Uit de resultaten uit Tabel 3-1 blijkt dat StreamTextGet de snelste tijden laat opmeten
Het is dus aangewezen DataInputStream te gebruiken en niet InputStream De
eerste maal dat de network first call uitgevoerd wordt neemt dit erg veel tijd in beslag
Dit is te wijten aan de initialisatie van het netwerk en het opbouwen van de objecten
(inladen) In de hierna volgende uitvoeringen is deze tijd tot 8 keer verminderd Wat
betreft de first run binnen de uitvoeringen zijn deze niet zo verschillend met het
gemiddelde We kunnen dus stellen dat eacuteeacutenmaal het netwerk geiumlnitialiseerd is (network
first call) de grootste barriegravere doorbroken is
Opmerkelijk is dat bij de GET-methoden er een positieve trend lijkt te zijn in de
opeenvolgende uitvoeringen voor wat betreft de eerste run (die is altijd trager dan het
gemiddelde dus winst bij opeenvolgende requests) Bij de POST-methoden treedt het
omgekeerde fenomeen op Indien dit niet aan de implementatie van de emulator te
wijten is kan men vermoeden dat het te maken heeft met de garbage collection die om
performantieredenen soms uitgesteld wordt Hierdoor kan er een tekort aan geheugen
ontstaan zodat de uitvoeringstijden beiumlnvloed worden
Een andere vaststelling is dat de uitvoeringstijden alsmaar trager worden bij
opeenvolgende uitvoeringen Ook dit is vermoedelijk te wijten aan de garbage
collection van de emulator
58
Figuur 4-5 network monitor tools in Wireless Toolkit
Verder onderzoek is hier echter aangewezen Het analyseren van meetresultaten bij de
plaatsing van de connectie-tester op een heel scala van emulatoren en toestellen tezamen
met een analyse van de CLDC- en emulatorimplementaties zou hier meer inzicht
verschaffen Men kan ook handig gebruik maken van de monitoring tools die de
Wireless Toolkit biedt om hier dieper inzicht te verkrijgen Figuur 4-5 is hiervan een
illustratie Het vormt echter een belangrijk onderzoek op zich en behoort niet tot het
doel van dit afstudeerwerk
59
0
50
100
150
200
250
300
350
1 2 3 4 5 6
TextGet
TextPost
StreamTextGet
StreamTextPost
XML-RPC
SOAP
Figuur 4-6 de tijden per uitvoering9
Figuur 4-6 geeft aan dat het relatief verschil tussen Tekst XML-RPC en SOAP erg
uitgesproken is Omwille van de XML-parsing heeft XML-RPC tot 5 keer meer
verwerkingstijd nodig om de aanvraag uit te voeren en het antwoord te verstaan SOAP
heeft omwille van de extra overhead (zie ook verder) nog meer verwerkingstijd nodig
SOAP doet het tot 10 keer minder snel dan via StreamTextPost
in bytes Text XML-RPC
SOAP
Grootte aanvraag 0 343 640
Grootte antwoord 46 167 514
totaal 46 510 1114
Tabel 4-2 de grootte van de berichten
Tabel 4-2 geeft de grootte in bytes weer van de berichten zoals gemeten via de network
monitor bij het uitvoeren van deze applicatie De tekstgebaseerde protocols sturen enkel
een korte header met URL- parameters XML-RPC verzendt daarboven 343 bytes en
9 1 is de eerste run van de eerste uitvoering 2 is het gemiddelde van de overige runs bij de tweede
uitvoering 3 en 4 zijn respectievelijk de eerste run en het gemiddelde voor de tweede uitvoering 5 en 6
voor de derde uitvoering
60
SOAP 640 bytes in een afzonderlijke stroom De langere lengte van de URL bij het
tekstprotocol werd niet in rekening gebracht maar deze overhead is relatief gezien
minimaal 10 Ook voor wat het antwoord betreft is de situatie gelijkaardig Het text-
protocol ontvangt de string van 46 bytes het XML-RPC antwoord is 167 bytes lang en
het SOAP antwoord omvat 514 bytes
0
200
400
600
800
1000
1200
Text XML-RPC SOAP
Grootte antwoord
Grootte aanvraag
Figuur 4-7 de grootten van de aanvragen en antwoorden
Opmerkelijk bij Figuur 4-7 is dat het totale data volume door SOAP verzonden bijna
twee keer zoveel is als bij XML-RPC Dit is erg belangrijk bij trage
netwerkverbindingen Het is ook belangrijk als de kost van een client-server applicatie
moet beschouwd worden De meeste GPRS-providers11 rekenen immers het gebruikte
datavolume door
in kilobytes Text XML-RPC
SOAP
Grootte client applicatie 643 3545 49
Tabel 4-3 de grootte van de client applicatie (in Kb) zonder obfuscatie
10 De parameterstring was immers kleiner dan 40 bytes 11 General Packet Radio Service httpwwwgsmworldcomtechnologygprsintroshtml
61
Tabel 4-3 geeft de grootte van de clientapplicatie weer wanneer deze enkel het
betreffende protocol zou implementeren De totale grootte van de testapplicatie bedraagt
zonder optimalisatie en obfuscatie 12 95 kb Aangezien er voor de tekst-protocols geen
extra klassebibliotheken moeten toegevoegd worden is de MIDlet-suite hier erg klein
minder dan 7Kb Door toevoeging van de kXML-RPC- en kSOAP-bibliotheken wordt
de grootte van de suite aanzienlijk uitgebreid respectievelijk tot 3545 Kb en 49 Kb
Deze groottes kunnen echter wel wat gereduceerd worden door middel van obfuscatie
0
10
20
30
40
50
60
Text XML-RPC SOAP
Figuur 4-8 de grootte van de client applicatie als alleen het gespecificeerde protocol
geiumlmplementeerd wordt (zonder obfuscatie)
435 Protocolvergelijkende testapplicatie in CFNET
Het Compact Framework ondersteunt het remoting concept van het desktop Framework
niet Voor wat betreft de connectiemethodes moet men zich dus beroepen op tekstuele
protocols of via Web Services Zoals eerder beschreven ondersteunt CF standaard web
services (SOAP) XML-RPC functionaliteiten worden echter niet standaard
aangeboden Daarvoor wordt er beroep gedaan op de populaire XML-RPC bibliotheek
te vinden op referentie 415
12 obfuscatie is een techniek die de variabelen hernoemt Naast bescherming van de code kan alzo ook de
applicatie kleiner gemaakt worden
62
4361 Opstelling en methode
De opstelling is vergelijkbaar met de opstelling voor de J2ME testapplicatie
Aangezien er geen NET specifieke protocols (zoals remoting) mogelijk zijn wordt er
gebruik gemaakt van dezelfde Tomcat Server als boven Dit heeft als voordeel dat de
response tijd van de server identiek is een vergelijkingszekerheid die wegvalt bij het
gebruik van Internet Information Server (IIS) Aangezien we voor de connectietests
geen gebruik maakten van serialisatie 13 is het scenario waar de server en de client
hetzelfde platform delen van geen belang
Net zoals in J2ME vergelijken we de protocols op zich We gebruiken een
remoteprocedure die een string teruggeeft Object serialisatie is ook hier niet van
toepassing
De testprocedure wordt tweemaal uitgevoerd Een eerste keer door middel van een
emulator die draait op dezelfde machine als de server Als emulator gebruiken we de
Pocket PC 2002 emulator die bij VSNET 2003 geleverd wordt De tweede keer voeren
we de testapplicatie uit op een Toshiba Pocket Pc die via WIFI verbonden is met de
servermachine
Om de relatieve verschillen aan te tonen tussen de communicatieprotocols worden Text
GET Text POST XML-RPC en SOAP getest
Tomcat Server
Emulator amp
Toshiba Pocket PC
AXIS
HTTP GET
HTTP POST
XML-RPC
SOAP
Figuur 4-9 de testopstelling
13 Serialisatie laat toe objecten efficient te encoderen en terug te decoderen
63
4362 De applicatie
De Connectietest applicatie voert dezelfde testmethode als in de J2ME testapplicatie uit
Eerst wordt er een first network call gegenereerd waarna dezelfde testprocedure
gestart wordt
Figuur 4-10 screenshot van de testapplicatie op een Pocket PC 2002
Zoals Figuur 4-10 illustreert wordt er een Text GET Text POST XML-RPC en SOAP
call uitgevoerd De meetresultaten worden telkens uitgeschreven
Wij geven hieronder een vereenvoudigd overzicht van de gebruikte code
Text methodes
64
Voor de Text methodes gebruiken we deze variabelen
string parameters = since=1+i+ampuser=toonampmax=3
string url =
http1921681231018080examplesservletAdvalvasServletTex
tPlain
Het antwoord wordt bij de Text methods als volgt opgehaald
vraag het antwoord
WebResponse resp = reqGetResponse()
Vraag de antwoordstroom op
Stream rec = respGetResponseStream()
StreamReader r = new StreamReader(rec)
lees de stream
result = rReadToEnd()
rClose()
Text GET
WebRequest req = WebRequestCreate(new Uri(url + +
parameters))
haal het antwoord op
Text POST
encodeer de parameters
SystemTextASCIIEncoding enc = new SystemTextASCIIEncoding()
byte [] data = encGetBytes(parameters)
Uri uri = new Uri( url )
WebRequest req = WebRequestCreate( uri)
reqMethod = POST
65
reqProxy = SystemNetWebProxyGetDefaultProxy()
reqContentType = applicationx-www-form-urlencoded
reqTimeout = 1000
reqContentLength = dataLength
schrijf de parameters
Stream s = reqGetRequestStream()
sWrite(data 0 dataLength)
sClose()
haal het antwoord op
XML-RPC
Xml RPC initialisatie
XmlRpcRequest client = new XmlRpcRequest()
clientMethodName = AdvalvasWsXmlRpcgetAdvalvasMessages
zet de parameters
clientParamsAdd( 11 ) since
clientParamsAdd(toon) user
clientParamsAdd(5) max
XmlRpcResponse resp =
clientSend(http1921681231018080examplesservletAdvalv
asServletXmlRpc)
result= (String) respValue
SOAP
De Web Service werd in VSNet toegevoegd aan de Web References Op die manier
kan via de automatisch gegenereerde code gewerkt worden Het object
AdvalvasWsSoapService wordt daarin gedefinieerd
initialisatie
AdvalvasWsSoapService aws = new AdvalvasWsSoapService()
66
parameters in methodeoproep
result = awsgetAdvalvasMessages((long) (10+i) toon 5)
De meetwaarden worden bekomen door middel van een hoge-resolutie timer Dit
mechanisme is echter niet ondersteund in CF en beroept zich op twee unmanaged API
functies QueryPerformanceFrequency en QueryPerformanceCounter Omdat de laatste
processorafhankelijk is bevragen we door middel van de eerste de frequentie van de
processor Om dit idee te encapsuleren is er de PerformanceTimer klasse (zie appendix
B) Deze klasse heeft twee functies Start() en Stop() Stop() geeft de gemeten tijd
terug
PerformanceTimer pt = new PerformanceTimer()
ptStart()
doe iets
long duration = ptStop()
4353 Resultaten op de emulator
De applicatie werd geplaatst op een Pocket PC 2002 Emulator Tabel 4-4 geeft de
meetresultaten van de drie herhalingen van de testprocedure weer
CFNET
(emulator) Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 660 129 60
1st run avg 1st avg 1st avg
TextGet 88 81 77 67 62 66
TextPost 125 89 93 83 77 74
XML-RPC 354 157 125 124 152 117
SOAP 771 204 424 169 178 143
SOAPinit 253 25 20
Tabel 4-4 de meetresultaten op de emulator (in ms)14
Hieruit blijkt dat ook hier de eerste uitvoering verantwoordelijk is voor veel langere
initialisatietijden De network first call neemt in de eerste uitvoering bijna zes keer
14 SOAPinit is de tijd nodig om het soapobject te creeumlren dit wordt apart gemeten
67
zoveel tijd in beslag als in de tweede De derde uitvoering doet hier nog eens de helft
van af Ook voor wat betreft de XML-RPC initialisatie merken we op dat dit geruim
meer tijd in beslag neemt Dit is te wijten aan het laden van de klassen en objecten om
de XML berichten op te stellen en te parsen De emulator implementatie maakt
vermoedelijk hergebruik van de SOAP enveloppe wat de verbeterde prestaties zou
verklaren Verder onderzoek is hier echter noodzakelijk
0
100
200
300
400
500
600
700
800
900
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-11 de meetresultaten op de emulator
Opmerkelijk is dat de tweede uitvoering een hoge eerste run waarde laat optekenen voor
het SOAP protocol (zie de lichtblauwe balk in de eerste run in de tweede uitvoering in
Figuur 4-11) Dit is vermoedelijk te wijten aan de implementatie van de emulator
Immers het lijkt alsof de emulator in de derde uitvoering geleerd heeft en veel betere
initialisatietijden laat opmeten Wij veronderstellen dat dit iets te maken heeft met hoe
de garbage collection geiumlmplementeerd is op de Pocket PC emulator In ieder geval is
dit iets wat niet optreedt wanneer we de applicatie draaien op een echt toestel (zie
verder) Ook hier is verder onderzoek aangewezen
Aangezien we gebruik maken van dezelfde testprocedure als bij de J2ME testapplicatie
is de relatieve verhoudingen van de berichtengrootten hetzelfde(zie 4345)
68
Aangezien het Compact Framework NET echter standaard de SOAP Web Services
bibliotheek aanbiedt kan men deze eenvoudig in een SDP referencieumlren en gebruiken
zonder de grootte van de applicatie te beiumlnvloeden Voor XML-RPC moet met zich
echter beroepen op een afzonderlijke implementatie bibliotheek Deze moet net zoals bij
de J2ME testapplicatie afzonderlijk bij de applicatie gevoegd worden De
XmlRpcCsdll bibliotheek die we nodig hebben voor XML-RPC is 36Kb Deze wordt
echter niet in de executable bijgevoegd (zoals in de JAR in J2ME) maar wordt bij het
plaatsen in de windows folder gecopieeumlerd Zo is de totale testapplicatie (slechts) 15Kb
groot
4354 Resultaten op Toshiba Pocket PC
De applicatie werd ook geplaatst op een Toshiba Pocket PC (Intel PXA 250 met 60MB)
die rechtstreeks via WIFI in verbinding staat met de Pentium-machine die Tomcat
draait
CFNET (Toshiba)
Eerste uitvoering
Tweede uitvoering
Derde uitvoering
network first call 2782 488 605
1st run avg 1st avg 1st avg
TextGet 316 146 149 234 126 151
TextPost 498 264 212 305 281 284
XML-RPC 3187 1364 1465 1184 1225 1137
SOAP 6626 1695 1055 1054 1041 1015
SOAPinit 1764 48 45
Tabel 4-5 de gemeten resultaten op Toshiba Pocket PC (in ms)
Hier merken we op dat de tijden algemeen beschouwd een factor 7 agrave 8 groter zijn dan
op de emulator Bij de eerste uitvoering zijn alle tijden in de eerste run behoorlijk groter
dan het daaropvolgende gemiddelde In de daaropvolgende uitvoeringen stabiliseert zich
dat (het omgekeerde doet zich zelfs soms voor) Zoals blijkt uit de Figuur 4-12 is het
verschil tussen Text XML-RPC en SOAP daardoor vooral in de eerste run in de eerste
uitvoering enorm uitgesproken De initialisatie van het SOAP object (SOAPinit) neemt
behoorlijk tijd de eerste keer Ook hier zijn deze resultaten te verklaren door een groot
aantal objecten en klassen die geladen moeten worden bij de initialisaties
69
Daaropvolgende uitvoeringen maken gebruik van het feit dat de Execution Engine deze
bronnen niet onmiddellijk terug vrijgeeft
0
1000
2000
3000
4000
5000
6000
7000
1st run avg 1st avg 1st avg
TextGet
TextPost
XML-RPC
SOAP
Figuur 4-12 de gemeten resultaten op Toshiba Pocket PC (in ms)
Opmerkelijk is dat vanaf de tweede uitvoering SOAP betere tijden laat opmeten dan
XML-RPC Misschien is dit niet zo verwonderlijk als we in acht nemen dat de XML-
RPC een bijgevoegde externe implementatie is Deze is misschien minder ge-
optimaliseerd als de standaard implementatie van SOAP web services
Deze resultaten tonen duidelijk aan dat Web Services in vergelijking met Textuele
protocols toch voor een behoorlijke overhead zorgen Naast de daaruitvolgende
netwerklatentie heeft dit ook een niet te loochenen invloed op de uitvoeringstijd Om de
soms eigenaardige resultaten op de emulator te verklaren is een uitgebreidere studie
vereist Een studie die verschillende plaatsingen op echte toestellen vergelijkt met
resultaten op emulatoren zal zeker tot enkele belangrijke best-practice besluiten kunnen
komen
Desondanks tonen deze resultaten aan dat het gebruik van Web Services toch niet
onoverwogen mag gebeuren
70
436 Conclusie
De meetresultaten in zowel J2ME als op het Compact Framework hebben een eenduidig
besluit Zuivere tekstuele communicatie zorgt voor een snellere verwerkingstijd op het
toestel (en op de server hoewel hier niet besproken) en zorgt ook voor een minder grote
bandbreedtebehoefte Figuur 4-13 stelt dit schematisch voor
Figuur 4-13 een vergelijking van de communicatieprotocols
We mogen echter de voordelen van een zelfbeschrijvend protocol niet uit het oog
verliezen Web Services laat het toe om objecten te omschrijven en de communicatie
tussen verschillende technologieeumln vlot te laten verlopen Wanneer we kiezen voor een
tekstueel protocol moeten we zelf de afspraken maken Zowel de client als de server
moeten hiervan op de hoogte zijn Vaak zorgt dit ook voor problemen bij het laten
interageren tussen verschillende technologieeumln (bijvoorbeeld een Java object
geserialiseerd versturen hoe gaat Net dit deserialiseren) De ontwikkelaar moet een
afweging maken tussen een methode die snel te implementeren is en die toekomstige
updates makkelijk maakt (en ook backwards compatibel) Web Services of voor een
eigen efficieumlnter protocol
44 User Experience
De gebruikersinterface (UI) is het deel van de applicatie die voor de gebruiker
misschien wel het belangrijkst is Een gebruiker beoordeelt vaak de kwaliteit van een
applicatie op basis van de elegantie en het gebruiksgemak van de interface En net door
71
de duidelijke verschillen tussen de UI mogelijkheden op mobiele toestellen en desktops
is het belangrijk te kijken op welke manier de ontwikkelaar een intuiumltieve
gebruikersinterface kan creeumlren
441 J2ME
CLDC en CDC definieumlren beiden niets over klassen voor de gebruikersinterface of hoe
applicaties geladen en geactiveerd moeten worden Dit wordt bepaald door de profielen
Wij zullen hier een beknopt overzicht geven van de mogelijkheden in CLDCMIDP en
CDCPersonal Profile
4411 MIDP
De user interface-klassen in het MID profiel zitten vervat in de
javaxmicroeditionlcdui package Deze biedt vijf soorten basis objecten
Ticker Displayable Display Alert en Command Displayable is de
ouderklasse van Screen en Canvas en kan een aantal Commands hebben Er zijn een
aantal Screens zoals Alert (die een meldingstekst toont) Form (een speciaal type dat
Items aanvaardt) List (een lijst met items) en TextBox (laat de gebruiker een tekst
ingeven) Voorts zijn er specifieke objecten die Alert als ouderklasse hebben
ChoiceGroup DateField Gauge ImageItem StringItem TextField enz
Aangezien dit profiel gericht is naar de meest gelimiteerde toestellen is het ook niet
verwonderlijk dat deze objecten slechts een summiere basisfunctionaliteit aanbieden
4412 Personal Profile
Het Personal Basis Profile biedt reeds een subset van de AWT package van J2SE aan en
heeft aldus lichtgewicht versies van onder andere deze klassen
javaawtComponent (de basisklasse)
javaawtContainer (de basisklasse voor AWT componenten die andere
componenten bevatten en beheren)
javaawtWindow de basisklasse voor top-level vensters
javaawtFrame een top-level venster met een titel
Het Personal Profile voegt hierbij nog een aantal klassen (zoals javaapplet
javaawt en javaawtdatatransfer) zodat het alle AWT-klassen uit J2SE 13
omvat behalve de tweedimensionale grafische klassen (javaawtPaint en
72
javaawtStroke) printklassen toegangsklassen (zoals
javaawtComponentAccessibleAWTComponent) en de javaawtRobot
klasse (referentie 411) PP heeft geen additionele klassen die niet in J2SE 13
gespecifieerd zijn
Het ontwikkelen van een rijke gebruikersinterface is dus erg vertrouwd voor J2SE
ontwikkelaars
442 NET
Hoewel de SystemWindowsForms namespace volledig herschreven werd voor CF
(voornamelijk omwille van performantie) bevat het toch hetzelfde basismodel als bij
het desktop Framework Bovendien is er in VSNET een form designer tool aanwezig
zodat de ontwikkeling van de UI even eenvoudig is als op de desktop Bovendien
ondersteunt het Compact Framework ook de creatie van custom controls waardoor de
functionaliteit van bepaalde componenten hergebruikt kan worden in verschillende
forms en projecten Tabel 4-6 (gebaseerd op referentie 316 amp 412) geeft de controls
weer die beschikbaar zijn op zowel CF als op het desktop Framework
Type Controls
Menus amp Toolbars MainMenu ContextMenu Toolbar
Place Holders Panel TabControl
Input CheckBox ComboBox DomainUpDown
NumericUpDown RadioButton TextBox
Sliders HScrollBar VScrollBar TrackBar ProgressBar
Images ImageList PictureBox
Display
Label TreeView StatusBar ListView ListBox
DataGrid
Non-visual Timer InputPanel OpenFileDialog SaveFileDialog
Tabel 4-6 de ondersteunde Controls in CF
Uiteraard werd de lookampfeel aangepast aan die van het toestel en zijn een aantal van de
eigenschappen gebeurtenissen en methodes weggelaten in vergelijking met het desktop
framework Er zijn enkele controls die niet in CF zitten zoals GroupBox RichTextBox
PrintDialog PrintPreview PrintPreviewControl CheckedListBox ColorDialog
73
FontDialog ErrorProvider ToolTip Dit is vooral te wijten aan de beperkingen van
het doeltoestel enof omdat Windows CE ze niet ondersteunt
CF ondersteunt ook de SystemDrawing namespace zodat bijvoorbeeld grafieken
rechtstreeks op het scherm gegenereerd kunnen worden
443 Conclusie
Voor wat betreft de gebruikersinterface bieden beide technologieeumln een ruime
functionaliteit J2ME biedt met de verschillende configuraties en profielen betere
aanpassingen aan de mogelijkheden van het toestel Dit betekent echter wel voor de
programmeur ook verschillende componenten en objecten CF gaat steeds uit van
dezelfde toolbox De verschillende platformen zullen hoogstens een verschil tonen in
de componenten door een aangepaste visualisatie Ook kan de CF programmeur uitgaan
van een aantal programma s die steeds aanwezig zijn op de client Dit biedt ook hier
uitwisselingsmogelijkheden
74
Hoofdstuk 5
Implementatie van de applicatie
51 Inleiding
Reeds in hoofdstuk 2 werden de vereisten van de applicatie bepaald Voor de uitwerking
kozen we voor het J2ME CLDC MIDP 20 profiel In plaats van een specifieke
demonstratie-serverapplicatie te schrijven (zoals we gedaan hebben in hoofdstuk 4)
hebben we gekozen om een bestaand systeem mobiel toegankelijk te maken Uiteraard
kan men zich daarvoor beroepen op een html-browser (die meestal standaard op het
toestel beschikbaar is) maar deze thesis richt zich zoals eerder vermeld op het
ontwikkelen van een stand-alone applicatie die zelf de data ophaalt en de gebruiker
toelaat om deze data lokaal te behandelen Zo kan de advalvas gebruikt worden zelfs
wanneer er geen verbinding beschikbaar is
Wij kozen in eerste instantie voor SOAP communicatie SOAP heeft het voordeel dat
het zelfbeschrijvend is waardoor de client en de server vooraf geen afspraken moeten
maken Welke webservices beschikbaar zijn zitten immers vervat in de WSDL
descriptor Een tweede voordeel is dat SOAP platformonafhankelijk en
taalonafhankelijk is Dit wordt treffend geiumlllustreerd door het gebruik van een derde
technologie (naast Java en NET) SOAP is ook aangezien het slechts bestaat uit XML
toestelonafhankelijk Bovendien garandeert het een veilige piste voor toevoegingen van
extra functionaliteit in de toekomst
We hebben in hoofdstuk 4 echter wel kunnen opmerken uit de connectietests dat Web
Services voor behoorlijk wat overhead zorgen Hoewel de graad van zelfbeschrijving en
het gebruiksgemak toeneemt is er ook meer verwerkingskracht en meer bandbreedte
vereist Daarbij komt nog dat J2ME standaard geen webservices aanbiedt waardoor we
de grootte van de MIDlet moeten verzwaren met een extra bibliotheek Net daarom
75
bespreken we ook in het tweede deel van dit hoofdstuk een alternatieve opstelling waar
we gebruik maken van een proxygateway server
52 Opstelling
Claroline (referentie 51) is een open-source electronische leer-omgeving (ELO)
gebruikt door de Universiteit Gent (echter recent herdoopt naar Minerva) Het is een
open-source PHP (Hypertext Preprocessor) applicatie die gebruik maakt van een
MySQL database PHP is een open-source scripting taal (zoals bijvoorbeeld Active
Server Pages (ASP) ColdFusion of Java Server Pages (JSP))
Deze ELO biedt een communicatieplatform voor studenten en hun lesgevers aan Eegraven
van de functionaliteiten is de advalvasfunctie Claroline biedt onder andere een
webinterface voor de registratie amp het beheer van de gebruikers
INTERNETMIDP 20Emulator
SOAP
HTML
Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
Figuur 5-1 de demonstratie-opstelling
Door gebruik te maken van een derde technologie (PHP naast Java of NET) kunnen we
het overkoepelende belang van Web Services extra benadrukken
76
Het is ook een typisch scenario waar er een bestaande applicatie aanwezig is waarvoor
er reeds een webinterface bestaat (HTML) Maar daarnaast wenst men een interface en
bepaalde functionaliteiten aan te bieden aan de mobiele gebruiker
Zo kunnen in onze applicatie de student en de lesgever berichten opvragen (met hun
identificatieparameters) De server zoekt welke vakken in de cv van de gebruiker zitten
en stuurt de (nieuwe) advalvasberichten Lesgevers kunnen daarnaast ook berichten
plaatsen
Voor administratiefuncties moet men zich in dit scenario beroepen op een rijkere client
waar men via een browser rechtstreeks de webapplicatie (PHP pagina s) op de server
betreedt
Hoeveel functionaliteit men biedt op de client hangt uiteraard af van de vereisten
NETWERK
Applicatie
Altijd steeds beschikbaar
Occasioneel
Niet
Figuur 5-2 de verbindingsmodellen
Zoals reeds in hoofdstuk 2 geschetst bevindt de applicatie zich in het occasioneel
verbonden model Er moet dus voldoende aandacht besteed worden aan het opslaan van
de verworven data en de mogelijkheid om die lokaal te behandelen Daarnaast moet er
data van de server gehaald worden Er is dus een netwerkverbinding nodig Deze
problematiek werd behandeld in hoofdstuk 4
77
Figuur 5-3 webinterface voor de lesgever in Claroline
53 WebService interface
Aangezien het claroline systeem resideert in een PHP omgeving hebben we gekozen
om de Web Services Server te schrijven in PHP Hoewel het logisch lijkt om dan de
geboden functionaliteiten en klassen van claroline te hergebruiken is dit na het
bestuderen van deze ELO omgeving niet aangewezen gebleken De Claroline
programmeurs hebben immers geen gebruik gemaakt van de object georieumlnteerde
mogelijkheden die deze scripting-taal biedt15 Wij moeten ons dus behelpen door het
systeem te bestuderen en rechtstreekse databasetoegang te implementeren Merk op dat
we ook hadden kunnen kiezen voor een andere scripting taal en vandaar de MySql
database rechtstreeks benaderen Als de bestaande applicatie reeds een goede
klassestructuur heeft is het bouwen van Web Services een minimale inspanning
We maken gebruik van de NuSoap implementatie (zie referentie 52) Er zijn ook
andere stabiele opties voor Web Services in PHP zo bijvoorbeeld de PEARSOAP
implementatie
We includeren eerst de bibliotheken voor de NuSoap server en voor een MySql
database abstractie laag
15 PHP biedt sinds versie 4 OO-ondersteuning Met de komst van versie 5 wordt dit nog verder
uitgebreid
78
includeren van de bibliotheken
require_once(nusoapphp) voor SOAP
require_once(classez_sqlphp) voor database
$NAMESPACE = httpugentbeAdvalvas
maak een nieuwe soap server object
$server = new soap_server
zet een aantal instellingen
$server-gtdebug_flag=false
$server-gtconfigureWSDL(Advalvas $NAMESPACE)
$server-gtwsdl-gtschemaTargetNamespace = $NAMESPACE
Volgende webservices hebben we gedefinieerd voor deze applicatie
Eerst specifieumlren we enkele nieuwe datatypes een gebruiker (user) een vak (course)
een valvasbericht (valvas) en twee datatype-arrays ValvasArray en CourseArray
Deze arrays worden gebruikt om collecties van datatypes door te sturen
definieer het datatype User
$server-gtwsdl-gtaddComplexType(
User
complexType
struct
all
array(
thename =gt
array(name=gtthenametype=gtxsdstring)
email =gt
array(name=gtemailtype=gtxsdstring)
)
)
soortgelijk voor Course
79
definieumler het datatype Valvas
$server-gtwsdl-gtaddComplexType(
Valvas
complexType
struct
all
array(
contents =gt array(name=gtcodetype=gtxsdstring)
date =gt array(name=gtdatetype=gtxsdstring)
course =gt array(name=gtcoursetype=gtxsdstring)
)
)
definieer het datatype ValvasArray (Valvas[])
$server-gtwsdl-gtaddComplexType(
ValvasArray
complexType
array
SOAP-ENCArray
array()
array(
array(ref=gtSOAP-ENCarrayTypewsdlarrayType=gttnsValvas[])
)
tnsValvas
)
Soorgelijk voor CourseArray
Dan specificeren we ook volgende webservice-methoden
- getCurrentDate() deze bevraagt de datum op de server en geeft deze in een
string terug Dit is belangrijk aangezien de client niet noodzakelijk dezelfde
tijdsinstellingen heeft als de server Deze waarde wordt gebruikt om de nieuwe
berichten op te halen De applicatie moet immers specificeren wanneer de laatste
synchronisatie gebeurd is
- checkLogin(string login string password) deze methode valideert de
parameters Indien de combinatie gevonden werd wordt de userid als antwoord
teruggegeven indien niet wordt er een negatieve foutcode teruggegeven
80
- getUserData(string login string password) deze methode geeft een User
datatype terug (indien de parameters gevalideerd zijn)
- getUserPostCourses(string login string password) deze methode geeft de
vakken terug (CourseArray datatype) waar de gebruiker die vervat zit in de
parameters voldoende rechten heeft om in te posten
- getUserValvas(string login string password int number long sincelast)
deze methode geeft een ValvasArray datatype terug dat alle valvasberichten
omvat die voor de gebruiker relevant zijn met number als maximaal aantal
terug te geven berichten (om een zekere controle te hebben op hoeveel data
maximaal per actie teruggegeven zal worden met andere woorden om de
gebruikersinteractie levendig te houden) en sinds sincelast
- postValvas(string login string password string contents string course)
deze methode plaatst indien de meegegeven gebruikersdetails genoeg rechten
hebben een bericht in de advalvas bij het vak course Het geeft terug of de actie
gelukt is
Deze methodes werden elk geschreven in PHP Wij illustreren de code hier voor
getUserData
registreer de methode op het server object
$server-gtregister(
getUserData
array(login=gtxsdstring password=gtxsdstring)
array(return=gttnsUser)
$NAMESPACE)
daarna wordt de gelijknamige functie in PHP geschreven
function getUserData ($login $pwd)
maak het database object
$db = new db(DB_USER DB_PASSWORD DB_NAME _DB_HOST)
controleer de loginparameters
$userid = checkLogin($login $pwd)
indien negatief = foutief
if ($useridlt0) return $userid
81
$q = SELECT concat(nom prenom) as thename email FROM
user WHERE user_id=$userid
$result = $db-gtget_row($q)
if ($db-gtnum_rows lt 1)
return -3 gebruiker niet gevonden
$user = array(
thename =gt $result-gtthename
email =gt $result-gtemail
)
return $user returneer de gebruikerdata (User datatype)
Op deze manier wordt de NuSoap Webservices Interface opgebouwd Door dit PHP
script in een web-accessible en door de PHP engine uitvoerbare folder te plaatsen wordt
de webservice beschikbaar gesteld Zie appendix A voor de WSDL die hieruit ontstaat
en die de webservice beschrijft
54 Client applicatie
Nu de webservice de functionaliteiten van Claroline aanbiedt kunnen we de
uiteindelijke applicatie maken Deze moet een gebruikersinterface bieden om de
webservices te gaan bereiken Daarnaast moeten we de data lokaal opslaan en er
bewerkingen op implementeren
82
kSOAP
+startApp()+pauseApp()+destroyApp()-test()
AdvalvasMIDlet+setOperation()+setParameter()+execute()+getResult()
laquointerfaceraquoRequest
ScreenHome
SOAPRequest
ScreenIdentify
ScreenAdvalvasList
ScreenPost
ScreenExecute
+addNew()+clearStore()+close()+enumerate()+getFirst()+getNumRecords()+getSize()
RmsDB User
+readObject()+writeObject()
laquointerfaceraquoSerializable
AdvalvasMessage
Course
Figuur 5-4 klassediagram van de applicatie
Voor wat betreft de lokale data opslag hebben we een RmsDB klasse gemaakt die de
RMS functionaliteiten uitbreidt Deze abstractie maakt het ook mogelijk snel de
applicatie te porten zodat er gebruik gemaakt kan worden van bijvoorbeeld een
relationele third-party oplossing (indien dit vereist zou zijn) of om bij het aanpassen
voor Personal Profile de RMS te vervangen door functionaliteiten op een
bestandsysteem (eventueel met XML)
Voor het werken met de objecten hebben we een AdvalvasMessage object een User
object en een Course object Deze implementeren allen de Serializable interface
die we kennen uit hoofdstuk 4
Voorts is er de SOAPRequest klasse die de Request implementeert zoals in de
connectietester applicatie uit hoofdstuk 4 Op deze manier garanderen we ook dat de
connectiefunctionaliteiten geabstraheerd worden waardoor het erg makkelijk en snel
83
wordt om een ander connectieprotocol te implementeren of zelfs de gebruiker de keuze
te laten 16
Vervolgens hebben we de AdvalvasMIDlet klasse die gebruik maakt van een aantal
Screens die de beeldschermen voorstellen Alle businesslogic zit vervat in de
AdvalvasMIDlet klasse zelf Deze specificeert de flow van de applicatie en hoe de
verschillende componenten aangeroepen en gebruikt moeten worden Deze flow werd
reeds schematisch weergegeven in Figuur 2-1
Aangezien we de verschillende elementen reeds belicht hebben in hoofdstuk 4 zullen
we hier niet verder ingaan op de programmatische aspecten van de implementatie Voor
verdere informatie verwijs ik de geiumlnteresseerde lezer door naar de commentaarstukjes
in de bijgevoegde code
Wij zullen hier de applicatie illustreren aan de hand van enkele screenshots verwerkt in
het flow-diagramma Figuur 5-5 geeft een idee van hoe de applicatie gevisualiseerd
werd17 Zoals reeds eerder vermeld kan men door middel van de Method Profiler de
Network Monitor en de Network Monitor extention een uitgebreide studie doen van de
performantie van elk deel van deze applicatie Hoewel dit een dieper inzicht in het
J2ME platform architectuur zal verschaffen en ruimte laat om best-practices op te
stellen voor het ontwerp van MIDP applicaties zou dit ons in het kader van dit
afstudeerwerk te ver leiden 18
16 Zo implementeren we bijvoorbeeld in de alternatieve opstelling een HTTP POST Request ipv
SOAPRequest 17 Op de bijgeleverde cd-rom staat ook een filmpje die de applicatie zoals gedemonstreerd in de
presentatie toont 18 Hoe verleidelijk ook
84
USER DATA STORED ON
DEVICENO
IDENTIFY
YES
IS LOGIN OK
CHECK SERVER
SAVE DATA ON DEVICE
()
YES
NO
READ FROM DEVICE
read
CHECK IF USER HAS COURSES
WITH POST PERMISSION
post
NO YES
Figuur 5-5 de flow met screenshots
Bij het opstarten van de applicatie wordt in de lokale datastore gezocht naar
gebruikersparameters Bij een eerste gebruik zijn die uiteraard leeg Daarom wordt
ernaar aan de gebruiker gevraagd Na het confirmeren wordt deze informatie
gevalideerd op de server Indien een positief antwoord ontvangen wordt vraagt de
applicatie alle informatie over de gebruiker op (een tweede verbinding) Deze
85
gebruikersparameters worden opgeslaan in de lokale datastore Indien een negatief
antwoord ontvangen werd meld de applicatie dit en wordt opnieuw het
authenticatiescherm getoond
De gebruiker wordt nu geleid naar het hoofdmenu Bij latere gebruikssessies zal het
programma na het inlezen van de lokale gebruikersparameters rechtstreeks dit scherm
tonen Hier kan gekozen worden om de advalvas te lezen een bericht te plaatsen data
te synchroniseren en zich opnieuw te identificeren
Advalvas lezen De lokale Advalvasstore wordt ingelezen en getoond aan de gebruiker
Deze kan de berichten lezen en desgewenst berichten verwijderen Ook kan hij vanuit
dit scherm de advalvas ophalen (synchroniseren)
Een bericht plaatsen Hierbij wordt een verbinding gemaakt met het netwerk en wordt
opgevraagd voor welke vakken de gebruiker rechten heeft om berichten te plaatsen
Indien er vakken teruggegeven worden kan er een bericht geplaatst worden Dit wordt
dan weer verzonden naar de server
Synchroniseren Hierbij wordt de nieuwe advalvasberichten ingeladen Dit gebeurt
door een tijdslabel mee te geven Dit tijdslabel duidt op de laatste synchronisatie
Hiermee kan de server enkel de laatste berichten (dus na het tijdslabel) teruggeven De
advalvasstore is zo geiumlmplementeerd dat het een beperking van aantal berichten toelaat
Indien het aantal overschreden wordt worden de oudste overschreven met nieuwere Dit
garandeert een efficieumlnt gebruik van de beschikbare opslagruimte en illustreert de
waarde van lokale databehandeling
Heridentificeren Hierbij worden de lokale datastores verwijderd (de advalvas en de
gebruikersparameters) Hierna kan een andere gebruiker zich aanmelden Omdat een
mobiel toestel typisch een persoonlijk toestel is werd er geen mogelijkheid
geiumlmplementeerd om verschillende gebruikers te laten switchen
55 De totaalapplicatie en het illustratiebelang
De implementatie van de totaalapplicatie demonstreert een aantal aspecten van CLDC
MIDP programmeren Het toont ook duidelijk aan dat J2ME zich uitstekend leent voor
een abstracter design19 We hebben ook aangetoond dat door middel van Web Services
19 Dit abstracte design heeft ook een prijs Wanneer men de profilers bekijkt is het duidelijk hoeveel
objecten en klassen er geladen moeten worden
86
een bestaande webapplicatie eenduidig kan uitgebreid worden op mobiele platformen
Een mogelijk scenario is bijvoorbeeld dat door middel van dezelfde Web Services een
applicatie gericht voor Pocket PC gebruikers meer functionaliteit implementeert dan een
applicatie in CLDC voor de GSM Web Services bieden ook een uitbreidbaar platform
voor interactie tussen verschillende technologieeumln
Het belang van deze demonstratie implementatie ligt vooral als ondersteuningswaarde
voor de aandachtspunten waar we in hoofdstuk 4 dieper op ingegaan zijn Hoewel dit
neerschrijven een tegengesteld idee zou kunnen poneren heeft deze demonstratie
applicatie het kader gevormd doorheen de studie
Een dergelijke eenvoudige toepassing illustreert toch reeds in zekere mate het belang
van een programmeerplatform op mobiele toestellen Naast de geboden oplossingen in
het altijd verbonden model zoals webapplicaties bereiken via een webbrowser is de
mogelijkheid om specifieke applicaties te ontwikkelen van groot belang
56 Alternatieve opstelling
Omdat uit hoofdstuk 4 gebleken is dat Web Services voor een niet te ontkennen
overhead zorgen is het belangrijk om een alternatief scenario te beschouwen Als we de
performantie-eigenschappen van tekstuele en binaire transmissie via HTTP GET en
POST in acht nemen lijkt het logisch toch voor deze connectiemethoden te kiezen We
mogen echter volgende nadelen niet uit het oog verliezen
- er moet een afspraak gemaakt worden tussen client en server voor de
implementatie kan beginnen
- Deze afspraken moeten gegarandeerd worden in de tijd (zodat na een update
oude installaties nog steeds werken)
- Wanneer men kiest voor serialisatie20 van objecten moet zowel de server als de
client dezelfde taal spreken Een zelfde gateway gebruiken voor een NET en
een J2ME implementatie is op deze manier uitgesloten
20 Aangezien zowel J2ME als CFNET geen serialisatie standaard aanbieden lijkt dit geen optimale piste
Vaak is het beter toch te kiezen voor eigen gedefinieumlerd eenvoudig tekstueel protocol
87
In de huidige markt wegen echter de beperkingen van de toestellen (nog steeds) zo
zwaar door dat we voor commercieumlle toepassingen genoodzaakt zijn een proxy of
gateway server te gaan in gebruik nemen 21 Dit wordt geiumlllustreerd in Figuur 5-6
Tomcat Server
INTERNETEmulator
Text POST
HTML Claroline
MySQL
PHP ENGINE
NuSOAPWSDL
Apache Web Server
Browser
AXIS
SOAP
GATEWAY PROXY server
Figuur 5-6 de gatewayproxy server opstelling
In deze opstelling stelt de gatewayproxy server zich in als de client uit de eerste
opstelling Wanneer het een zuiver gateway server is vertaalt de gateway-
serverapplicatie de request naar een SOAP request De gatewayserver ontvangt het
SOAP antwoord en vertaalt dit op terug naar de client (in het meer performanter
protocol) De server applicatie biedt ruimte om ook een proxy te gaan vormen Het kan
bijvoorbeeld data lokaal cachen om zo requests nog sneller te kunnen gaan
beantwoorden (in ons voorbeeld is de getServerDate methode hier een ideaal voorbeeld
21 We schrijven proxygateway server aangezien de server zowel de taak van een proxy server kan gaan
op zich nemen als de zuivere taak van gateway server
88
van de proxyServer kan immers op geregelde tijdstippen de tijd aan de Claroline server
bevragen en dit lokaal verder berekenen)
Tomcat Server
Low-end toestel
Text POST
HTML Claroline
MySQLPHP ENGINE
NuSOAPWSDL
Apache Web ServerBrowser
AXIS
SOAP
GATEWAY PROXY server
SOAP
High-end toestel
Figuur 5-7 gecombineerde opstelling
57 Uitbreidingen
Naast het implementeren van meer functionaliteit voor de advalvasapplicatie zijn er
aantal punten die zeker verder onderzocht kunnen worden
- hoe kunnen we ervoor zorgen dat de veiligheid van de gebruikers gegarandeerd
wordt Er wordt immers gevoelige informatie verzonden
- Een dergelijke applicatie leent zich het best om te draaien in de achtergrond De
applicatie moet dan detecteren of er een verbinding beschikbaar is Zij zou dan
op een heel minimale manier de server (desbetreffend gateway server) moeten
89
bevragen op nieuwe berichten Indien er nieuwe aanwezig zijn zou er een
venster kunnen pop-uppen dat dit aan de gebruiker meldt
-
90
Hoofdstuk 6
Besluit
61 Resultaten
Tijdens dit afstudeerwerk is het duidelijk geworden dat J2ME (JAVA) en het Compact
Framework (NET) heel sterk gelijkaardig zijn Toch zijn er een aantal belangrijke
verschillen op te merken
Platformafhankelijkheid Aangezien CF enkel op Windows toestellen draait is het
platformafhankelijk waar J2ME de platformonafhankelijkheid hoog in het vaandel
draagt Net daardoor treden er bij J2ME een aantal portabiliteitsproblemen op zoals
uit hoofdstuk 3 bleek Het Compact Framework is in staat hogere te stellen in
verband met de onderliggende hardware en biedt algemeen gezien een ruimere
functionaliteit Dit heeft een prijs Voor de low-end toestellen heeft de ontwikkelaar
enkel de mogelijkheid om de CLDC configuratie van J2ME te gebruiken
Filosofie De JAVA specificaties worden gestuurd door een groep experts en bedrijven
Hoewel dit voor een zekere vertraging zorgt garandeert dit wel het goedkeuren van
een groot deel van de industrie J2ME is ook ouder en dus volwassener Het
Personal Profile in CDC is zo bijvoorbeeld de opvolger van PersonalJava Het
Compact FrameworkNET is nog slechts in zijn eerste versie en er is nog veel
ruimte voor verbeteringen en uitbreidingen Toch biedt het reeds een ruime
functionaliteit De uitbreidingen worden gestuurd door 1 bedrijf Microsoft dat
hoewel het zich open instelt voor de mening van de ontwikkelaar toch zelf de
beslissingen neemt Het kan zo echter wel snel inspelen op deze snel evoluerende
markt Getuige hiervan is de snelle opmars van Windows mobile toestellen Hoewel
J2ME eerder gegroeid is vanuit de consumentenmarkt en Microsoft zich eerder
richtte op de professionele high-end gebruiker groeien beide technologieeumln toch
meer naar elkaar toe
Communicatie Het is erg belangrijk dat mobiele applicaties een verbinding kunnen
maken met een server (of zelfs andere mobiele toestellen) Hoewel beide
91
technologieeumln hier een ruime functionaliteit voor bieden levert het Compact
Framework een grotere mogelijkheid CF biedt immers standaard ondersteuning
voor Web Services iets waar de J2ME programmeur nog steeds zijn toevlucht moet
nemen tot externe bibliotheken die de suite verzwaren Echter uit hoofdstuk 4 en
hoofdstuk 5 bleek dat Web Services niet steeds de beste keuze zijn Het is daarom
opmerkelijk dat geen van beide (platformeigen) serialisatie of geoptimaliseerde RPC
functionaliteit aanbieden
Learning curve Bestaande Visual Basic en Visual C++ ontwikkelaars zullen gelukkig
zijn met de taalonafhankelijkheid van het Compact Framework De CF architectuur
laat ook ruimte voor verdere expansie in de talen (bijvoorbeeld Python) Aangezien
het Compact Framework een echte subset is van het desktop Framework zal een
Microsoft ontwikkelaar snel Smart Device Projects kunnen ontwikkelen De
mogelijkheid om de vertrouwde ontwikkelomgeving Visual Studio ook hier te
gebruiken bevorderd deze ervaring alleen maar J2ME is daarentegen volledig
gebaseerd op de JAVA taal Hoewel de JAVA programmeur zijn bestaande kennis
kan gebruiken voor het ontwikkelen van mobiele toepassingen zal er toch een
leerproces moeten zijn Dit is zeker waar voor CLDC programmeren zoals bleek uit
hoofdstuk 4 Nieuwe concepten voor de connecties en de lokale data opslag dienen
daar geeumlxploreerd te worden Ook voor wat betreft de gebruikersinterface zijn er
profiel eigen specificaties Hoewel CDC ook een subset van AWT aanbiedt is het
toch het Compact Framework die de beste learning curve voorlegt
Hoewel er een groot aantal kleine verschillen doorheen deze studie naar voren kwam is
het erg moeilijk de keuze tussen JAVA of NET voor mobiele applicaties te maken
Beiden leggen hun eigen accenten en proberen het voor hun bestaande achterban (de
desktop programmeurs in JAVA of NET) het zo makkelijk mogelijk te maken hun
skills te gebruiken voor mobiele applicaties Het NET Framework promoot het gebruik
van Web Services heel sterk Dit illustreert dat beide technologieeumln geloven in het
belang om verschillende technologieeumln te laten interageren Dit werd treffend
geiumlllustreerd in hoofdstuk 5 Toch werd aangetoond dat Web Services een aantal
nadelen met zich meebrengen en dat het gebruik van een gatewayserver soelaas kan
brengen
92
De keuze tussen JAVA of CFNET moet dus vooral gemaakt worden in functie met de
doelmarkt (en doeltoestellen) en bestaande kennis van de ontwikkelaar Beide
technologieeumln zijn elkaar waard en zullen voor lange tijd naast elkaar en met elkaar
bestaan
62 Verder onderzoek
In volgende domeinen is verder onderzoek echter noodzakelijk
- Performantietests gecombineerd met een featurevergelijking voor wat betreft de
lokale data opslag Hoe goed presteren de ADONET data providers Welke
mogelijkheden biedt SQLServer CE en hoe kunnen deze vergeleken worden
met JDBC oplossingen
- Vele theoretische punten uit hoofdstuk 3 hebben nood aan diepere uitspitten
Welke specifieke beveiligingsmogelijkheden zijn er Op welke manieren kan de
uiteindelijke applicatie bezorgd en geiumlnstalleerd worden op de clients Welke
mogelijkheden worden er geboden voor het updaten en managen van de
applicatie
- Het verbindingsonderzoek in hoofdstuk 4 heeft zich beperkt tot tekstuele
protocols XML-RPC en SOAP Er werd een groot verschil opgemerkt tussen de
tekstuele en de op XML-gebaseerde protocols Er is dus nood aan onderzoek hoe
custom protocols best geschreven kunnen worden op welke manieren
ondersteunen de platformen data marshalling22 Ook onderzoek hoe de
performantie van SOAP en XML verbeterd kan worden is aangewezen
- In het verbindingsonderzoek werden enkel de relatieve berichtengrootte
verschillen onderzocht Verder onderzoek naar welke invloed dit heeft op
verschillende bandbreedtes zou interessant cijfermateriaal opleveren In de
praktijk zal immers niet elke client dezelfde bandbreedte gebruiken Dit zal ook
de applicatieserver extra belasten
- Emulatoren geven leveren soms eigenaardige resultaten zoals hoofdstuk 4
getuigd Onderzoek hoe emulatoren zich gedragen ten opzichte van echte
toestellen en de onderlinge verschillen tussen toestellen is hier aangewezen
22 Marshalling is het proces waar data verzameld wordt en getransfereerd in een standaard formaat over
een netwerk om op die manier de data aan beide kanten beschikbaar te maken Objecten worden
marshalled en bij de ontvanger terug geconvergeerd naar een object
93
- De modelapplicatie uit hoofdstuk 5 kan sterk uitgebreid worden om meer
vergelijkingspunten aan te rijken Deze uitbreidingen werden geschetst in
hoofdstuk 5
94
APPENDIX A
Wsdl van de connectietester SOAP web service
ltxml version=10 encoding=UTF-8 gt
- ltwsdldefinitions
targetNamespace=http1270018080axisAdvalvasWsSoapjws
xmlns=httpschemasxmlsoaporgwsdl
xmlnsapachesoap=httpxmlapacheorgxml-soap
xmlnsimpl=http1270018080axisAdvalvasWsSoapjws
xmlnsintf=http1270018080axisAdvalvasWsSoapjws
xmlnssoapenc=httpschemasxmlsoaporgsoapencoding
xmlnswsdl=httpschemasxmlsoaporgwsdl
xmlnswsdlsoap=httpschemasxmlsoaporgwsdlsoap
xmlnsxsd=httpwwww3org2001XMLSchemagt
ltwsdlmessage name=getAdvalvasMessagesRequestgt
ltwsdlpart name=since type=xsdlong gt
ltwsdlpart name=user type=xsdstring gt
ltwsdlpart name=max type=xsdint gt
ltwsdlmessagegt
ltwsdlmessage name=getAdvalvasMessagesResponsegt
ltwsdlpart name=getAdvalvasMessagesReturn type=xsdstring gt
ltwsdlmessagegt
ltwsdlportType name=AdvalvasWsSoapgt
ltwsdloperation name=getAdvalvasMessages parameterOrder=since user maxgt
ltwsdlinput message=implgetAdvalvasMessagesRequest
name=getAdvalvasMessagesRequest gt
ltwsdloutput message=implgetAdvalvasMessagesResponse
name=getAdvalvasMessagesResponse gt
ltwsdloperationgt
ltwsdlportTypegt
ltwsdlbinding name=AdvalvasWsSoapSoapBinding type=implAdvalvasWsSoapgt
ltwsdlsoapbinding style=rpc
transport=httpschemasxmlsoaporgsoaphttp gt
ltwsdloperation name=getAdvalvasMessagesgt
ltwsdlsoapoperation soapAction= gt
ltwsdlinput name=getAdvalvasMessagesRequestgt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=httpDefaultNamespace use=encoded gt
ltwsdlinputgt
ltwsdloutput name=getAdvalvasMessagesResponsegt
ltwsdlsoapbody encodingStyle=httpschemasxmlsoaporgsoapencoding
namespace=http1270018080axisAdvalvasWsSoapjws use=encoded gt
95
ltwsdloutputgt
ltwsdloperationgt
ltwsdlbindinggt
ltwsdlservice name=AdvalvasWsSoapServicegt
ltwsdlport binding=implAdvalvasWsSoapSoapBinding name=AdvalvasWsSoapgt
ltwsdlsoapaddress location=http1270018080axisAdvalvasWsSoapjws
gt
ltwsdlportgt
ltwsdlservicegt
ltwsdldefinitionsgt
96
APPENDIX B
De Performance Timer klasse
using System
using SystemRuntimeInteropServices
namespace AdvalvasWsTest
Class to test times
public class PerformanceTimer
[DllImport(coredlldll)]
extern static int QueryPerformanceCounter(ref long
perfCounter)
[DllImport(coredlldll)]
extern static int QueryPerformanceFrequency(ref long
perfCounter)
static private Int64 m_frequency
private Int64 m_start
static PerformanceTimer()
if (QueryPerformanceFrequency(ref m_frequency) == 0)
throw new ApplicationException()
m_frequency = 1000 convert to ms
public void Start()
if (QueryPerformanceCounter(ref m_start) == 0)
97
throw new ApplicationException()
public Int64 Stop()
Int64 stop=0
if (QueryPerformanceCounter(ref stop) == 0)
throw new ApplicationException()
return (stop - m_start)m_frequency
98
REFERENTIES
31 Java Technology Overview - JC J2ME J2SE J2EE
Bruno Ferreira de Souza (Java Technologist Sun Microsystems Inc) (op cd-
rom)
32 J2ME Introduction Configurations and Profiles
Urs Steiner (University of Zuumlrich) (op cd-rom)
33 J2ME grows up
Tony Sundsted
httpwww-106ibmcomdeveloperworksjavalibraryj-j2me
34 Java 2 Micro Edition (J2ME) Specifications
Eric Giguere (Publisher John Wiley amp Sons) (op cd-rom)
35 JSR 30 J2METM Connected Limited Device Configuration
httpwwwjcporgjsrdetail30jsp
36 JSR 139 Connected Limited Device Configuration 11
httpwwwjcporgjsrdetail139jsp
37 JSR 118 Mobile Information Device Profile 20
httpwwwjcporgjsrdetail118jsp
38 J2ME in a nutshell
Kim Topley (Publisher OReilly - Edition March 2002)
39 JSR 46 J2METM Foundation Profile
httpwwwjcporgjsrdetail46jsp
310 JSR-000062 Personal Profile Specification
httpjcporgaboutJavacommunityprocessfinaljsr062indexhtml
311 J2ME Gets Personal
David Hemphill
httpfawcettecomjavapro2002_12magazinefeaturesdhemphilldefault_pfas
px
312 Java 2 Micro Edition
Donald E Stephens Convention Center
httpwwwnetrinocomPapersESC2002C330_Slidespdf
313 Essential Windows CE Application Programming
Robert Burdick (Wiley Computer Publishing John Wiley amp Sons Inc-1999)
99
314 JSR 75 PDA Optional Packages for the J2METM Platform
httpwwwjcporgenjsrdetailid=75
315 Microsoft WindowsCE Memory Models and Usage
Intel
316 Building Solutions with the Ms NET CF
Dan Fox amp Jon Box Addison-Wesley 2003
317 Microsoft CFNET FAQ
httpmsdnmicrosoftcommobilityprodtechinfodevtoolsnetcffaqdefaultaspx
(130)
318 Andy Wigley amp Stephen Wheelwright NET Compact Framework Core
reference (Microsoft Press)
319 Let the mobile games begin part 1 amp 2
Michael Juntao Yuan
httpwwwjavaworldcomjavaworldjw-02-2003jw-0221-wirelesshtml
320 Managed mobile clients with OSGi Managed smart clients
Michael Juntao Yuan
httpwww-106ibmcomdeveloperworkslibrarywi-osgi
321 Over The Air User Initiated Provisioning Recommended Practice for the Mobile
Information Device Profile
Sun Microsystems
httpjavasuncomproductsmidpOTAProvisioning-10pdf
322 J2EE Client Provisioning
httpjavasuncomj2eeprovisioningindexjsp
323 httpwwwgo-monocom
324 httpjavasuncomproductsj2mewtoolkit
325 httpwwwssuncomsoftwareproductsjsenterpriseindexhtml
326 httpeclipsemesourceforgenet
327 httpwwwcodewarriorcomMWDevelopWirelessWireless_Studio
328 httpwww-306ibmcomsoftwarewirelesswsdd
329 httpwwweclipseorg
330 httpwwwmicrojavacomdevelopertools
331 httpwwwjcporgenparticipationmembers
332 httpjavasuncomj2se13docsguidejni
100
333 httpjavasuncomdevelopercommunitychatJavaLive2001jl0213html
334 Java vs Net Security
Denis Piliptchouk
httpwwwonjavacompubaonjava20031126javavsdotnethtmlpage=lastamp
x-showcontent=text
41 wwwreqwirelesscom
42 wwwpointbasecom
43 JSR 169 JDBC Optional Package for CDCFoundation
httpwwwjcporgenjsrdetailid=169
44 JSR 172 J2METM Web Services Specification
httpwwwjcporgenjsrdetailid=172
46 The NET Compact Framework
Dan Fox
httpwwwinformitcomarticlesarticleaspp=31693
47 httpwwwpreceivecomxmlrpc
48 httpksoapenhydraorg
49 httpkxmlenhydraorg
410 httpwebwanadoobecyberelfnanoxml
411 Personal Basis Profile vs Personal Profile Whats the Difference
Eric Giguere
httpdeveloperssuncomtechtopicsmobilitypersonalarticlespbp_pp
412 httpwwwdotnet247com247referencemsgs20104870aspx
413 httpjakartaapacheorgtomcat
414 httpxmlapacheorgaxis
415 httpxml-rpcnet
51 httpwwwclarolinenet OpenSource e-learning
52 httpcvssourceforgenetviewcvspynusoaplib
