Designdokument. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Transkript

1 Designdokument Magne Rodem og Jan-Erik Strøm 18. juni 2006

2 Innhold 1 Introduksjon 3 2 Overordnet arkitektur 4 3 Klient/tjener-løsningen Felles klasser Tjeneren Web Service Kontaktdatabase Klienten Aksess mot Web Service med Wingfoot SOAP Parsing av XML Sikkerhet Autentisering Kryptering Brukergrensesnitt Rammeverk for brukergrensesnitt Beskrivelse av brukergrensesnitt for applikasjonen Referanser 26 6 Revisjonshistorie 27 2

3 1 Introduksjon Dette dokumentet beskriver designprosessen for det systemet vi utviklet i hovedprosjektet. Det tar for seg hvordan systemet er bygd opp fra grunnen av, og vil ligge som en basis for eventuelt videre arbeid. Gjennom dette dokumentet vil de veivalg vi gjorde underveis belyses og begrunnes. Løsninger vil skisseres, og ulike alternativer diskuteres. Dette synes vi er viktig for å få fram og vise hvordan de ulike veivalgene hadde innvirkning på det ferdige produktet, og hvordan de var med på å drive utviklingen framover. Designdokumentet er i hovedsak myntet på utviklere eller andre med tekniske forutsetninger som ønsker å sette seg dypere inn i hvordan systemet fungerer, og få forståelse for de valg som er gjort. Vi mener dette er et et svært viktig dokument i vårt hovedprosjekt, da det viser hvordan vi har angrepet og løst de problemstillingene prosjektet innehar. Det vil også være til stor hjelp for utenforstående til å sette seg inn i systemet. Dokumentet er ment å være et oppslagsverk, der kapitlene er uavhengige av hverandre. Det skal ikke være nødvendig å lese det kronologisk hvis man bare ønsker å se på og forstå en del av systemet, men for å skaffe seg mest mulig oversikt anbefales det å lese gjennom dokumentet fra start til slutt. Det anbefales å lese kravspesifikasjonen før man leser dette dokumentet. Seksjon 2 presenterer en overordnet oversikt over systemet. I denne seksjonen er det meningen at leserne skal danne seg seg et helhetsbilde av systemet som gjør det lettere for dem å forstå det som kommer videre i dokumentet. Seksjon 3 tar for seg klient/tjener-løsningen med Web Service som et bindeledd mellom kontaktdatabasen og klient-applikasjonen. Vi går også inn på hvordan selve kommunikasjonen mellom tjener og klient foregår, og sikkerhetsaspekter rundt dette. Seksjon 4 tar for seg brukergrensesnittet til klient-applikasjonen. Her går vi inn i detalj om våre valg angående egetkomponert GUI-bibliotek, og hvordan dette fungerer. 3

4 2 Overordnet arkitektur Figur 1: Overordnet arkitektur. Figur 1 viser systemets overordnete arkitektur. Dette er en typisk trelagsarkitektur hvor databasen inneholder dataene, Web Service en inneholder forretningslogikken som behandler dataene, og J2MEapplikasjonen tilbyr brukerne et brukergrensesnitt mot denne logikken, som igjen gir dem adgang til dataene. På tjenersiden kjører kontaktdatabasen som inneholder kontaktene det skal være mulig å aksessere fra klient-applikasjonen. I vår løsning har vi laget en standard databaseimplementasjon for vår fiktive databasestruktur, men det er mulig å lage nye implementasjoner og dermed skifte denne ut fullstendig. En Web Service er koblet opp mot denne databasen og tilbyr klienter metoder for å aksessere databasen. Web Service en kjører på en J2EE applikasjonstjener. Klienten er en J2ME-applikasjon som benytter seg av Wingfoot SOAP[1], en lettvekts SOAP-klient med innebygd XML-parser som egner seg på mobile plattformer, for å kommunisere med Web Service en. J2ME-applikasjonen krever at telefonen støtter MIDP 2.0, noe som de aller fleste nyere telefoner gjør. Vi valgte å gå for MIDP 2.0 grunnet utvidet funksjonalitet for grafikkhåndtering og datakommunikasjon, to av hovedelementene i den applikasjonen vi skulle utvikle. Tjener og klient kommuniserer med hverandre via SOAP. Dette er en standard som blir brukt i forbindelse med Web Services og overfører XML over et nettverk, som regel ved bruk av HTTP. SOAP-meldinger, såkalte SOAP Envelopes sendes mellom tjener og klient. Dette er XML-meldinger med en gitt syntaks. Når SOAP brukes i forbindelse med Web Services, som det normalt gjør, vil oppbyggingen av SOAP-meldingene avhenge av det innholdet Web Service en har å tilby. 4

5 3 Klient/tjener-løsningen I dette kapitlet vil vi ta for oss klient/tjener-løsningen som systemet består av. Vi vil beskrive hva som skjer på begge sidene med hensyn på funksjonalitet og hvilke teknologier som tas i bruk, samt hvordan kommunikasjon mellom klienten og tjeneren foregår. Det vil også bli drøftet hvordan vi kom fram til de valgene vi gjorde, og hvilke alternativ vi hadde. 3.1 Felles klasser Data hentes ut på forskjellige måter på henholdsvis tjener og klient. På tjeneren må data hentes ut fra en database, mens på klienten vil data forekomme i XML-format og må parses. I den sammenheng fant vi det nyttig å opprette et sett med klasser til det formål å mellomlagre dataene. På den måten strømlinjeformes koden for å prosessere dataene etter at de er lagt inn (tjeneren) eller hentet ut (klienten). Figur 2 viser et klassediagram over de klassene som brukes til dette formålet. Figur 2: Felles klasser. Info-klassen holder styr på den informasjonen som er lagret om en kontakt. Dette kan være ulike telefonnumre, adresser, web-sider og lignende. Objektvariabelen type peker til en av konstantene i klassen (oppgitt med store bokstaver) og angir hvilken type informasjon et objekt av klassen er. labelobjektvariabelen er en tekst som fungerer som ledetekst for selve informasjonen. For å ta et eksempel; hvis type er TEL HOME, kan label være Telefon hjemme. Dette brukes hovedsaklig på klienten for å vise brukeren tekstlig hva slags type informasjon det er snakk om. Den siste objektvariabelen, text, er selve dataene som er knyttet mot typen. Et Info-objekt kan opprettes gjennom konstruktøren eller bygges opp ved hjelp av set-metodene. 5

6 Konstruktøren ser slik ut: public Info(int type, String label, String text) Informasjon om en kontakts epost-adresse kan da legges inn som et Info-objekt på følgende måte: Info info = new Info(Info. , "Epost-adresse", "ola.nordmann@norge.no"); Dersom alle opplysningene ikke er tilgjengelig i det klassen instansieres, kan man også bruke setmetodene: Info info = new Info(); info.settype(info. ); info.setlabel("epost-adresse"); info.settext("ola.nordmann@norge.no"); Contact-klassen inneholder informasjon om en enkel kontakt. Denne inneholder fornavn, etternavn og hvilken gruppe kontakten tilhører, i tillegg til en tabell med Info-objekter som representerer selve informasjonen om kontakten. Metoden getfullname returnerer kontaktens fulle navn (fornavn + etternavn), mens metoden getinfotext returnerer teksten til et Info-objekt som har typen som er angitt i metodens parameter. På den måten kan man hente ut det man måtte ønske om kontakten, uten å måtte iterere gjennom hele tabellen først. Eksempelvis, hvis man ønsker å finne mobilnummeret til kontakten, kan følgende kode brukes: String mobilnummer = kontakt.getinfotext(info.tel_mobile); Hvis intet mobilnummer finnes i kontakt-objektet, returneres null. Den siste metoden i Contact, tovcard, lager en vcard-streng basert på informasjon som er lagret i objektet. vcard er en standard for å beskrive kontaktinformasjon elektronisk og er støttet av de fleste telefoner. vcard benyttes også i andre sammenhenger, som for eksempel epost-klienter. Når en vcard-streng sendes som en tekstmelding til en mobiltelefon, vil mottakertelefonen oppdage at det er et vcard, og følgelig spørre brukeren om han vil lagre kontaktinformasjonen i telefonenes lokale adressebok. Response-klassen representerer et svar fra tjeneren. Ved for eksempel søking vil tjeneren opprette et objekt av klassen og legge til alle kontakter som tilfredsstilte søket. Objektvariabelen total indikerer hvor mange totale treff søket gav, altså ikke hvor mange kontaktobjekter som ligger i objektet. Det er opp til klienten å bestemme hvor mange kontaktobjekter som skal ligge i hvert responsobjekt. Dette på grunn av at overføringshastigheten til og fra mobile enheter er begrenset, og ved søk som gir mange treff, vil det ta lang tid å motta disse fra tjeneren. Ved mottak av data fra tjeneren, vil klienten parse XML en som kommer, hente ut kontaktinformasjon og legge det i et responsobjekt. Dette brukes videre i applikasjonen for å fylle UI-lister og vise fram informasjonen. 6

7 3.2 Tjeneren Web Service Tjeneren i systemet vårt er en Web Service. En Web Service tilbyr interoperabilitet mellom to systemer, slik at de kan utveksle data[2]. Et sett med operasjoner defineres på Web Service en og disse gjøres tilgjengelig for klienter som ønsker å bruke dem. Grensesnittet til Web Service en er gitt av dens WS- DL (Web Services Description Language). Dette er en fil som setter regler for hvordan kommunikasjonen mellom Web Service en og klienter skal foregå med hensyn på oppsett av SOAP-meldinger. All kommunikasjon mellom Web Service en og klienten skjer gjennom disse SOAP-meldingene. Innholdet er XML, og syntaksen til denne er altså beskrevet i WSDL-filen. Fordelen med å bruke en Web Service er at den er basert på åpne standarder. Det betyr at man like gjerne kan utveksle data mellom en Web Service som kjører på.net og en klient som bruker Java, Python eller andre plattformer, og vice versa. Protokollene og dataformatene er tekstbasert, og gjør det lettere for utviklere å forstå. I tillegg brukes normalt HTTP for å overføre dataene. Dette har den fordelen at dataoverføringen kan gå uforstyrret gjennom brannmurer og lignende sikkerhetsmekanismer. Derimot, en av ulempene ved Web Service er at ytelsen ikke kan konkurrere med lignende systemer som RMI, CORBA eller DCOM. Dette ligger i at XML har veldig tykk syntaks, noe som fører til at datamengden som overføres blir større. Vi valgte å gjøre Web Service en tilgjengelig ved hjelp av J2EE (Java 2 Enterprise Edition). De største fordelene med å bruke J2EE er at mye av ansvaret flyttes over til den aktuelle applikasjonstjeneren man benytter. Applikasjonstjenerne har blant annet innebygde funksjoner for kryptering, databasepooling og skalering. Alt dette er i stor grad relevant i vårt system. J2EE er i tillegg plattformuavhengig, og legger vekt på enkel gjenbruk av komponenter. For å kunne ta i bruk Web Service som en kobling mellom J2ME-klienten og kontaktdatabasen, satte vi opp følgende operasjon/metode: public no.mje.common.response getcontacts(string searchquery, int startindex, int stopindex, String phonenumber, String password) throws RemoteException Denne metoden vil, når den blir kalt, returnere de kontaktene fra kontaktdatabasen som matcher den gitte søkestrengen angitt i searchquery. Parametrene startindex og stopindex angir et intervall for resultatene som skal tas med, mens phonenumber og password brukes for å autentisere klienten og sørger for at det hentes ut kontakter fra riktig gruppe. Hvis searchquery er null eller en tom streng, vil alle kontaktene fra kontaktdatabasen matches. Dette kan brukes av klienten for å liste ut alle kontakter. 7

8 Under vises et utdrag fra WSDL-filen til Web Service en. Utdraget viser XML-skjema for metoden getcontacts.... <complextype name="getcontacts"> <sequence> <element name="string_1" type="string" nillable="true"/> <element name="int_2" type="int"/> <element name="int_3" type="int"/> <element name="string_4" type="string" nillable="true"/> <element name="string_5" type="string" nillable="true"/> <sequence> </complextype>... Her ser vi at klienter som ønsker å kalle metoden må komponere SOAP-meldingen som forholder seg til metodens XML-skjema. Utdraget under viser hvordan dette kan gjøres.... String searchquery =...; int start =...; int stop =...; String phonenumber =...; String password =...; String request = "<m:getcontacts xmlns:m=\"urn:contactwebservice/types\"> " + "<String_1>" + searchquery + "</String_1> " + "<int_2>" + start + "</int_2>" + "<int_3>" + stop + "</int_3>" + "<String_4>" + phonenumber + "</String_4>" + "<String_5>" + password + "</String_5>" + "</m:getcontacts>";... Vi har her komponert kroppen til SOAP-meldingen som skal sendes til Web Servicen. Vi etterspør metoden getcontacts og setter på de parametrene som metoden krever. Videre vil denne strengen sendes til Wingfoot-API et, som tar seg av selve overføringen. Deretter vil vi motta en responsmelding. Formen på denne responsmeldingen er også spesifisert i WSDL-filen som XML-skjema:... <complextype name="getcontactsresponse"> <sequence> <element name="result" type="response" nillable="true"/> </sequence> </complextype> <complextype name="response"> <sequence> <element name="contact" type="contact" nillable="true" minoccurs="0" maxoccurs="unbounded"/> <element name="total" type="int"/> </sequence> 8

9 </complextype> <complextype name="contact"> <sequence> <element name="firstname" type="string" nillable="true"/> <element name="group" type="string" nillable="true"/> <element name="info" type="info" nillable="true" minoccurs="0" maxoccurs="unbounded"/> <element name="lastname" type="string" nillable="true"/> </sequence> </complextype> <complextype name="info"> <sequence> <element name="label" type="string" nillable="true"/> <element name="text" type="string" nillable="true"/> <element name="type" type="int"/> </sequence> </complextype>... Rotelementet til kroppen i responsmeldingen skal altså hete getcontactsresponse, det skal ha et barneelement result, som igjen har barneelementene firstname, group, info og lastname. Elementet info har igjen barnelementene label, text og type. Strukturen her gjenspeiler Responseobjektet som returneres av getcontacts. Klienten må selv sørge for å parse denne responsmeldingen når den mottas. Hvordan dette gjøres beskrives i kapitlet om klienten. 9

10 3.2.2 Kontaktdatabase Da vi i dette prosjektet ikke hadde anledning til å teste ut de forskjellige databasene som den nettsentriske adresseboken kjører på, ble vi nødt til å definere vår egen databasestruktur med innhold som best mulig simulerer de data som en slik adressebok inneholder. Design med interface gjorde oss imidlertid i stand til å separere selve databaseimplementasjon vekk fra Web Service-metoden, slik at Web Service en ble uavhengig av en bestemet databaseimplementasjon. Dette betyr at det blir en lett oppgave å skifte ut databaseimplementasjon ved et senere tidspunkt. Alt som må gjøres er å implementere interfacet DatabaseConnection og endre instansieringen i Web Service-klassen til å instansiere den nye implementasjonen. Figur 3 viser de ulike klassene som er i spill og sammenhengen mellom dem knyttet opp mot Web Service en. Figur 3: Klassediagram for Web Service-løsningen. ContactWebServiceBean er Bean-klassen. Vi har implementert denne som en tilstandsløs SessionBean, noe som betyr at applikasjonstjeneren styrer opprettelse og fjerning av Bean-instansene. I tillegg til obligatoriske metoder for å styre initialisering og avslutning av Bean en, inneholder denne klassen Web Service-metoder som er tilgjengelig for klienten. I ejbcreate-metoden blir databasetilkoblingen initialisert. Dette gjøres ved å velge implementasjon av interfacet DatabaseConnection. I vårt tilfelle bruker vi DefaultDatabaseConnection, som er en standardimplementasjon for vår fiktive kontaktdatabase. I J2EE er det vanlig å benytte DataSource-objekter som grensesnitt mot databaser. Et slikt objekt er koblet mot en bestemt database og vet blant annet hvilken databasedriver som skal brukes. I ejbcreate-metoden oppretter vi en databasetilkobling på følgende måte: 10

11 ... private DatabaseConnection databaseconnection;... public void ejbcreate() {... InitialContext context = new InitialContext(); DataSource datasource = (DataSource)context.lookup("java:comp/env/jdbc/ContactDatabase"); Connection connection = datasource.getconnection(); databaseconnection = new DefaultDatabaseConnection(connection);... }... Vi gjør altså et JNDI-oppslag mot java:comp/env/jdbc/contactdatabase for å få tilgang til Data- Source-objektet for vår database. JNDI (Java Naming and Directory Interface) er et standardisert grensesnitt som kan brukes mot ulike typer navne/katalogtjenester. Web Service-modulen har en såkalt deployment descriptor hvor vi har spesifisert at JNDI-navnet java:comp/env/jdbc/contactdatabase skal være en DataSource og at det skal mappes til det globale navnet jdbc/contactdatabase. Det blir dermed opp til applikasjonstjeneren å sørge for at riktig DataSource-objekt blir returnert ved oppslag mot jdbc/contactdatabase. Ved installasjon av applikasjonen, må man altså sørge for å angi riktig databasenavn, brukernavn, passord og maskinnavn for databasetjeneren slik at applikasjonstjeneren vet hvordan den skal behandle oppslag mot nevnte JNDI-navn. Hvordan dette gjøres varierer for de ulike applikasjonstjenerne. I vår installasjonsveiledning har vi beskrevet hvordan man gjør dette i Sun Java System Application Server. Ut fra DataSource-objektet kan vi hente et Connection-objekt som vi sender med i konstruktøren til vår DatabaseConnection-implementasjon. Dette DatabaseConnection-objektet blir værende i Bean en helt til den fjernes automatisk av applikasjonstjeneren. Da kjøres metoden ejbremove, og databasetilkoblingen lukkes. Når Web Service-metoden getcontacts blir kalt av klienten, kaller den opp tilsvarende metode på interfacet DatabaseConnection og overlater dermed jobben med å hente ut kontakter til implementasjonen. Merk at implementasjoner også må forholde seg til klassene Response og Contact. Et Response-objekt inneholder en tabell med Contact-objekt som tilsvarer de kontaktene spørringen var ute etter. I tillegg inneholder objektet antall kontakter som var i samsvar med den gitte spørringen. På grunn av lav overføringshastighet vil det være fornuftig av klienten å ikke forespørre altfor mange kontakter på en gang, og av den grunn kan det være nyttig å vite hvor mange treff totalt søket ga, slik at klienten kan videreformidle denne informasjonen til brukeren. 11

12 3.3 Klienten Aksess mot Web Service med Wingfoot SOAP Wingfoot er en lettvekts klient-implementasjon av SOAP 1.1, og er spesielt lagt til rette for MIDP/CLDCplattformen [3]. Dette betyr at dets API tillater oss å kontakte Web Services som kjører på blant annet Sun Application Server eller.net. Wingfoot har derimot noen begrensninger i forhold til standardimplementasjoner. Måten SOAP fungerer på er å sende XML over HTTP. En SOAP-melding inneholder XML og kan ha to forskjellige stiler; RPC-stil eller Document-stil. RPC (Remote Procedure Call) brukes når det skal kalles en fjernmetode, og kroppen til XML en som sendes er strukturert på en slik måte at den spesifiserer metoden som skal kalles, og hvilke parametre å gi den. Ved Document kan man strukturere XML en akkurat som man selv måtte ønske. Det blir opp til mottakeren å parse og gjøre mening i innholdet. Wingfoot støtter både RPC og Document. I tillegg til stil, kan en SOAP-melding kodes på to forskjellige måter; Encoded og Literal. Reglene for koding og oversettelse er spesifisert i encodingstyle -attributtet, og indikerer hvordan applikasjonsdatatyper skal oversettes til XML. Wingfoot støtter begge kodingene, men ikke alle kombinasjoner av stiler og kodinger. Tabellen under viser de ulike kombinasjoner og hvilke Wingfoot støtter. Kombinasjon RPC Encoded RPC Literal Document Encoded Document Literal Støttet av Wingfoot Ja Nei Nei Ja Dette ga oss to valg; RPC Encoded og Document Literal. For våre formål passet Document Literal mer enn bra nok, og det ble også valget vårt. Med Document Literal må vi dog parse den rå XML en som kommer fra Web Service en og komponere et XML-svar manuelt tilbake, men på den måten får vi også full oversikt og kontroll over datautvekslingsprosessen som igjen gjør oss i stand til å optimalisere ytelsen på dataoverføringen. I motsetning til J2ME Web Services (JSR 172) er Wingfoot ingen standard i seg selv, og krever ikke at telefonene støtter det. Wingfoot benytter seg kun av det allerede eksisterende MIDP-API et for å kommunisere med Web-Service er. Dette skjer som kjent gjennom HTTP, og dette støttes i MIDP 2.0. Gangen i å kalle en Web Service-metode med Wingfoot er todelt. Først må det opprettes et Envelope-objekt. Dette objektet representerer selve SOAP-meldingen som skal sendes. Siden vi bruker Document Literal, må vi konstruere vår egen XML og deretter kalle setbody(string xml) på Envelopeobjektet. Syntaksen til denne XML en er gitt av Web Service ens WSDL-fil. Videre må vi opprette Call-objekt. Dette objektet vil utføre selve kallet av Web Service-metoden. Vi må også spesifiere transportmetoden for kallet. Vi bruker her HTTPTransport siden vi ønsker at SOAP-meldingen skal sendes over HTTP. Til slutt kalles metoden invoke på Call med ønsket transport-objekt. Denne metoden vil blokkere inntil kallet er gjennomført, og returnerer et nytt Envelope-objekt som inneholder responsen 12

13 fra Web Service en. I neste delkapittel gjennomgås parsing av denne responsen. Å utføre et kall mot en Web Service fra en mobil enhet kan ta litt tid, da overføringshastigheten som regel ikke er all verden. I og med at invoke-metoden blokkerer, kan brukeren oppleve flere sekunder med dødtid mens kallet blir utført. For å imøtekomme dette, kjører vi all nettverkskommunikasjon i en egen tråd. Da kan denne tråden kjøres parallelt med GUI-tråden og brukeren vil ikke oppleve hakking eller lengre venting på grunn av treg overføringshastighet. Det er også viktig at brukeren får beskjed, i form av en melding nederst på skjermen, om at noe skjer i bakgrunnen. I tillegg behandles alle unntak. Nettverksaksess på mobile enheter er ikke alltid like pålitelig, så man må være forberedt på det verste. Figur 4 viser de klassene som er involvert i forbindelse med kommunikasjon mot Web Service en. Figur 4: Klasser involvert i kommunikasjon med Web Service en. WebServiceClient er en Singleton. Metoden retrievecontacts utfører et kall til Web Service en hvor den etterpør kontakter basert på en søkestreng. For at man skal kunne autentisere seg på Web Service en, må telefonnummer til telefonen som applikasjonen brukes fra, samt et passord, settes ved hjelp av metoden setauthenticationcredentials. I tillegg må url til Web Service en spesifiseres ved hjelp av setserverurl. Disse verdiene leses ut fra JAD-filen som ligger ved applikasjonen. Mer om dette i kapitlet om sikkerhet. ResponseParser har én statisk metode, parse, som sørger for å parse responsen fra Web Service et etter et kall dit. Denne metoden returnerer et Response-objekt (felles klasse). En lytter i WebServiceClient vil sørge for å videreformidle dette objektet til brukergrensesnittklassene slik at kontaktinformasjonen kan bli lagt tilgjengelig for brukeren. 13

14 3.3.2 Parsing av XML Mobile enheter har begrenset med ressurser, både med tanke på minnekapasitet og overføringshastighet ved datakommunikasjon over nett. Dette er begrensninger vi måtte ta hensyn til da vi skulle foreta et valg angående hvilken XML-parser vi skulle bruke til å parse XML en som ble mottatt over SOAP. Det finnes i hovedsak tre ulike typer XML-parsere[4]: Pull Ved bruk av en pull-parser kalles en metode på parseren gjentatte ganger for å traversere gjennom et dokument. Push En push-parser går gjennom hele dokumentet på egen hånd og kaller tilbake på metoder i koden når viktige hendelser inntreffer. SAX-parsere går under denne kategorien. Model En model-parser bygger opp en intern representasjon (i minnet) av dokumentet. Etter at parsingen er fullført, kan dokumentet analyseres, og data kan hentes ut. Som nevnt har mobile enheter begrenset minnekapasitet, og model-parsere er derfor ikke spesielt godt egnet for vår applikasjon. Push-parsere har ikke denne ulempen, men blir fort litt upraktiske å bruke, i og med at applikasjonen hele tiden må holde orden på hvor i dokumentet den befinner seg. Pull-parsere er derimot enkle å forstå og bruke, og passer godt for bruk på mobile enheter, da de er sparsomme med bruk av minne. Vi kom etter hvert fram til at vi hadde to valg; kxml og SAX-parseren som følger med i J2ME Web Services (JSR 172). J2ME Web Services er en såkalt optional package og fungerer kun på mobiltelefoner som støtter spesifikasjonen JSR 172, mens kxml er et eget parsebibliotek som følger med sammen med Wingfoot SOAP. Vi kom fram til at kxml passer best for vårt bruk, da kxml følger med Wingfoot SOAP og støtter all den funksjonaliteten vi trenger. kxml er i tillegg en pull-parser og egner seg derfor godt for mobile enheter. Følgende eksempel viser strukturen på XML-strengen som J2ME-applikasjonen mottar fra tjeneren: 14

15 <result> <contact> <firstname>ola</firstname> <lastname>nordmann</lastname> <group>arbeidsplassen AS</group> <info> <label>telefon hjemme</label> <text> </text> <type>0</type> </info> <info> <label>epost</label> <type>4</type> </info> <info> <label>gateadresse</label> <text>karl Johans gt. 1</text> <type>6</type> </info> <info> <label>postadresse</label> <text>0342 Oslo</text> <type>7</type> </info> <info> <label>fødselsdato</label> <text> </text> <type>8</type> </info> </contact> [...] <total>23</total> </result> Strengen bygges opp ut fra innholdet i Response-objektet som er beskrevet i avsnittet om felles klasser. Strengen inneholder da en liste med et gitt antall kontakter (maksimalt antall angis av klienten), samt til slutt et element (total) som viser hvor mange treff som totalt ble returnert av det aktuelle søket. Alle kontakter har elementene fornavn, etternavn og gruppe, samt et gitt antall info-elementer. Alle info-elementer har en beskrivelse, en tekst og et nummer som identifiserer hvilken type info det er snakk om. Metoden som utfører parsingen av denne strengen er enkel, men ganske lang, så vi vil ikke gjengi denne her. Vi viser heller en litt mindre metode som viser hvordan man kan hente ut navnet til kontaktene i en slik XML-streng. Eksempelet på neste side viser bruk av klassene XmlParser og ParseEvent i kxml-api et. Den opprinnelige metoden opererer på samme måte, men går dypere i XML-treet og returnerer et Response-objekt i stedet for en strengtabell. 15

16 public static String[] getcontactnames(string xml) throws IOException { byte[] stringbytes = xml.getbytes(); ByteArrayInputStream bais = new ByteArrayInputStream(stringBytes); XmlParser parser = new XmlParser(new InputStreamReader(bais)); parser.setprocessnamespaces(false); ParseEvent parseevent = null; Vector contacts = new Vector(); while ((parseevent = parser.read())!= null) { if (parseevent.gettype() == Xml.START_TAG) { if (parseevent.getname().equals("contact")) { String firstname = null, lastname = null; while (!(parseevent.gettype() == Xml.END_TAG && parseevent.getname().equals("contact"))) { parseevent = parser.read(); } if (parseevent.gettype() == Xml.START_TAG && parseevent.getname().equals("firstname")) { parseevent = parser.read(); firstname = parseevent.gettext(); } else if (parseevent.gettype() == Xml.START_TAG && parseevent.getname().equals("lastname")) { parseevent = parser.read(); lastname = parseevent.gettext(); } } contacts.addelement(lastname + ", " + firstname); } } else if (parseevent.gettype() == Xml.END_DOCUMENT) break; String[] conts = new String[contacts.size()]; contacts.copyinto(conts); } return conts; 16

17 3.4 Sikkerhet Autentisering Siden brukerne av systemet tilhører ulike grupper (ProffNett-avtaler), må brukerne identifiseres. Ved søk og utlisting av kontakter skal en bruker kun få returnert kontakter som befinner seg i samme gruppe som den aktuelle brukeren. Samtidig vil man hindre brukere i å få tilgang til andre grupper enn den de befinner seg i. Det er altså nødvendig å autentisere brukere før de gis tilgang til kontaktlisten. Ved implementasjon av autentiseringsdelen i dette systemet, var det flere elementer vi måtte ta hensyn til. Først og fremst er det ikke ønskelig at brukerene må taste inn brukernavn og passord. Dette vil redusere tjenestens brukervennlighet. Likevel måtte vi sørge for at ingen kan utgi seg for å være noen andre enn den de er. Man kunne kanskje tenke seg at man via J2ME kunne hente ut mobiltelefonens telefonnummer, og benytte dette ved autentisering. Dette er imidlertid ikke tilfelle. Et annet nummer benyttes ved identifisering av brukere på GSM-nettet. Dette er det 15 siffer lange IMSI-nummeret (International Mobile Subscriber Identity). Dette er lagret på SIM-kortet, men er heller ikke lesbart fra en J2MEapplikasjon. Her måtte vi altså velge en annen strategi. For å unngå å spørre brukerne om autentiseringsinformasjon, var det klart at dette måtte være lagret på telefonen i en eller annen form. Vi har løst dette ved å legge brukerens telefonnummer og passord i applikasjonens JAD-fil. Dette innebærer at denne filen må være ferdig generert før nedlasting. Måten dette vil foregå på er følgende: 1. Brukeren sender en tekstmelding til et gitt telefonnummer hos operatør med et gitt kodeord for å laste ned applikasjonen. For eksempel kan en melding sendes til 1999 med kodeordet PROFFNETT. 2. En tjener hos operatør mottar meldingen, genererer et nytt passord, og registrerer dette i databasen sammen med telefonnummeret som meldingen ble sendt fra. Et krav her er at brukeren allerede må være tilordnet en ProffNett-avtale, og registrert i databasen med navn og ytterligere personopplysninger. 3. Tjeneren skriver så brukerens telefonnummer og passord til applikasjonens JAD-fil. 4. Tjeneren sender en melding tilbake til brukeren med URL for nedlasting av applikasjonen. 5. Brukeren laster ned applikasjonen og installerer den på sin telefon. Applikasjonen er nå klar til bruk, og brukeren slipper å taste inn sitt telefonnummer og passord. 17

18 Figur 5: Figur som viser informasjonsflyten ved nedlasting av applikasjonen. Brukeren må altså være registrert som ProffNett-kunde for å kunne laste ned applikasjonen, siden tjeneren sjekker avsenderens telefonnummer opp mot databasen over registrerte ProffNett-brukere. I det applikasjonen er lastet ned og installert, er den klar til bruk, og brukeren behøver ikke å vite sitt eget passord. Den gjevne bruker vil heller ikke være klar over at det faktisk finnes et passord. Det er mulig å finne brukerens passord (lese JAD-filen), men dette krever litt innsats. JAD-filen må da overføres til en PC. Dersom mobiltelefonens eier gjør dette, får vedkommende kun se sitt eget passord. Hvis mobiltelefonen derimot blir stjålet, kan tyven gjøre det samme og dermed se brukerens passord. Vi mener likevel at denne autentiseringsmetoden er akseptabel. Brukeren som fikk telefonen frastjålet vil måtte melde fra til Telenor, som deretter sperrer abonnementet Kryptering Da denne tjenesten innebærer overføring av passord og personlige opplysninger mellom mobiltelefoner og en Web Service, bør kommunikasjonen mellom disse krypteres. Her har man ulike valgmuligheter. Krypterings-API et Bouncy Castle inneholder klasser for kryptering og dekryptering av data, og kan benyttes både på tjeneren og på klientapplikasjonene. Et problem her er at dette API et er meget stort og derfor ikke er spesielt godt egnet for mobile enheter. En enklere og mer robust metode for kryptering oppnår man ved å benytte HTTPS. HTTPS innebærer vanlig HTTP-interaksjon over krypteringslag som SSL (Secure Socket Layer) eller TLS (Transport Layer Security). Dette sikrer tilstrekkelig beskyttelse mot pakkesniffing. 18

19 Vår J2ME-applikasjon støtter kommunikasjon over HTTPS. Eneste krav er at SSL-sertifikatet som benyttes på tjeneren er signert av en kjent autoritet (Verisign, Thawte etc). Dersom man har betalt en autoritet for å få signert et sertifikat, behøver man kun å installere det nye sertifikatet i applikasjonstjeneren[6], og bytte serverurl-innstillingen i JAD-filen på klientene til i stedet for 19

20 4 Brukergrensesnitt Etter å ha prøvd ut J2MEs standardbibliotek for brukergrensesnitt, fant vi fort ut at dette ikke passet helt til vårt formål. Blant annet er måten knapper/kommandoer (Commands) er implementert på forvirrende og kan lett føre til at selv den mest erfarne mobiltelefonbruker mister tråden. Det virker litt tilfeldig hvor de forskjellige kommandoene legger seg, og man opplever ofte at en kommando har gjemt seg blant en rekke enhetsspesifikke kommandoer. I tillegg opplevde vi det som trasig at det ikke går an å skrolle nedover hvis alle komponente i brukegrensesnittet ikke fikk plass på skjermen. Tatt dette i betrakning begynte vi å hente inpirasjon fra andre J2ME-applikasjoner. Den største inpirasjonskilden ble uten tvil Opera Mini [7]. Opera Mini er en nettleser i form av en liten og kompakt J2ME-applikasjon som ved hjelp av teknologien Small Screen Rendering [8] kan vise selv de mest innholdsrike og avanserte nettsider på enheter med begrenset skjermoppløsning. Brukergrensesnittet til Opera Mini er intuitivt og fint å se på. Kommandoer er logisk plassert og forandrer seg dynamisk etter innholdet på skjermen. Man får en rullegardin som brukes til å skrolle med hvis innholdet ikke passer på skjermen. Med utgangspunkt i dette fant vi ut av ville designe vårt eget UI-bibliotek som passet til den applikasjonen vi skulle utvikle. Dette var derimot ikke en enkel oppgave, da vi måtte tegne opp alle UI-komponente selv ved hjelp av Canvas-systemet i J2ME. I forhold til Canvas-systemet hadde vi to valg. Vi kunne enten benytte den vanlige Canvas-klassen, eller klassene i pakken javax.microedition.lcdui.game. Denne pakken blir gjerne omtalt som The MIDP 2.0 Game API. Spill-API et gjør det enklere å lage spill for mobiltelefonen. Blant annet inneholder dette API et en del ekstrafunksjonalitet som er nyttig i denne sammenhengen; laghåndtering av grafiske elementer (Sprites), mer avansert tasttrykksbehandling samt mulighet for å spesifisere bakgrunnskart. Grunnen til at vi valgte å ta i bruk GameCanvas framfor den mer tradisjonelle Canvas, var at vi fikk mer fleksibilitet blant annet når det gjaldt behandling av tastetrykk og opptegning av grafiske elementer. 20

21 4.1 Rammeverk for brukergrensesnitt Figur 6: Oversikt over UI-biblioteket Figur 6 viser klassene som inngår i UI-rammeverket og assosiasjonene mellom dem. Screen er en Singleton-klasse som representerer selve skjermen/displayet. Denne arver fra GameCanvas, som er en klasse i spill-api et til J2ME. En av de viktigste klassene i UI-biblioteket er Form. Dette er selve innholdet som skal vises på skjermen. En Form er en konteiner for UI-komponenter som blant annet tekstfelt og lister. Internt bruker Form spill-api-klassen LayerManager for å holde kontroll over komponentene sine. Fordelen med dette er at vi slipper å skrive masse kode som sørger for å tegne komponentene i riktig rekkefølge og på riktig plass i forhold til hverandre. En Form kobles til Screen ved å kalle metoden setform(form form) på Screen. Hvis Form inneholder mange komponenter, kan det hende at skjermen blir for liten til å vise hele Form en. Da vil Screen sørge for å legge på en rullegardin og med det la brukeren skrolle seg nedover Form en etterhvert som han traverserer gjennom komponentene. Man kan knytte kommandoer til en Form (UICommand). Disse kommandoene vil da gjelde for hele Form en og ikke en spesiell komponent i Form en. Typiske kommandoer som kan brukes her er navigasjonskommandoer for å navigere til andre Form er, OK/Avbryt-kommandoer og så videre. Disse kommandoene vil vises på en TaskBar nederst på skjermen. 21

22 Figur 7: Utseendet på skjermen. Figur 7 viser hvordan skjermen er bygd opp. Vi har en Header på toppen, deretter en Form i midten og en eventuell ScrollBar hvis Form en er for stor til å passe inn. Nederst er Form ens TaskBar, hvor kommandoene knyttet til Form en er plassert. Den valgte komponenten har en ekstra markør rundt seg som viser at denne er valgt. Når brukeren trykker ned eller opp-tasten på sin telefon vil markøren traversere til neste eller forrige komponent. En komponent kan også ha indre traversering; i dette tilfellet består komponenten av flere valgbare elementer. Et eksempel på dette er List. Her kan man velge mellom flere forskjellige elementer i listen. TextField derimot, består kun av et tekstfelt, og har dermed ingen indre traversering. Måten dette er løst på er å definere en abstrakt metode i UIComponent: public abstract boolean traverse(int direction); Denne metoden skal returnere true hvis komponenten har indre traversering. Da blir det også opp til komponenten å holde styr på denne indre traverseringen, og tegne opp markør på riktig plass. Når brukeren traverserer over det siste elementet til komponentens indre traversering, vil metoden returnere false, som betyr at det er trygt å traversere til neste komponent. Parameteren direction angir i hvilken retning det skal traverseres; 1 for nedover og -1 for oppover. Hvis komponenten ikke har indre traversing, vil metoden kun returnere false. 22

23 Et annen hensyn vi måtte ta når det gjaldt traverseringen, var at hvis innholdet på skjermen var større enn displayet, og skrolling var nødvendig, måtte det skrolles hvis neste element i traverseringen var utenfor skjermen. Dette synliggjøres på figuren under. Figur 8: Skrolltraversering. Til venstre i bildet er markøren på det siste elementet i List 1. Når brukeren trykker ned-tasten, skal TextField 2 bli den valgte komponenten. Men denne komponenten er bare halvveis synlig; den ligger utenfor skjermen. Dermed må traverseringskoden sørge for å skrolle nødvendig mengde slik at TextField 2 vises i sin helhet. Til høyre vises resultatet etter at brukeren har trykket ned-tasten. Det har blitt skrollet akkurat nok til at hele komponenten vises nederst. 23