Ontwerp van een mobiele client voor de verwerking van attachments

Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse

Ontwerp van een mobiele client voor de verwerking van e-mail attachments door Dieter Verslype

Promotoren: Prof. Dr. Ir. F. Gielen, Prof. Dr. Ir. B. Dhoedt

Begeleiders: Ing. T. Bouve, Ir. S. Van Hoecke, Ir. T. Verdickt

Scriptie ingediend tot het behalen van de academische graad van licentiaat in de informatica

Academiejaar 2003–2004

Woord vooraf Zoals de ge¨ıntresseerde lezer wel zal begrijpen is het schrijven van een thesis geen eenvoudige zaak, noch is het het werk van één enkele persoon. Op de eerste plaats komen uiteraard de promotoren Prof. Dr. Ir. F. Gielen en Prof. Dr. Ir. B. Dhoedt, die het thesisonderwerp voorzagen en die regelmatig toetsten hoever het was gesteld met de vooruitgang van het project. Daarnaast komen ook de begeleiders Ing. Thomas Bouve, Ir. Sofie Van Hoecke en Ir. Tom Verdickt. Ze deden me inzien dat een thesis niet zozeer een noodzakelijk kwaad is, maar eerder een mooie kans om op het einde van de opleiding nog een unieke ervaring op te doen als voorbereiding op het echte werk. Ik wens hen dan ook het beste met hun doctoraat. De samenwerking met mijn medestudenten Raf Hens en Koen Stroobant verliep vlot. We hebben samen een mooi pakket ontwikkeld. Niet te verwaarlozen is de steun en het geduld die ik van mijn ouders kreeg, het plezier en vertier van mijn vrienden en mijn vriendin Julie. Bij het schrijven van deze tekst besef ik - met enige melancholie - dat het studentenleven voor mij bijna afgelopen is. Bedankt aan alle opgenoemde personen, het was een tof jaar!

Dieter Verslype, mei 2004

Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren 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.”

Dieter Verslype, mei 2004

Inhoudsopgave 1 Inleiding

1

2 Technologisch overzicht

3

2.1

Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1

J2EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.2

J2SE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.3

J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2

Base64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.3

MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.4

IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.5

XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.6

GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3 Architectuur

14

3.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.2

Globale Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.3

Communicatie tussen client en client module server . . . . . . . . . . . . . . . . .

15

3.3.1

Aanvragen van een service . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

Communicatie tussen modules en client module server . . . . . . . . . . . . . . .

16

3.4.1

Aanvragen van de verwerkingsmogelijkheden . . . . . . . . . . . . . . . .

16

3.4.2

Updaten van de verwerkingsmogelijkheden . . . . . . . . . . . . . . . . . .

17

3.4.3

Aanvragen van een proces . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

Operationele scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

3.5.1

Interactie e-mail client - gateway . . . . . . . . . . . . . . . . . . . . . . .

19

3.5.2

Interactie client module server - e-mail module client . . . . . . . . . . . .

22

3.4

3.5

i

3.5.3

Samenvattend voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.6

Architectuur e-mail client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.7

Architectuur e-mail client module . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4 Software implementatie 4.1

4.2

29

E-mail module client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.1.1

Klassebespreking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.1.2

Enkele codedetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

E-mail module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.2.1

Klassebespreking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.2.2

Enkele codedetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

5 Systeem testen

48

5.1

Overzicht testfases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.2

Demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

5.3

Enkel screenshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6 Conclusies 6.1

54

Mogelijke uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ii

54

Hoofdstuk 1

Inleiding Het is tegenwoordig mogelijk om tekstuele e-mails te downloaden van een mailserver en te lezen op een mobiel toestel. Maar door de geringe mogelijkheden inzake opslag, verwerking en visuele voorstelling is het nog niet echt haalbaar om attachments te beheren op een mobiel toestel. Op de laatste nieuwe modellen is het wel al mogelijk om afbeeldingen op te slaan, maar toch staan al deze technieken nog in hun kinderschoentjes, zodat ze niet volledig aan onze verwachtingen voldoen. We willen immers ook bijvoorbeeld PDF-bestanden en andere uit onze mails kunnen halen, om deze te bekijken.

Zou het mogelijk zijn om een betrouwbare, gebruiksvriendelijke applicatie te ontwerpen die toelaat bij het lezen van e-mail op een mobiele telefoon ook de attachments te gaan bekijken? Zolang de huidige beperkingen blijven op een mobiel toestel, blijft het antwoord op deze vraag ”Neen!”. Maar misschien kunnen we toch al een stap zetten in de goede richting door het vereenvoudigen van mobiel e-mailbeheer. Daarom werd het volgende idee bedacht: als men nu eens enkel de tekstuele boodschappen zou gaan voorstellen op de mobiele mail client en de attachments zou laten downloaden door een gateway, die deze dan kan laten afhandelen op het LAN-netwerk (bijvoorbeeld printen voor een PDF of afspelen op een geluidsinstallatie voor een MP3). Zo kunnen mails toch mobiel gelezen worden en de attachments erbij een bestemming krijgen.

Dit zou voor vele mensen, die vaak onderweg zijn zoals verkopers, al een aardige verbetering zijn. Stel dat een handelsreiziger via e-mail de nieuwe cataloog in PDF-formaat van zijn leverancier krijgt. Dan kan hij, waar hij ook is, beslissen dit bestand te laten afdrukken, zodat als hij terug

1

op zijn kantoor aankomt de cataloog klaarligt op zijn printer en hij onmiddellijk zijn nieuwe bestellingen kan doen.

Er zal dus een soort mailclient ontwikkeld worden, die voldoet aan enkele eisen. Er werd gekozen om deze in Java 2 Micro Edition te schrijven, omdat dit een uiterst flexibel platform is voor het ontwikkelen van eenvoudige applicaties en het door de meeste recente mobiele toestellen wordt ondersteund. De client moet uiteraard in de mogelijkheid zijn om via het internet te verbinden met een mailserver over TCP/IP. Dit is mogelijk met een GPRS mobiel toestel (cfr. infra). Het moet ook mogelijk zijn deze mails slechts gedeeltelijk te downloaden (enkel de tekst en de lijst van attachments, niet de attachments zelf). Dit is mogelijk met IMAP (cfr. infra), een e-mail fetch protocol dat toelaat stukken van een mail apart te downloaden. De mail client zal daarnaast ook in de mogelijkheid zijn om te verbinden met de gateway. De software voor de gateway werd geschreven in Java 2 Standard Edition.

Deze thesis is een deel van een groepsproject. Naast het verwerken van e-mail attachments worden ook applicaties ontwikkeld voor het verwerken van de mediabestanden van een MMSbericht en het controleren van een domoticasysteem. Er wordt sporadisch verwezen naar de andere werken. In de volgende hoofdstukken wordt een beschrijving gegeven van hoe de mailapplicatie werd ontwikkeld.

2

Hoofdstuk 2

Technologisch overzicht 2.1

Java

Figuur 2.1: Java overzicht

Java, ontwikkeld door Sun Microsystems, is een programmeertaal die streeft naar platformonafhankelijkheid (het ”Write Once, Run Anywhere-principe). Ondertussen zijn er verschillende versies op de markt voor uiteenopende doeleinden zoals te zien in Figuur 2.1 (Bron: [1]). Hier-

3

onder bespreken we de voor ons relevante onderdelen (zie ook [2]).

2.1.1

J2EE

Java 2 Platform, Enterprise Edition (J2EE), is een ontwikkelomgeving die het de ontwerpers makkelijker maakt bedrijfsapplicaties te schrijven door ze te baseren op gestandaardiseerde, modulaire componenten. (zie ook [3])

2.1.2

J2SE

Java 2 Platform, Standard Edition (J2SE) biedt een volledige omgeving aan voor het applicatieontwerp op desktop computers en servers en werd ook als basis gebruikt voor J2EE. (zie ook [4])

2.1.3

J2ME

Java 2 Platform, Micro Edition (J2ME) definieert configuraties en profielen voor het bouwen van complete java runtime environments die voldoen aan een waaier van toestellen en markten. Configuraties Configuraties bestaan uit een virtuele machine en een minimum aan klassebibliotheken die een basisfunctionaliteit aanbieden voor een bepaalde klasse van toestellen met gelijke karakteristieken. Op dit moment zijn er twee: Connected Device Configuration (CDC) en Connected Limited Device Configuration (CLDC). Zoals de naam duidelijk maakt is CLDC een configuratie voor minder krachtige toestellen, zoals mobiele telefoons, pagers en PDA’s. Profielen Voor het aanbieden van een complete java runtime environment gericht op specifieke klassen van toestellen moeten configuraties gecombineerd worden met een profiel. Dit zijn extra klassen bovenop de configuratie voor het controleren van toestelspecifieke eigenschappen. Hét profiel inzake mobiele telefoons is Mobile Information Device Profile (MIDP). Optionele pakketten Bovenop het profiel kunnen nog optionele pakketten worden ge¨ınstalleerd. Veel GSM-fabrikanten ontwerpen zo’n pakket, vanuit commercieel oogpunt, opdat hun software niet compatibel zou

4

zijn met GSM’s van andere fabrikanten. We hebben gekozen om de GSM-zijde van de thesis te schrijven met MIDP 1.0 zonder optionele pakketen. Ondertussen is er een herziene versie MIDP 2.0, maar deze was nog niet uitgebracht bij de aanvang van de thesis.

2.2

Base64

Base64 is een codering die binaire bestanden omzet naar een rij van karakters. Ze zet telkens 3 bytes van het inputbestand om naar 4 karakters. Ze gebruikt dus 6 bits per karakter (64 verschillende karakters). De gebruikte karakters zijn: het alfabet in kleine letters (26), het alfabet in hoofdletters (26), de tien cijfers (10) en ’+’ en ’/’. Op het einde kan er zich een probleem voordoen indien de grootte van het inputbestand geen veelvoud van 3 is. Dit wordt opgelost door ’0’-bytes toe te voegen aan het einde van het input bestand. Uiteraard mogen deze bytes niet op de gewone manier gecodeerd worden, maar worden ze als ’=’ gecodeerd. Het decodeerproces verloopt analoog. In Tabel 2.1 staat de codeertabel voor Base64 afgebeeld. Zie ook [6]

2.3

MIME

MIME of Multipurpose Internet Mail Extensions specifieert uitbreidingen inzake e-mail, waaronder: • mails kunnen meer objecten bevatten • geen beperkingen meer inzake lijnlengte en totale lengte van de mail • andere karaktersets dan ASCII Een MIME-boodschap bestaat uit headers met daaronder datablokken (met eigen headers), waarbij ieder blok zijn eigen MIME-type bezit. Een MIME-type is net als een bestandsextensie een soort wijzer van hoe de data moet ge¨ınterpreteerd worden. Het eerste blok uit een mail is meestal de tekstuele boodschap in text/plain” of text/html” ” ” (of beide) en de daaropvolgende blokken zijn de attachments. Deze zijn meestal binaire bestanden. Omdat IMAP een tekstprotocol is, zijn die binaire bestanden gecodeerd in Base64. De aparte delen van een MIME-boodschap worden gescheiden door een boundary, een soort random

5

bits

karakter

bits

karakter

bits

karakter

bits

karakter

000000

A

010000

Q

100000

g

110000

w

000001

B

010001

R

100001

h

110001

x

000010

C

010010

S

100010

i

110010

y

000011

D

010011

T

100011

j

110011

z

000100

E

010100

U

100100

k

110100

0

000101

F

010101

V

100101

l

110101

1

000110

G

010110

W

100110

m

110110

2

000111

H

010111

X

100111

n

110111

3

001000

I

011000

Y

101000

o

111000

4

001001

J

011001

Z

101001

p

111001

5

001010

K

011010

a

101010

q

111010

6

001011

L

011011

b

101011

r

111011

7

001100

M

011100

c

101100

s

111100

8

001101

N

011101

d

101101

t

111101

9

001110

O

011110

e

101110

u

111110

+

001111

P

011111

f

101111

v

111111

/

Tabel 2.1: Codeertabel voor Base64

application/x-latex audio/mp3 image/jpeg message/rfc822 multipart/mixed text/richtext video/mpeg Tabel 2.2: enkele MIME-types

6

rij van karakters. Hieronder zie je voorbeelden van die blokken.

Voorbeeld van MIME-headers waarin oa. het pad staat dat de mail heeft afgelegd en de typische headers (from, to, cc, . . . ). De headers zijn afgesloten door een boundary.

Return-Path: Received: (from apache@localhost) by mail.ugent.be (8.11.6/8.11.6) id i3CGaJf29902 for [email protected]; Mon, 12 Apr 2004 18:36:19 +0200 X-Authentication-Warning: mail.ugent.be: apache set sender to Dieter.Verslype@UG ent.be using -f Received: from 81.240.228.66 ( [81.240.228.66]) as user [email protected] by mail.ugent.be with HTTP; Mon, 12 Apr 2004 18:36:19 +0200 Message-ID: <[email protected]> Date: Mon, 12 Apr 2004 18:36:19 +0200 From: Dieter Verslype To: [email protected] MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) 3.1 X-SA-Exim-Mail-From: [email protected] Subject: Demo IMAP protocol Content-Type: multipart/mixed; boundary="-MOQ1081787779853b79fc4000a99fbfd673269 2442467" X-Spam-Status: No, hits=0.0 required=5.0 tests=none, DCC CHECK FROM tiscali.be fwmail4 1025; Body=1 Fuz1=1 This message is in MIME format. ---MOQ1081787779853b79fc4000a99fbfd6732692442467 Voorbeeld van een tekstueel MIME-blok (afgesloten door de boundary):

Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit hallo, Dit is de body van de mail. Er is ook nog een attachment met de naam IMAP.txt. groetjes, Dieter ---MOQ1081787779853b79fc4000a99fbfd6732692442467

7

Voorbeeld van een attachment MIME-blok gecodeerd in Base64 formaat (afgesloten door de boundary). Het attachment is van het type text/plain en draagt de naam IMAP.txt”. ” Content-Type: text/plain; name="IMAP.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IMAP.txt" RGl0IGlzIGVlbiBhdHRhY2htZW50IGdlY29kZWVyZCBpbiBCYXNlNjQgZm9ybWFhdC4= ---MOQ1081787779853b79fc4000a99fbfd6732692442467 Zie ook [7] en [8]

2.4

IMAP

IMAP staat voor Internet Message Access Protocol. Het is een krachtiger e-mail fetch protocol dan het populairdere Post Office Protocol v3 (POP3). Het verschil bij POP3 is dat de mails op de IMAP-server blijven staan terwijl deze bij POP3 na het downloaden op de client van de server worden verwijderd. Het grote voordeel is dat men zijn mails op meerdere PC’s kan lezen en beheren. De kracht van IMAP zit in de uitgebreide lijst commando’s die een IMAP-server kan verwerken. Tabel 2.3 heeft een overzicht van een aantal van deze commando’s. LOGIN <paswoord>

inloggen op de server

SELECT <mailbox>

openen van een mailbox

FETCH (RFC822)

mail volledig downloaden

FETCH (BODYSTRUCTURE)

MIME-structuur van een mail opvragen

FETCH BODY[<part>]

MIME-part van een mail downloaden

FETCH BODY[<part>.MIME]

MIME-headers van een MIME-part downloaden

STORE +FLAGS.SILENT(\DELETED)

mail als verwijderd markeren

EXPUNGE

effectief verwijderen van gemakeerde mails

CLOSE

sluiten van een mailbox

LOGOUT

uitloggen van de server Tabel 2.3: IMAP commando’s

Alle commando’s worden voorafgegaan door een willekeurige karakterstring. Als een server een antwoord formuleert op een aanvraag, geeft hij die string terug om duidelijk te maken op welk commando hij antwoordt. Hier volgt een telnetsessie met een IMAP-server waarop de mail

8

uit het vorig voorbeeld zich bevond (communicatie van de client naar de server wordt aangegeven met ’C:’ en omgekeerd met ’S:’).

Het verbinden en inloggen dvrslype:\>telnet pegasus.atlantis.ugent.be 143 S: * OK IMAP4 server ready (6.7.019.1) C: a1 LOGIN dvrslype ******** S: a1 OK login successful Het Selecteren van de inbox:

C: S: S: S: S: S: S: S: S:

a2 SELECT inbox * 1 EXISTS * 1 RECENT * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $MDNSent) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $MDNSent)] * OK [UIDVALIDITY 1069167259] mailbox UID validity * OK [UNSEEN 1] first unseen message number * OK [UIDNEXT 34] predicted next UID a2 OK [READ-WRITE] SELECT complete

Het opvragen van de structuur van de mail:

C: a3 FETCH 1 (BODYSTRUCTURE) S: S: S: S: S:

* 1 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" ("charset" "ISO-8859-1") NIL NIL "8bit " 112 8)("TEXT" "PLAIN" ("name" "IMAP.txt") NIL NIL "base64" 70 1 NIL ("attachme nt" ("filename" "IMAP.txt"))) "MIXED" ("boundary" "-MOQ1081787779853b79fc4000a99 fbfd6732692442467"))) a3 OK FETCH complete

Het opvragen van de data van het eerste MIME-blok van de mail:

C: a4 FETCH 1 BODY[1] S: S: S: S: S:

* 1 FETCH (BODY[1] {112} hallo, Dit is de body van de mail. Er is ook nog een attachment met de naam IMAP.txt.

9

S: S: groetjes, S: S: Dieter) S: a4 OK FETCH complete Het opvragen van de headers van het tweede MIME-blok van de mail:

C: a5 FETCH 1 BODY[2.MIME] S: S: S: S: S: S: S:

* 1 FETCH (BODY[2.MIME] {134} Content-Type: text/plain; name="IMAP.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IMAP.txt" ) a5 OK FETCH complete

Het opvragen van de data van het tweede MIME-blok van de mail:

C: a6 FETCH 1 BODY[2] S: S: S: S:

* 1 FETCH (BODY[2] {70} RGl0IGlzIGVlbiBhdHRhY2htZW50IGdlY29kZWVyZCBpbiBCYXNlNjQgZm9ybWFhdC4= ) a6 OK FETCH complete

2.5

XML

XML staat voor eXtensible Markup Language en is een taal voor het gestructureerd beschrijven van data, die zoals HTML gebruik maakt van tags. De verschillen met HTML zijn dat de taal geen vastgelegde tags moet gebruiken (en dus uitbreidbaar is) en dat XML niet vertelt hoe de data moet worden voorgesteld. Daarvoor kan XML gebruik maken van stylesheets (CSS, XSL, ...).

Ieder welgevormd XML-document begint met het definiëren van de XML-versie en de codering van het document (voor een voorbeeld wordt doorverwezen naar het einde van de paragraaf). Daarna komt de eigenlijke data in tags gebruikmakend van een boomstructuur met slechts één rootelement. Iedere tag ’<element>’ moet een sluittag ’’ voorafgaan. Indien er

10

geen data tussen de openen sluittag moet, kan ook gebruik gemaakt worden van ’<element/>’. Iedere opentag kan ook attibuten hebben zoals in ’<element id=”1”>’. Een XML-document wordt geldig genoemd als het voldoet aan een bepaalde Document Type Definition (DTD). Die DTD’s zijn een soort definitie van de structuur van een document en bepalen welke elementen toegelaten zijn, welk type de argumenten zijn enz..., zoals duidelijk wordt in onderstaand voorbeeld. Een voorbeeld van een XML-document: <mailclient gebruiker = "Dieter Verslype"> <mailbox naam = "UGENT"> <mail afzender = "Fred" onderwerp = "THESIS"> Hierbij mijn thesis als bijlage. Thesis.pdf <mailbox naam = "SKYNET"> <mail afzender = "Piet"> Veel succes met de examens! <mail afzender = "Stef" onderwerp = "foto’s"> 1.jpg 2.jpg 3.jpg met mailclient.dtd:
mailclient (mailbox+)> mailclient gebruiker CDATA #REQUIRED> mailbox (mail*)> mailbox naam CDATA #REQUIRED> mail (body,attachment*)> mail afzender CDATA #REQUIRED>

11

In het voorbeeld zien we een XML-document dat een bepaalde mailclient voorstelt volgens de definitie in mailclient.dtd. In mailclient.dtd zien we dat een mailclient bestaat uit één of meer (aangeduid door het ’+’-teken) mailbox-elementen en één verplicht attribuut: gebruiker. Een mailbox heeft één verplicht attribuut (naam) en bevat geen, één of meerdere (aangeduid door het ’*’-teken) mail-elementen. Een mail heeft verplicht een afzender, maar onderwerp is niet verplicht. Een mail bestaat uit exact één body en geen, één of meerdere attachment-elementen. In Figuur 2.2 zien we de boomstructuur van bovenstaand XML-document (voor de eenvoud zonder data in de bladeren).

Figuur 2.2: voorbeeld XML-boomstructuur

2.6

GPRS

GPRS of General Package Radio Service is een pakketgebaseerde draadloze verbinding voor gebruikers van mobiele telefoons. GPRS werkt op het gewone GSM-netwerk (Global System for Mobile Communications), maar maakt er efficiënter gebruik van en haalt snelheden van 56 tot 114 kbps (afhankelijk van het gewone GSM verkeer). Het grootste verschil met oudere tech-

12

nieken (zoals Circuit Switched Data) is dat er betaald wordt per byte in plaats van per seconde. Dit maakt de weg vrij voor verscheidene applicaties naar de GSM, bv: chatten (lage troughput per seconde, dus goedkoper via GPRS).

Zoals reeds gezegd zullen de attachments van een mail niet op de GSM worden gedownload. Dit blijkt nu ook een voordeel te zijn wegens goedkoper.

GPRS zal nooit echt doorbreken, aangezien zijn opvolger zich al staat op te dringen namelijk UMTS (Universal Mobile Telecommunications System), waarmee de derde generatie mobiele telefoons (3G) zullen uitgerust zijn. UMTS werkt volgens dezelfde principes als GPRS, maar dan tegen nog hogere snelheden (tot 384 kbps) tegen een uiteraard hogere prijs.

13

Hoofdstuk 3

Architectuur 3.1

Inleiding

In dit onderdeel wordt een schets gegeven van hoe het project werd onderverdeeld en hoe de communicatie tussen deze delen verloopt. Er worden drie verschillende services aan mobiele gebruikers aangeboden (MMS, e-mail en domotica). Gemakkelijkheidshalve konden er gewoon drie verschillende mobiele programma’s geschreven worden met hun bijhorend stuk software voor de gateway. Er werd echter gekozen om de bestanden, eens gedownload, door een gemeenschappelijk deel te laten afhandelen. De aparte delen voor de verschillende services zijn dan een soort module die worden ingeplugd op een gemeenschappelijke server. Er is voor deze aanpak gekozen omdat het een voordeel biedt: indien men een nieuwe service wenst te ontwikkelen moet men enkel een nieuwe mobiele applicatie en een bijhorende module schrijven (m.a.w. uitbreidbaarheid). De communicatie tussen de module en de gemeenschappelijke server gebeurt via XML-documenten.

3.2

Globale Architectuur

Figuur 3.1 toont de globale architectuur van ons project. De centrale server, die de client module server wordt genoemd, is ontwikkeld door Raf Hens. Deze maakt het mogelijk om aparte client modules te laden die specifieke bestanden ter beschikking kunnen stellen van de client module server op aanvraag van een mobiele client.

De afhandeling van de bestanden gebeurt dan verder door de client module server. De MMS client module stelt de mediabestanden uit een MMS bericht ter beschikking (ontwikkeld door

14

Figuur 3.1: Globale Architectuur

Koen Stroobant) en de domotica client module werkt met XML bestanden die duidelijk maken welke acties er in huis moeten gebeuren (ontwikkeld door Bart Jacobs).

3.3

Communicatie tussen client en client module server

Na het verbinden met de gateway moet de client duidelijk maken welke service gewenst is, met welke client module deze wil communiceren. Deze communicatie gebeurt via XML (zie Figuur 3.2). Hieronder wordt verduidelijkt hoe deze communicatie verloopt.

Figuur 3.2: XML commucicatie tussen client en module

15

3.3.1

Aanvragen van een service

Nadat een verbinding wordt tot stand gebracht tussen de client en de client module server, stuurt de eerste een XML-string naar de server geldig volgens de volgende DTD:

serviceRequest.dtd: In het geval van de mail module is dit dus: ’<servicerequest clientid=”mail”/>’. Het antwoord van de server op deze aanvraag is een XML-string naar deze DTD:

serviceResponse.dtd:
error (text?)> error code CDATA #REQUIRED> text (#PCDATA)> info (#PCDATA)>

Dit betekent dat de server op 3 mogelijke manieren kan antwoorden. Als alles normaal verloopt krijgt de client gewoon ’<serviceresponse result = ”ok”/>’ terug en kan hij beginnen met zijn aanvraag aan de module. Indien de module echter niet geladen is, wordt ’<serviceresponse result = ”notfound”/>’ terug gegeven of als er een fout opgetreden is ’<serviceresponse result = ”error”/>’ met eventuele kinderen die de fout verduidelijken. De communicatie tussen de modules en de client is natuurlijk de keuze van de ontwikkelaar en wordt hier dus niet besproken.

3.4 3.4.1

Communicatie tussen modules en client module server Aanvragen van de verwerkingsmogelijkheden

Iedere processing module kan een aantal MIME types verwerken. Een print module kan bijvoorbeeld ’text/plain’ en ’image/bmp’ verwerken. Als een client verbonden is op de e-mail client module en voor een bepaald voor een bepaald type de mogelijkheden wil kennen, dan moet de

16

module deze kunnen achterhalen. Er zijn twee mogelijkheden om deze te weten te komen: ofwel door telkens de verwerkingsboom” op te vragen (deze structuur wordt hieronder verduidelijkt) ” aan de module server, ofwel door de boom enkel bij het laden van de module op te vragen en een luisteraar te registreren bij de server, die zorgt voor het updaten van de boom, bijgehouden door de client module. Voor de e-mail client module werd voor de laatste aanpak geopteerd. De volgende DTD definieert de structuur van de verwerkingsboom die opgevraagd wordt bij het laden van de module. getAvailableProcessingCapabilitiesResponse.dtd:

Figuur 3.3 toont een voorbeeld van deze XML structuur. De kinderen van een ’module’ zijn de MIME-types die door deze ’module’ verwerkt kunnen worden of het element X-ANY wat betekent dat alle MIME-types erdoor kunnen verwerkt worden. De e-mail client module houdt deze boom dus bij en wanneer een client een aanvraag doet, kan het in deze boom gaan zoeken naar de verwerkingsmogelijkheden.

Figuur 3.3: Voorbeeld XML structuur bij het aanvragen van de verwerkingsmogelijkheden

3.4.2

Updaten van de verwerkingsmogelijkheden

Nadat een module is geladen, kunnen er natuurlijk verwerkingsmogelijkheden bijkomen (bv: printer wordt aangezet). Dan worden alle modules hiervan op de hoogte gebracht zodat ze hun

17

verwerkingsboom kunnen aanpassen. Dit gebeurd volgens deze DTD: capabilityAdded.dtd: Figuur 3.4 geeft een voorbeeld weer van deze XML structuur. De toppen worden dan gewoon toegevoegd aan de boom. Voor het verwijderen van een module wordt gewoon de naam van de module doorgegeven aan de client module.

Figuur 3.4: Voorbeeld XML structuur voor het updaten van de verwerkingsmogelijkheden

3.4.3

Aanvragen van een proces

Indien een client zijn aanvraag heeft afgehandeld, moet de module met deze informatie een proces gaan aanvragen (bijvoorbeeld een bestand afdrukken) aan de module server. Dit gebeurt met een XML document naar de volgende DTD: processRequest.dtd:

18

Een processingrequest kan uit meerdere requests bestaan. Een request bevat één of meerdere verwerkingsmodules en data. De data kan ook verschillende vormen aannemen, nl een XMLstring op zich, een bestandsnaam of mixed type. Bij domotica moeten er bijvoorbeeld meerdere acties in eens gebeuren (licht aan, bad laten lopen). Bij de e-mail module zullen dit eenvoudige XML documenten met slechts één request en één bestandsnaam zijn van de volgende vorm: <processingrequest> <request> <module id="print"/>

3.5

Operationele scenario’s

3.5.1

Interactie e-mail client - gateway

Na een mail te hebben gedownload met de e-mail client kan er uit de lijst met attachments één enkele geselecteerd worden. Voor elke keer dit gebeurt, wordt er opnieuw verbonden met de gateway en worden de mogelijke acties aan de gebruiker meegedeeld voor dat specifiek MIMEtype (dit zal uiteraard anders zijn voor text/html dan voor audio/mp3). Als de client verbindt met de server kunnen er zich meerder situaties voordoen: Geval 1: Basisscenario. 1. De client verbindt met de client module server. Er wordt ook duidelijk gemaakt dat de boodschap van de e-mail client komt en dat er dus verlangd wordt om te communiceren met de e-mail client module. 2. De module is beschikbaar. De client module server antwoordt positief. Vanaf dit moment communiceert de client dus met de e-mail module client. 3. De client vraagt of er diensten beschikbaar zijn voor een bepaald MIME-type.

19

Figuur 3.5: Geval 1: Basisscenario.

4. De module stuurt een lijst van voorhanden diensten (bv: opslaan). Op het mobiel toestel verschijnt een keuzelijst, waarbij slechts 1 keuze kan gemaakt worden. Indien men meer verrichtingen wil maken met hetzelfde bestand dan moet men de handeling volledig over doen (opnieuw verbinden etc.) 5. De client kiest een optie, deze wordt samen met de eigenschappen (IMAP-server, poort, gebruikersnaam, paswoord, bestandsnaam) van het gekozen attachment doorgestuurd. 6. De e-mail client module zal deze aanvraag verwerken, maar sluit nu al de verbinding. Er is geen feedback over het verloop van de aanvraag.

Geval 2: De gewenste optie is niet beschikbaar.

Figuur 3.6: Geval 2

20

1. De client verbindt met de gateway en vraagt de e-mail client module aan. 2. De module is beschikbaar. De gateway antwoordt positief. Vanaf dit moment communiceert de client dus met de e-mail client module. 3. De client vraagt of er diensten beschikbaar zijn voor een bepaald MIME-type (bv: text/html). 4. De module stuurt de verschillende opties door. 5. De client had graag een andere optie gezien (bv: afdrukken), kiest de cancel-optie en de verbinding wordt verbroken.

Geval 3: Geen enkele optie is beschikbaar.

Figuur 3.7: Geval 3

1. De client verbindt met de gateway en vraagt de e-mail client module aan. 2. De module is beschikbaar. De gateway antwoordt positief. Vanaf dit moment communiceert de client dus met de e-mail client module. 3. De client vraagt of er diensten beschikbaar zijn voor een bepaald MIME-type (bv: audio/mp3). 4. De module antwoordt dat er voor dit MIME-type geen service beschikbaar is. Enkel de cancel-optie verschijnt op het scherm van de client. 5. De client kiest de cancel-optie en de verbinding wordt verbroken.

21

Geval 4: De e-mail client module is niet beschikbaar.

Figuur 3.8: Geval 4

1. De client verbindt met de gateway en vraagt de e-mail client module aan. 2. De gateway antwoordt dat de module niet beschikbaar is. Op het mobiel toestel verschijnt een gepaste foutmelding. De gateway sluit de verbinding actief.

Geval 5: De client module server is niet on-line.

Figuur 3.9: Geval 5

1. De client probeert te verbinden met de gateway maar er vindt een time-out plaats. De server is niet on-line. Op het mobiel toestel verschijnt een gepaste foutmelding.

3.5.2

Interactie client module server - e-mail module client

De client verbindt met de gateway. Deze wil de socket waarmee de client verbonden is doorgeven aan de e-mail client module. Er kunnen zich volgende situaties voordoen: Geval 1: Basisscenario. 1. De client module server controleert of de e-mail client module voorhanden (geladen) is. 2. De module is beschikbaar.

22

Figuur 3.10: Geval 1

3. De clientmoduleserver geeft de socket door waarop de client is verbonden. 4. Na de aanvraag van de client geeft de module een XML document met de gegevens van de aanvraag van aan de client (bestandslokatie en gekozen optie).

Geval 2: De e-mail client module is niet beschikbaar.

Figuur 3.11: Geval 2

1. Een client is verbonden en heeft de e-mail client module aangevraagd. De client module server controleert of de module voorhanden (geladen) is. Dit is niet zo. De client communicatie verloopt zoals in Geval 4 van vorige sectie.

3.5.3

Samenvattend voorbeeld

1. De client verbindt met de client module server en vraagt de e-mail client module aan. De server antwoordt dat deze beschikbaar is. 2. De client module server geeft de socket waarop de client is verbonden door aan de module. 3. De client stuurt het MIME-type van het te verwerken bestand door naar de module. Deze kijkt in de verwerkingsboom welke opties mogelijk zijn en stuurt deze door. De

23

Figuur 3.12: Samenvattend Voorbeeld

client antwoordt met de gekozen optie en de eigenschappen van het te verwerken bestand (IMAP-server, poort, gebruikersnaam, paswoord, bestandsnaam, mail index, MIME deel). Hierna wordt de verbinding met de client verbroken. 4. De module downloadt het gevraagde bestand van de IMAP server. 5. De module geeft het bestand door aan de client module server voor de verwerking ervan. 6. De client module server stuurt het bestand naar een randapparaat.

3.6

Architectuur e-mail client

De e-mail client is een GUI die op een mobiele telefoon werkt. Hij is in de mogelijkheid om te verbinden met een IMAP-server en om van de mails op die server de body en de bestandsnamen van de attachments op te slaan. Daarna kan de gebruiker kiezen om te verbinden met de e-mail client module op de client module server en deze vragen om de attachments effectief af te halen. Figuur 3.13 toont de benodigde componenten van de applicatie. Blokken die in het grijs aangeduid zijn, stellen grafische componenten voor. ’hoofdmenu’ is zoals de naam doet vermoeden een keuzemenu. Vanuit dit ’hoofdmenu’ is het mogelijk om naar ’IMAP instellingen’, ’gateway instellingen’ en ’inbox’ te gaan of om de appli-

24

Figuur 3.13: Architectuur e-mail client

catie af te sluiten. De ’IMAP instellingen’ en ’gateway instellingen’ zijn twee gelijkaardige formulieren die bij het opstarten van het programma de host, poort, gebruikersnaam en paswoord uit een bestand laden. Het is mogelijk om deze dan aan te passen en op te slaan. Deze instellingen worden gebruikt om de verbindingen met de IMAP-server en de gateway op te zetten. ’IMAP verbinding’ en ’gateway verbinding’ zijn componenten die het protocol kennen van de server waarmee ze moeten communiceren en het vertalen naar bruikbare data voor de e-mail client. ’mail’ is een eenvoudige component die alle gegevens van één enkele e-mail bijhoudt. ’inbox’ geeft dan een grafische voorstelling van een lijst van ’mail’-objecten (typisch het onderwerp van de ’mail’ en eventueel de verzender). Een ’mailformulier’ toont dan de inhoud van één bepaalde ’mail’, ’attachments’ toont de attachments bij die ’mail’ en ’opties’ toont de verscheidene opties die op de gateway mogelijk zijn voor een bepaalde attachment (afhankelijk van het MIME-type van die attachment).

Figuur 3.14 toont een voorbeeld van de interactie in de e-mail client. Als men in ’hoofdmenu’ de ’inbox’ opvraagt, gebeuren de volgende acties:

25

Figuur 3.14: Interactie e-mail client

1. ’IMAP verbinding’ vraagt de gegevens op om te verbinden met de IMAP server. 2. ’IMAP verbinding’ verbindt met de IMAP server, vraagt de e-mails op en maakt per mail een object van het type ’mail’. 3. ’inbox’ geeft een grafische voorstelling van die mails. 4. Bij het selecteren van een ’mail’ in ’inbox’, verschijnt er een mailformulier op het scherm. 5. Bij het verzoek de attachments bij die mail te zien, verschijnt een ’attachments’. 6. Bij het selecteren van een attachment vraagt ’gateway verbinding’ de gegevens op om te verbinden met de gateway. 7. ’gateway verbinding’ verbindt met de gateway, maakt kenbaar om welk MIME-type het gaat en ontvangt een aantal opties die voorhanden zijn voor dat type. 8. De opties worden voorgesteld in een ’opties’. De verdere communicatie (het kiezen van één van de mogelijkheden) weze duidelijk.

26

Figuur 3.15: Architectuur e-mail client module

3.7

Architectuur e-mail client module

De e-mail client module werkt op de gateway en is geen GUI dus bevat hij ook geen grafische componenten. In Figuuur 3.15 is een blokdiagram van de componenten afgebeeld. De e-mail client module bevat een boom met de verwerkingsmogelijkheden (aangeduid met ’Capability Tree’), die geladen en upgedated wordt zoals hierboven werd verduidelijkt (met behulp van de ’XML Coder Decoder’). Daarnaast is er ook een lijst van threads (per client die verbonden is) die de aanvragen verwerken. Voor het downloaden van de attachments wordt gebruik gemaakt van de IMAP client. Deze kan, indien nodig, de Base64 Decoder aanspreken voor het decoderen van de attachments. Voor het downloaden van de body van een e-mail (in ’text/plain’ of ’text/html’) is dit niet nodig. Nadat de bestanden beschikbaar zijn, maakt de e-mail client module een XML document (met de ’XML Coder Decoder’) voor het aanvragen van de verwerking van het bestand door de client module server.

Figuur 3.16 toont een voorbeeld van de communicatie in de e-mail client module. 1. Bij het laden van de module wordt de verwerkingsboom meegegeven. Na het laden van de module kan de client module server de boom nog updaten. 2. Als een client wordt doorverwezen naar de e-mail client module, wordt een nieuwe thread aangemaakt voor de verwerking van zijn aanvraag.

27

Figuur 3.16: Interactie e-mail client module

3. De thread vraagt de gegevens op van het gevraagde bestand (server, bestandsnaam, gekozen verwerkingsoptie ed.) en geeft deze gegevens door naar de IMAP Client. 4. De IMAP Client gaat de gegevens downloaden van de IMAP server. 5. De IMAP Client laat de gegevens decoderen (indien nodig). 6. De Client Thread vraagt de XML Coder Decoder met de bestandsnaam en de gekozen optie een XML document te maken voor het aanvragen van de verwerking van het bestand. 7. Dit XML document wordt doorgegeven naar de client module server, die de aanvraag afrondt.

28

Hoofdstuk 4

Software implementatie In dit onderdeel wordt de software-ontwikkeling van de e-mail module client en de e-mail module verduidelijkt.

4.1

E-mail module client

De client is een applicatie die ontwikkeld werd voor een Java 2 Micro Edition (J2ME) enabled mobiele telefoon. Voor het leren programmeren in deze omgeving werd [10] gebruikt. Als aanzet werd gekeken naar een open source IMAP client ([11]), voornamelijk voor het achterhalen hoe het IMAP protocol behandeld werd. Uiteindelijk werd hieruit enkel één klasse behouden, namelijk ’MyConnection’, een lijngerichte communicatieverbinding, omdat deze niet standaard aanwezig is in J2ME. Sun Microsystems gebruikt het suffix ’let’ als naam voor vele soorten programma’s die deel uitmaken van de java-familie, bv: servlet, applet, spotlet... Onder J2ME heten de programma’s MIDlets (Mobile Information Device). De hoofdklasse van elk programma moet dan ook een extensie zijn van de abstracte klasse javax.microedition.midlet.MIDlet.

4.1.1

Klassebespreking

MAM Onze MIDlet-klasse heet MAM (Mobile Attachment Managment). Figuur 4.1 toont het UML diagram van MAM. MAM is een soort container die alle andere instanties van klassen bijhoudt en de interactie tussen de objecten regelt, doordat MAM ook een implementatie is van de interface javax.microedition.lcdui.CommandListener en luistert naar alle andere objecten. Alle

29

gebeurtenissen die zich voordoen door het drukken op bepaalde knoppen in grafische panelen worden dus afgehandeld door MAM in de methode commandAction. De andere drie methodes komen van de klasse MIDlet en worden opgeroepen door het besturingssysteem van de mobiele telefoon. Indien er bijvoorbeeld een inkomend gesprek is, zal onze applicatie gepauzeerd worden met de methode pauseApp. MAM bevat meerdere grafische componenten (objecten die afgeleidt zijn van de klasse Displayable), maar op het mobiel toestel kan er slechts 1 tegelijk worden afgebeeld. Daarom heeft MAM een Display object die het voorstellen van grafische componenten regelt en een pointer bevat naar het huidig voor te stellen object. Navigerend tussen schermen, moet deze pointer gewijzigd worden. De klasse Alert is een grafische component voor het voorstellen van foutboodschappen. De bespreking van de andere klassen gebeurt hieronder.

Figuur 4.1: UML diagram van het MIDlet MAM

IntroCanvas IntroCanvas is het grafische beginscherm (in de architectuur spraken we van ’hoofdmenu’ in Figuur 3.13.) van de applicatie, met erop een logo dat getekend wordt door de methode paint. Daarnaast staan nog enkele menuopties op het scherm voor het navigeren in het programma, nl. naar de inbox, de instellingen van de verbindingen of voor het afsluiten van het programma.

30

Daarom wordt, net zoals bij alle andere grafische componenten, MAM doorgespeeld met de constructor zodat MAM als CommandListener luistert naar de Command op het scherm. In Figuur 4.2 staat het UML diagram van IntroCanvas afgebeeld.

Figuur 4.2: UML diagram van IntroCanvas

SettingsForm SettingsForm is de analogie van ’IMAP instellingen’ en ’gateway instellingen’ uit Figuur 3.13. Het is een grafisch scherm waar de instelling van een verbinding bewerkt kunnen worden. Het houdt ook de instellingen bij, die toegankelijk zijn door enkele getters. Bij constructie laadt het een bestand (een RecordStore, cfr. infra) uit het geheugen van het toesel (waarvan de naam wordt meegegeven met de constructor). Het is ook mogelijk om de bewerking te annuleren (’cCancel’) of op te slaan in de RecordStore. RecordStore is een klasse die toelaat naar het geheugen van het toestel te schrijven, zodanig dat na afsluiten van de applicatie (en zelfs heropstarten van het toestel) de gegevens nog bewaard zijn. In Figuur 4.3 staat het UML diagram van SettingsForm afgebeeld. Message Message (’mail’ in de architectuur) is een klasse die alle informatie van één mail bijhoudt. Voor de attachments houdt het een Vector bij voor de bestandsnamen (Vector attachments) en een Vector voor de MIME types (Vector types). De methodes zijn voornamelijk getters en setters. De methode addBodyLine wordt gebruikt omdat een mail lijn per lijn wordt gedownload en dan toegevoegd aan de String body in Message. De toString methode wordt gebruikt voor het grafisch voorstellen van een mail op een MailForm. In Figuur 4.4 staat het UML diagram van Message afgebeeld.

31

Figuur 4.3: UML diagram van SettingsForm

InboxList InboxList (’inbox’ in de architectuur) krijgt een array van Messages mee bij constructie (en ook MAM voor het luisteren naar de Commands) en stelt deze voor in een grafische lijst. Wanneer een mail wordt geselecteerd, roept MAM getSelectedMsg op en met het resultaat stelt hij een MailForm op. De methode removeMessage(int i) verwijdert de mail op index i uit de array msgs en hernieuwt de grafische lijst. In Figuur 4.5 staat het UML diagram van Message afgebeeld. MailForm MailForm (of ’mailformulier’) stelt een Message grafisch voor door een StringItem (met de inhoud van Message.toString()) op een Form te plaatsen. Het bevat ook de commando’s om te navigeren naar de attachments, terug te keren naar de inbox of de mail te verwijderen. In Figuur 4.6 staat het UML diagram van MailForm afgebeeld. AttachmentList AttachmentList (of ’attachments’) is een grafische lijst van de attachments bij één mail, op basis van de Vector attachments, meegekregen bij constructie. De methode getSelectedAttachment() geeft de naam van de geselecteerde bijlage terug als String.

32

Figuur 4.4: UML diagram van Message

Figuur 4.5: UML diagram van InboxList

In Figuur 4.7 staat het UML diagram van AttachmentList afgebeeld.

33

Figuur 4.6: UML diagram van MailForm

Figuur 4.7: UML diagram van AttachmentList

OptionList OptionList (of ’opties’) is een grafische lijst die de verwerkingsmogelijkheden voorstelt bij een bepaald attachment, nadat deze opties zijn aangevraagd aan de gateway. De structuur is gelijklopend aan deze van de klasse hierboven. In Figuur 4.8 staat het UML diagram van OptionList afgebeeld.

Figuur 4.8: UML diagram van OptionList

ImapClient ImapClient (of ’IMAP verbinding’) is een klasse die de communicatie verzorgt met de IMAP server met behulp van de lijngerichte verbinding ’MyConnection’. De methode open(String host, int port, int username, int password) zet een nieuwe verbinding

34

op met de IMAP server en logt in. De methode close() verbreekt de verbinding en de methode connected() controlleert of de verbinding actief is. De methode execute(String commando) wordt gebruikt door alle andere methoden om een IMAP commando naar de server te sturen. Hierbij wordt de integer commandCount eerst ge¨ıncrementeerd. Zo wordt bij elke sessie voor elk commando een unieke prefixstring verkregen (zie Sectie 2.4). De publieke methode receiveMsgs roept eerst de methode getMessageCount op, die het aantal boodschappen op de server weergeeft. Daarna roept ze dat aantal maal de private methode receiveMessage(int index) op, die een bericht van de server downloadt en de relevante informatie in een Message-object stopt. De methode removeMessage(int index) verwijdert een e-mail van de server. In Figuur 4.9 staat het UML diagram van ImapClient afgebeeld.

Figuur 4.9: UML diagram van ImapClient

GatewayClient GatewayClient (of ’Gateway verbinding’) verzorgt de communicatie met de gateway. Net als ImapClient heeft het dezelfde methodes inzake verbinding. Daarnaast is er ook een methode receiveOptions om de verwerkingsmogelijkheden voor een bepaald MIME type te ontvangen van de gateway. De resulterende vector wordt dan doorgegeven aan het OptionForm. Ook zijn er nog de receive en send methodes voor het ontvangen en verzenden van data van en naar de gateway. In Figuur 4.10 staat het UML diagram van GatewayClient afgebeeld.

35

Figuur 4.10: UML diagram van GatewayClient

MyConnection MyConnection is zoals reeds gezegd een klasse die overgenomen is uit een open source project ([11]). Het is de implementatie van een lijngerichte verbinding gebaseerd op de karaktergerichte klassen InputStream en OutputStream die wel standaard in J2ME zitten. De publieke methodes send en receive gebruiken de protected methodes read en write. Ook hier zijn weer de standaarmethodes voor het opzetten van de verbinding. In Figuur 4.11 staat het UML diagram van MyConnection afgebeeld.

Figuur 4.11: UML diagram van MyConnection

36

4.1.2

Enkele codedetails

MAM.java Hier volgt een bespreking van het Midlet MAM:

De variabelen en de constructor van MAM: private private private private private private private private private private private

Display display; IntroCanvas intro; SettingsForm imapSettings; SettingsForm gatewaySettings; InboxList inbox; ImapClient imapClient; GatewayClient gatewayClient; MailForm mailForm; AttachmentList attachmentList; OptionList optionList; Alert error;

public MAM() { display = Display.getDisplay(this); intro = new IntroCanvas(this); error = new Alert("ERROR",null,null,AlertType.ERROR); imapClient = new ImapClient(); gatewayClient = new GatewayClient(); try { imapSettings = new SettingsForm(this,"IMAP-Settings","IMAP.dat"); gatewaySettings = new SettingsForm(this,"Gateway-Settings","gateway.dat"); } catch(Exception ex) { error.setString("Error loading settings..."); display.setCurrent(error); } } Display display houdt een pointer bij naar het huidig af te beelden scherm. Als een ander afbeeldbaar object (een kindklasse van Displayable) op het scherm gezet wordt, kan dit gebeuren met display.setCurrent(Displayable d). In de constructor is te zien dat alle grafische componenten een this-pointer meekrijgen met de constructor, omdat de hoofdklasse luistert naar alle knoppen op de schermen. Bij de SettingsForms wordt ook nog de bestandsnaam van de RecordStore meegegeven, waarin de gegevens van een vorig sessie opgeslagen zijn. Dit kan verscheidene

37

Exceptions genereren. Indien er zich een Exception voordoet, wordt een gepaste tekst op de Alert error geplaatst. Een Alert is vergelijkbaar met een dialoogvenster in een desktopomgeving. MAM moet als extensie van MIDlet enkele methoden implementeren: public void startApp() throws MIDletStateChangeException { display.setCurrent(intro); } public void destroyApp(boolean b) { try { imapClient.close(); gatewayClient.close(); } catch(IOException ex){} } public void pauseApp(){}

De eerste methode wordt opgeroepen indien de applicatie wordt opgestart (vergelijkbaar met de methode start voor applets). In dit geval wordt er gewoon voor gezorgd dat het beginscherm wordt afgebeeld. De tweede methode wordt opgeroepen bij het sluiten van de applicatie. Hier wordt verzekerd dat de verbinding correct wordt afgesloten. De laatste methode wordt aangeroepen indien er op de mobiele telefoon een inkomend gesprek is. Hier wordt niks opgevangen omdat GSM-gesprekken en GPRS-communicatie tegelijkertijd kunnen gebeuren. MAM is ook een implementatie van CommandListener. Daarom moet het ook de methode commandAction implementeren. Hieronder is slechts een beknopt deel van deze methode tussengevoegd om een beeld te scheppen van de werking ervan. public void commandAction(Command c, Displayable s) { // opvragen van de inbox if (c == IntroCanvas.cInbox) { try { // verbinding opzetten, mails downloaden en een nieuwe InboxList aanmaken. imapClient.open(imapSettings.getHost(),imapSettings.getPort(), imapSettings.getUsername(),imapSettings.getPassword()); inbox = new InboxList(this,imapClient.receiveMsgs());

38

imapClient.close(); display.setCurrent(inbox); } catch(IOException e) { error.setString("Error trying to connect to IMAP server."); display.setCurrent(error); } } // attachment gekozen, opvragen van verwerkingsmogelijkheden else if (c == AttachmentList.SELECT_COMMAND && s == attachmentList) { try { // verbinden en servicerequest doen gatewayClient.open(gatewaySettings.getHost(), gatewaySettings.getPort(), gatewaySettings.getUsername(), gatewaySettings.getPassword()); gatewayClient.send("<servicerequest clientid=\"mail\"/>"); // antwoord van server bijhouden String response = gatewayClient.receive(); // fout in de aanvraag if (response.indexOf("error")!=-1) { String fout = response.substring(response.indexOf("result=\"error\">")+15, response.indexOf("")); error.setString(fout); display.setCurrent(error); gatewayClient.close(); } // e-mail client module niet geladen else if (response.indexOf("notfound")!=-1) { error.setString("MailModule not found!"); display.setCurrent(error); gatewayClient.close(); } // anders MIME type van gekozen bestand doorsturen, // verwerkingsopties ontvangen en voorstellen op // voorstellen op een OptionList else {

39

String fileType = inbox.getSelectedMsg(). getType(attachmentList.getSelectedIndex()); gatewayClient.send(fileType); optionList = new OptionList(this,gatewayClient.receiveOptions()); display.setCurrent(optionList); } } catch(IOException e) { error.setString("Error trying to connect to gateway.)); display.setCurrent(error); } } // een optie werd gekozen else if (c == OptionList.SELECT_COMMAND && s == optionList) { try { // geselecteerde optie doorsturen gatewayClient.send(optionList.getSelectedOption()); if(!optionList.getSelectedOption().equals("cancel")) { // gegevens van attachment doorsturen gatewayClient.send(imapSettings.getHost()); gatewayClient.send(""+imapSettings.getPort()); gatewayClient.send(imapSettings.getUsername()); gatewayClient.send(imapSettings.getPassword()); gatewayClient.send(""+(inbox.getSelectedIndex()+1)); gatewayClient.send(attachmentList.getSelectedAttachment()); gatewayClient.send(""+(attachmentList.getSelectedIndex()+1)); } gatewayClient.close(); } catch (IOException e) { error.setString("Error trying to transfer data to gateway."); display.setCurrent(error); } display.setCurrent(attachmentList); } } } De methode controleert eerst van welk Command een Event werd ontvangen. In het eerste geval wil de gebruiker de inbox opvragen. Daartoe wordt eerst verbonden met de

40

IMAP server met behulp van de IMAP instellingen. De mails worden gedownload, meegegeven met de constructor van de InboxList en de InboxList wordt op het scherm afgebeeld. Indien er een fout is opgetreden tijdens de transfer met de IMAP server wordt een dialoogvenster op het scherm gezet. In het volgende geval wil de gebruiker voor een bepaald attachment de verwerkingsmogelijkheden kennen. Hiertoe verbindt de gebruiker met de gateway en verzendt ’<servicerequest clientid=”mail”>’ omdat hij de services van de e-mail client module wil gebruiken. In de String response wordt het antwoord opgeslagen van de client module server en wordt gekeken in welke van de drie gevallen men zit. In het geval ’ok’ of ’notfound’ wordt een foutmelding weergegeven. Anders wordt het MIME-type van het te behandelen attachment doorgestuurd en worden de mogelijke opties ontvangen en voorgesteld op een OptionList. Als in dit gehele proces een I/Ofout gebeurt, wordt een dialoogvenster op het scherm gebracht. In het laatste geval wordt de gekozen optie doorgestuurd naar de module. Indien het niet de ’cancel’-optie was, wordt alle data doorgestuurd van het gekozen attachment. Daarna wordt de verbinding verbroken en wordt teruggekeerd naar de AttachmentList.

4.2

E-mail module

Voor het ontwikkelen van de e-mail module hebben we (Bart, Koen, Raf en ikzelf) in samenspraak met de begeleiders interfaces afgesproken, opdat we onze modules afzonderlijk van elkaar konden programmeren. Deze interfaces worden hier niet besproken. Ze worden duidelijk aan de hand van de eigen ge¨ımplementeerde klassen. De interfaces zijn te vinden op de CD-ROM bij deze thesis (net als de code en de nodige software voor het uitvoeren van de applicatie). De e-mail client module werd ge¨ımplementeerd in J2SE.

4.2.1

Klassebespreking

MailModule MailModule is de implementatie van de interface ClientModule. De verplichte methodes zijn destroy, getID, setServer en transferSocket. Bij het laden van een ClientModule in de ClientModuleServer (CMS) wordt de methode setServer aangeroepen, zodat de module een pointer bezit naar de CMS (in ons geval ClientModuleServer cms), voor het aanroepen van methodes in de CMS. De methode getID geeft een unieke String terug (ten opzichte van alle andere client

41

modules). Deze String moet door een verbonden client verstuurd worden in zijn service request. Voor de e-mail client module is deze String mail”. De methode transferSocket wordt gebruikt ” om de Socket waarop een client is verbonden met de CMS door te geven aan de module. De destroy methode wordt uiteraard door de CMS opgeroepen wanneer een ClientModule uitgeplugd wordt. De methode finishThread wordt opgeroepen als de client alle info heeft doorgestuurd, om deze uit de LinkedList threads te halen. Het Document cap is de verwerkingsboom die wordt bijgehouden door de module. MailModule bevat ook een ServerListener, waarover later meer. In Figuur 4.12 staat het UML diagram van MailModule afgebeeld.

Figuur 4.12: UML diagram van MailModule

MailThread MailThread is een extensie van de klasse Thread en handelt de aanvraag van één client af in de methode run. Bij constructie krijgt ze de pointers naar de MailModule en de CMS mee en de Socket voor het communiceren met de client. In Figuur 4.13 staat het UML diagram van MailThread afgebeeld. ImapClient ImapClient bevat slechts één statische methode namelijk getFile. De methode staat in voor het afhalen van een attachment van een IMAP server. Bij de codedetails van deze sectie wordt de werking ervan verduidelijkt. In Figuur 4.14 staat het UML diagram van ImapClient afgebeeld.

42

Figuur 4.13: UML diagram van MailThread

Figuur 4.14: UML diagram van ImapClient

XmlCodec XmlCodec neemt de XML operaties voor zijn rekening. De methode buildProcessDoc maakt een XML document voor het aanvragen van een bepaalde service met bepaald attachment van de volgende vorm (waarbij OPTION en FILE de argumenten zijn van de methode): <processingrequest> <request> <module id="OPTION"/> De methode lookupCapabilities zoekt voor een bepaald MIME type in de verwerkingsboom (Document cap in MailModule) de mogelijke opties. In Figuur 4.15 staat het UML diagram van XmlCodec afgebeeld. Base64Decoder Base64Decoder is een aanpassing van de originele klasse Base64EncoderDecoder van [12] tot enkel een decoder. De methode decode zet een array van karakters om naar binaire data. In Figuur 4.16 staat het UML diagram van Base64Decoder afgebeeld.

43

Figuur 4.15: UML diagram van XMLCodec

Figuur 4.16: UML diagram van Base64Decoder

ServerListener ServerListener is een implementatie van de interface ProcessingCapabilityListener. De twee methodes handelen het in- en uitpluggen van verwerkingsmodules af. In de codedetails van deze sectie wordt de werking ervan verduidelijkt. In Figuur 4.17 staat het UML diagram van ServerListener afgebeeld.

Figuur 4.17: UML diagram van ServerListener

4.2.2

Enkele codedetails

ImapClient.java ImapClient is het vitale deel van de e-mail client module. Het downloadt een attachment van een IMAP server. Hiertoe heeft het slechts één statische methode (String host, int port, String username, String password, String fileName, int msgId, int mimePart). Hieronder volgt de code:

44

public static void getFile(String host, int port, String username, String password, String fileName, int msgId, int mimePart) { try { // verbinding met de IMAP server opzetten Socket socket = new Socket(host,port); PrintWriter out = new PrintWriter(socket.getOutputStream(), true); BufferedReader in = new BufferedReader (new InputStreamReader(socket.getInputStream())); // inloggen, mailbox selecteren en body van juiste // MIME deel van de mail downloaden. out.println("a1 LOGIN " + username + " " + password); out.println("a2 SELECT INBOX"); out.println("a3 FETCH " + msgId + " BODY[" + mimePart + "]"); String buffer = in.readLine(); // de inkomende data skippen tot aan "FETCH ..." // daarna nog een lege lijn skippen // hierna begint de nodige data. while (buffer.indexOf("FETCH (BODY["+mimePart+"]")==-1) buffer = in.readLine(); buffer = in.readLine(); String tmp = ""; // in geval we de body (als tekst of html) willen downloaden) if (fileName.equals("BODY (text)") || fileName.equals("BODY (html)")) { PrintWriter fw = null; if (fileName.equals("BODY (text)")) fw = new PrintWriter(new FileWriter("BODY.txt")); else if (fileName.equals("BODY (html)")) fw = new PrintWriter(new FileWriter("BODY.html")); tmp = buffer; buffer = in.readLine(); // downloaden en opslaan tot "a3 OK ..." while (buffer.indexOf("a3 OK FETCH complete")==-1) { fw.println(tmp); tmp = buffer; buffer = in.readLine(); }

45

// op de laatste lijn staat een haakje (IMAP protocol) // als afsluiter. Dit teken moet worden weggelaten. fw.println(tmp.substring(0,tmp.length()-1)); fw.flush(); fw.close(); } // in geval van een attachment moet de data voor het opslaan // nog gedecodeerd worden met de Base64Decoder else { FileOutputStream fw = new FileOutputStream(fileName); while (buffer.indexOf("a3 OK FETCH complete")==-1) { fw.write(Base64Decoder.decode(tmp.toCharArray())); tmp = buffer; buffer = in.readLine(); } fw.write(Base64Decoder.decode(tmp.substring(0,tmp.length()-1).toCharArray())); fw.flush(); fw.close(); } // uitloggen van de IMAP server out.println("a4 CLOSE"); out.println("a5 LOGOUT"); socket.close(); } catch(IOException e) { e.printStackTrace(); } } Eerst wordt er een TCP/IP verbinding tot stand gebracht met de IMAP server en wordt er ingelogd. Dan verzoeken we de IMAP server de body van het MIME deel van een bepaalde mail te versturen. Er wordt een deel info (IMAP protocol) overgeslagen en enkel de nodige data wordt opgeslagen. Indien de body gevraagd was (in tekst of html), dan wordt deze niet gedecodeerd, aangezien enkel attachments in Base64 gecodeerd zijn. ServerListener.java ServerListener wordt bij initialisatie van MailModule geregistreerd bij de CMS. Deze laatste houdt de client module op de hoogte van eventuele wijzigingen in de verwerkingsmogelijkheden.

46

MailModule heeft een statisch Document cap (van capabilities), waar ServerListener dan de nodige wijzigingen op uitvoert. public class ServerListener implements ProcessingCapabilityListener { public ServerListener() {} // indien een nieuwe module wordt ingeladen public void capabilityAdded(Document add) { NodeList nl = add.getChildNodes(); for(int i = 0; i
47

Hoofdstuk 5

Systeem testen 5.1

Overzicht testfases

Na het afspreken van de interfaces kon iedereen aan zijn eigen implementatie beginnen. Het programmeerwerk is in een drietal fases gebeurd. Eerst werd de IMAP client voor het mobiel toestel ontwikkeld. Het testen van deze applicatie gebeurde aanvankelijk met de M50 emulator van Siemens, maar wegens het te kleine scherm met slechts twee kleuren werd uiteindelijk gekozen om de tests verder te zetten met de ’MIDP Concept SDK Beta 0.3.1, Nokia release’ die in het ’Nokia Developers Suite for J2ME’-pakket zit. Toen de IMAP client reeds redelijk vorm begon te krijgen, werd overgegaan naar een volgende fase. Aangezien alle informatie uit de e-mails kon gehaald worden inzake attachments, werd begonnen met de implementatie van de e-mail client module voor het downloaden van deze bestanden. Aangezien deze module echter steunt op een server werd hiervoor een dummy server geschreven die de inkomende verbinding doorgeeft aan de module. In een laatste fase, toen alle componenten in een ver gevorderd stadium van ontwikkeling waren, werden geprobeerd om de code van de e-mail client module en de client module server (en de bijhorende processing modules) samen te laten werken. Het heeft slechts een tweetal uur gekost om het systeem volledig werkende te krijgen. Een beloning voor de goeie afspraken vooraf. In de volgende sectie wordt de opstelling en de resultaten besproken van de demo die werd gegeven voor de promotoren en begeleiders.

48

5.2

Demo

Figuur 5.1 verduidelijkt de opstelling die gebruikt werd voor het geven van de demo. Er zijn twee computers bij de test betrokken. Enerzijds ’PC 1’, waarop de geëmuleerde mobiele applicatie werkt, anderzijds ’PC 2’, waarop Rafs server wordt uitgevoerd. Op de server zijn twee client modules ingeplugd namelijk de e-mail client module en de MMS client module en twee processing modules namelijk de soundmodule voor het afspelen van audio en de printmodule voor het afdrukken. Voor het testen van het e-mail onderdeel werden twee mails gestuurd naar de IMAP server pegasus.atlantis.ugent.be met elke een attachment: een WAV-geluidsbestand en een BMP-afbeelding. De mails werden eerst gedownload met de mobiele client en daarna werden de verwerkingsmogelijkheden van beide attachments opgevraagd. Er werd geprobeerd om het WAV-bestand door de audio module te laten verwerken en de bitmap door de print module. Beide opdrachten zijn geslaagd.

Figuur 5.1: Testopstelling tijdens demo

5.3

Enkel screenshots

In onderstaande figuren zijn enkele screenshots van de e-mail client te zien op de ’MIDP Concept SDK Beta 0.3.1, Nokia release’-emulator. In de inbox (zie Figuur 5.4) zit één mail met als attachment een bitmapafbeelding. In Figuur 5.8 staat de attachmentlijst afgebeeld en in Figuur 5.9 de verwerkingsmogelijkheden voor het bitmapbestand.

49

Figuur 5.2: Screenshot: hoofdmenu

Figuur 5.3: Screenshot: IMAP instellingen

50

Figuur 5.4: Screenshot: inbox

Figuur 5.5: Screenshot: headers van de mail

51

Figuur 5.6: Screenshot: body van de mail

Figuur 5.7: Screenshot: attachments bij de mail

52

Figuur 5.8: Screenshot: attachmentlijst

Figuur 5.9: Screenshot: optielijst bij attachment

53

Hoofdstuk 6

Conclusies In de inleiding werd gesteld dat ondanks de toenemende mogelijkheden op mobiele toestellen toch nog enkele tekortkomingen zijn inzake het verwerken van relatief grote bestanden. Voor het oplossen van dit probleem werd er een modulaire server ontwikkeld door Raf Hens. De verwerkingsmodules maken het mogelijk bestanden op een lokaal netwerk te verwerken (bijv. printen, opslaan, afspelen op audio device) en bepalen eigenlijk de kracht van de server. Via de client modules kunnen mobiele clients dan gebruik maken van deze verwerkingsmodules (bijvoorbeeld via mobiel toestel attachment afprinten). Door het afspreken van de interfaces voor de modules en de communicatie tussen de blokken in XML, wat trouwens een groot deel van de tijd in beslag nam, zijn we erin geslaagd afzonderlijk onze onderdelen te ontwikkelen en deze later samen te doen werken. Dit heeft ons trouwens ook een breder inzicht verschaft over hoe een professioneel project in groep wordt ontwikkeld. Bij de laatste demo bewezen we de werking van ons project.

6.1

Mogelijke uitbreidingen

Er werd bij de aanvang van het thesisjaar beslist dat we geen security zouden gaan inbouwen (zo wordt bijvoorbeeld het paswoord van het IMAP account ongeëncrypteerd over het netwerk verzonden), omdat dit ons te ver van het oorspronkelijk probleem zou leiden. Met bestaande technologieën is het mogelijk volgende aspecten van security in te bouwen: • authenticatie: het vastellen van de identiteit van de gebruiker door bijvoorbeeld gebruikersnaam / paswoord beveiliging, digitale handtekeningen of met een identiteitsticket (Kerberos).

54

• authorisatie: de rechten van een bepaalde gebruiker. De systeembeheerder heeft meer rechten dan een gewone gebruiker • encryptie: het onleesbaar maken van de netwerkcommunicatie (3DES, RSA, PGP,. . . ). Zo kunnen de paswoorden die over het netwerk worden verstuurd niet worden gelezen. • integrity: de verzekering dat een verstuurd bericht onveranderd aan de andere zijde toekomt. • niet-loochening: een gebruiker kan niet ontkennen dat hij een bepaalde service heeft aangevraagd. Als we veronderstellen dat we onze services gaan commercialiseren is authenticatie in de eerste plaats van belang omdat enkel gebruikers die betalen voor een service toegang krijgen tot deze service. Authorisatie is van belang in geval een gebruiker enkel voor de MMS service heeft betaald. Dan mag hij immers geen toegang krijgen tot de e-mail service. Hierbij komt uiteraard ook encryptie van pas voor het versleutelen van de paswoorden. Integriteit moet voorzien worden zodat het bericht om een bepaald e-mail attachment te laten printen niet gewijzigd wordt in het opslaan van dat attachment. Dit kan door bijvoorbeeld een MD5-hash bij het bericht te voegen. Met behulp van tijdsstempels en encryptie kunnen we ons systeem ook wapenen tegen terugspeelaanvallen.

De IMAP client kan beveiligd worden door de IMAP sessie ook over SSL te laten werken.

55

Bibliografie [1] http://java.sun.com/j2me/j2me-ds.pdf [2] http://java.sun.com [3] http://java.sun.com/j2ee/ [4] http://java.sun.com/j2se/ [5] http://java.sun.com/j2me/ [6] http://email.about.com/cs/standards/a/base64 encoding.htm [7] http://www.cs.indiana.edu/docproject/mail/mime.html [8] http://www.ltsw.se/knbase/internet/mime.htp [9] http://www.imap.org [10] Michael Morrison, “Teach Yourself Wireless Java with J2ME in 21 days”, in SAMS, Indianapolis, Indiana, VS Juni 2001. [11] http://mail4me.enhydra.org/index.html [12] http://www.source-code.biz

56

Ontwerp van een mobiele client voor de verwerking van attachments

Recommend Documents