SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

DIPLOMSKI RAD br. 2718

DINAMIČKO PRUŽANJE USLUGA NA

POKRETNIM UREĐAJIMA

Zoran Štrbac

Zagreb, lipanj 2006.

Mentor rada: dr.sc. Ignac Lovrek Voditelj rada: dr.sc. Ignac Lovrek

Sadržaj

Uvod ..............................................................................................................................................1

1. Bežično pružanje usluga – OTA............................................................................................2

1.1. OTA putem WAP-a.......................................................................................................4

1.2. OTA u J2ME okruženju ................................................................................................4

2. Protokol Push-OTA...............................................................................................................5

2.1. Vrste podataka za Push OTA-u .....................................................................................8

3. OTA unutar J2ME okruženja ..............................................................................................10

3.1. Arhitektura pružanja usluga.........................................................................................10

3.2. Profil pokretnog informacijskog uređaja.....................................................................12

3.2.1. Arhitektura visoke razine i MIDP .......................................................................13

3.2.2. Zahtjevi za pokretne informacijske uređaje.........................................................14

3.3. OTA unutar specifikacije MIDP 2.0............................................................................16

3.3.1. Očekivana funkcionalnost uređaja.......................................................................16

3.3.2. Životni ciklus pružanja usluge.............................................................................17

3.3.3. Otkrivanje i odabir aplikacije ..............................................................................18

3.3.4. Instalacija aplikacije ............................................................................................19

3.3.5. Ažuriranje aplikacije............................................................................................21

3.3.6. Izvršavanje aplikacije ..........................................................................................22

3.3.7. Brisanje aplikacije ...............................................................................................22

3.3.8. Promjene u JAD-u za podršku OTA-i .................................................................22

3.3.9. Međusobna suradnja između AMS-a i poslužitelja za pružanje usluga ..............24

4. Lokacijske usluge i OTA.....................................................................................................25

4.1. Vrste lokacijskih usluga ..............................................................................................25

4.1.1. Okidne usluge ......................................................................................................26

4.1.2. Informacijske usluge............................................................................................27

4.1.3. Usluge praćenja treće strane ................................................................................27

4.1.4. Usluge pružanja pomoći korisniku......................................................................28

4.2. Lokacijska tehnologija i lokacijske metode.................................................................28

4.2.1. Identifikacija ćelije ..............................................................................................30

4.2.2. Metoda poboljšanog promatranja vremenske razlike..........................................32

4.2.3. Potpomognuti GPS ..............................................................................................32

4.2.4. Hibridna rješenja..................................................................................................33

4.2.5. Usporedba lokacijskih metoda ............................................................................33

5. Usluga pružanja lokacijski zavisnih informacija pokretnom korisniku uz pomoć OTA-e .35

5.1. Analiza problema i predložena rješenja.......................................................................35

5.1.1. Otkrivanje, preuzimanje i instalacija aplikacije ..................................................35

5.1.2. Određivanje lokacije korisnika............................................................................36

5.1.3. Obrada lokacije i dohvat odgovora na poslužitelju .............................................36

5.1.4. Komunikacija između aplikacije i poslužitelja....................................................37

5.2. Izvori informacija za lokacijsku uslugu.......................................................................37

5.3. Arhitektura usluge .......................................................................................................38

5.4. Funkcionalnost OTA poslužitelja................................................................................39

5.5. Funkcionalnost klijentske aplikacije ...........................................................................39

5.6. Funkcionalnost poslužiteljske aplikacije .....................................................................41

6. Opis programskog rješenja usluge.......................................................................................42

6.1. Opis rješenja klijentske aplikacije ...............................................................................42

6.1.1. Klasa KlijentPumpa.............................................................................................43

6.1.2. Klasa Find............................................................................................................44

6.2. Opis rješenja poslužiteljske aplikacije.........................................................................45

6.2.1. Klasa PosluziteljPumpa .......................................................................................46

6.2.2. Klasa Worker.......................................................................................................46

6.3. Opis rješenja OTA poslužitelja....................................................................................47

6.3.1. Konfiguriranje Apache web poslužitelja za OTA-u ............................................47

6.4. Preuzimanje, pokretanje i rad s aplikacijom................................................................48

6.4.1. Preuzimanje aplikacije.........................................................................................48

6.4.2. Pokretanje poslužiteljske aplikacije ....................................................................50

6.4.3. Pokretanje klijentske aplikacije i demonstracija usluge ......................................50

7. Poslovni aspekti lokacijskih usluga.....................................................................................56

Zaključak .....................................................................................................................................60

Literatura .....................................................................................................................................61

1

Uvod

Porastom broja korisnika pokretnih uređaja u zadnjih nekoliko godina i razvojem samih

pokretnih uređaja u pogledu procesorske snage, potrošnje energije, prikaza te veličine

memorije, otvorile su se mogućnosti i stvorili poticaji za kreiranje novih vrsta usluga. Jedne

od novonastalih usluga su lokacijske usluge i bežično pružanje usluga korisniku. Ove dvije

vrste usluga moguće je međusobno povezati kako bi se korisniku putem jedne usluge olakšalo

korištenje druge usluge.

Zadatak diplomskog rada je istražiti i implementirati bežično pružanje usluga korisniku,

proučiti lokacijske usluge i metode te razviti lokacijsku informacijsku uslugu čije će

korištenje korisniku biti omogućeno uz pomoć bežičnog pružanja usluga. Prilikom

istraživanja posebna je pozornost obraćena na otkrivanje, odabir, preuzimanje i instalaciju

aplikacije na pokretni uređaj. U prvom poglavlju dan je svojevrstan uvod u problem bežičnog

pružanja usluga. Ostvarenje bežičnog pružanja usluga korištenjem push komunikacije opisano

je u drugom poglavlju kroz prikaz protokola Push OTA. Treće poglavlje nas upoznaje s

bežičnim pružanjem usluga unutar Java okruženja za male uređaje i profila pokretnog

informacijskog uređaja, te pruža detaljan opis već spomenutog postupka tog načina pružanja

usluga. Pregled lokacijskih usluga te opis metoda lociranja korisnika, koje se koriste pri

ostvarivanju takvih usluga, dan je u četvrtom poglavlju. U petom poglavlju opisana je

ostvarena lokacijska usluga kroz podrobnu analizu problema, prikaz predloženih rješenja te

konačnu arhitekturu i funkcionalnost same usluge. Opis programskog rješenja i korištenje

same usluge dano je u šestom poglavlju dok su u sedmom poglavlju ukratko prikazani

poslovni aspekti lokacijskih usluga.

2

1. Bežično pružanje usluga – OTA

Razvojem pokretnih mreža i samih uređaja koji se u njima koriste, pružena je podrška za nove

načine njihove primjene. Jedna od tehnologija je i bežično pružanje usluga (engl. Over The

Air Provisioning, skraćeno OTA) koje se odvija u dinamičkom okruženju. Pojam dinamičkog

okruženja ovdje se odnosi na vrijeme, lokaciju i širinu primjene. Glavna ideja OTA-e odnosi

se na to da korisnik, nakon što nabavi uređaj, ne mora ponovno ići operateru kako bi na njemu

omogućio korištenje novih usluga, već da to može napraviti putem bežičnog prijenosa tj.

putem OTA-e. OTA je dakle mogućnost preuzimanja i instalacije usluge ili nekog sadržaja

putem bežične mreže, najčešće na zahtjev korisnika.

Ostvarenje pružanja usluga putem OTA-e može biti izvedeno na više načina. Jedan od

najčešćih slučajeva uporabe OTA-e u današnje vrijeme je konfiguracija WAP (Wireless

Application Protocol) ili MMS (Multimedia Messaging Service) postavki na korisničkim

uređajima tako što ih operater šalje korisniku putem SMS (Short Message Service) poruke.

Korisnički zahtjev uključuje pozivanje centra za korisničku podršku gdje korisnik osobno

zahtjeva slanje točno određenih postavki za neku telekomunikacijsku uslugu od operatera.

Operater zatim inicira push komunikaciju putem OTA-e preko SMS-a i šalje postavke

korisniku [5]. Korisnik po primitku poruke s postavkama za konfiguraciju odobrava

instalaciju te je time njegova usluga omogućena. Primjer za ovaj slučaj korištenja OTA-e

prikazan je na slici (Sl. 1.1).

Sl. 1.1 Prikaz konfiguracije postavki OTA-om preko SMS-a

3

Drugi slučaj uporabe pružanja usluga putem tehnologije OTA je još uvijek malo korišten, ali

u zadnje vrijeme se sve više primjenjuje, naročito u području igara za pokretne uređaje i

lokacijskih usluga. Ideja u ovom slučaju uporabe je da korisnik sam, putem aplikacije za

otkrivanje sadržaja (engl. Discovery Application, skraćeno DA), pronađe uslugu ili aplikaciju

koja ga zanima te njenim odabirom pokrene instalaciju iste korištenjem OTA-e [1]. Na slici

(Sl. 1.2) možemo vidjeti jednostavan prikaz arhitekture OTA za ovaj način pružanja usluga.

Sl. 1.2 Jednostavan prikaz OTA arhitekture

Primjećujemo slijedeće dijelove arhitekture za ostvarivanje funkcionalnosti OTA:

• Klijentski uređaj s aplikacijom za otkrivanje sadržaja – Klijentski uređaj mora

imati programsku podršku (engl. software) koji korisniku omogućuje lociranje

aplikacija na određenom poslužitelju za pružanje usluge u mreži i mogućnost odabira

koje će aplikacije preuzeti. Ovaj software se naziva aplikacija za otkrivanje sadržaja tj.

već spomenuti DA. DA može biti temeljena na web pregledniku ili zasebna, ali je

važno da koristi isti protokol za pružanje usluge kao i poslužitelj.

• Mreža – Ovo podrazumijeva bilo koju odgovarajuću bežičnu mrežu. Najčešće se za

prijenos koristi GPRS ili GSM mreža, a u novije vrijeme i UMTS i EDGE.

• Poslužitelj za preuzimanje (download) sadržaja (Provisioning Portal) – Ovaj dio

arhitekture se još naziva i portal za pružanje usluge, poslužitelj ili uređaj za

distribuciju. On je glavno računalo, vidljivo u mreži, na kojem je obično pokrenut web

poslužitelj i koji ima pristup spremniku sadržaja. Ima dvije glavne funkcije: osigurava

pravilno oblikovane izbornike, često napisane u WML-u ili HTML-u, koji ispisuju

aplikacije koje je moguće preuzeti i pružaju pristup aplikacijama. Jedan poslužitelj za

preuzimanje sadržaja može podržavati jedan ili više OTA protokola.

4

• Spremnik sadržaja (Content Repository) – Kao što i samo ime govori, ovo je

spremnik u kojem se nalaze sve aplikacije i opisnici aplikacija koje je moguće

preuzeti.

Sa slike možemo i vidjeti sam tok pružanja usluge i podijeliti ga u tri glavna dijela. To su:

otkrivanje sadržaja, odabir sadržaja te preuzimanje i instalacija odabranog sadržaja.

Pružanje usluga putem OTA-e danas se najčešće izvodi na 2 načina tj. korištenjem dviju

tehnologija. To su OTA putem WAP-a i OTA u Java okruženju, preciznije u J2ME (Java 2

Platform, Micro Edition) okruženju.

1.1. OTA putem WAP-a

Pružanje usluga OTA-om unutar protokola WAP ostvareno je posebnim protokolom Push-

OTA koji se nalazi unutar WAP protokolnog složaja u sloju usluga sjednice (engl. Session

Services). Ostali dijelovi bitni za podršku OTA-i unutar WAP-a su još provisioning usluga u

sloju otkrivanja usluge (engl. Service Discovery), usluga autentifikacije u sloju sigurnosnih

usluga (Security Services) i push usluga u aplikacijskoj okosnici (engl. Application

Framework). Tri osnovne strane u pružanju usluga Push-OTA-om su inicijator push-a (engl.

Push Initiator, skraćeno PI), push proxy prilaz (engl. Push Proxy Gateway, skraćeno PPG) i

WAP klijent.

1.2. OTA u J2ME okruženju

Pružanje usluga korištenjem OTA-e u J2ME okruženju je prvenstveno povezano s profilom

pokretnog informacijskog uređaja (engl. Mobile Information Device Profile, skraćeno MIDP).

MIDP je dosad imao dvije verzije: MIDP 1.0 i aktualni MIDP 2.0. OTA je sastavni dio MIDP

2.0 dok je u MIDP 1.0 bio samo preporuka. U J2ME okruženju pružanje usluga putem OTA-e

odnosi se prvenstveno na otkrivanje, odabir, preuzimanje, instalaciju i korištenje MIDP

aplikacija koje inače nazivamo MIDlet-ima. To su aplikacije koje su posebno prilagođene za

pokretne uređaje koji podržavaju Java tehnologiju tj. koje su u skladu s MIDP-om. MIDlet-

ima je moguće ostvarivanje brojnih usluga za korisnike, kao recimo lokacijskih usluga, a isto

tako moguće im je ponuditi i zabavu kroz igre napravljene u J2ME okruženju.

5

2. Protokol Push-OTA

Protokol Push-OTA je dio okosnice Push koji je odgovoran za prijenos sadržaja od push

proxy prilaza (engl. Push Proxy Gateway, skraćeno PPG) do klijenta i njegovih korisničkih

agenata.

Na slici (Sl. 2.1) vidimo da u komunikaciji Push OTA postoje tri strane i to inicijator push-a,

PPG i WAP klijent. PI je taj koji pokreće push komunikaciju. On komunicira s PPG-om

putem protokola za pristup push-u (engl. Push Access Protocol, skraćeno PAP), a PPG nakon

prilagodbe primljenih podataka te iste prosljeđuje WAP klijentu putem Push OTA-e [3].

Sl. 2.1 Prikaz Push OTA komponenata i odnosa među njima

PI je najčešće aplikacija koja je pokrenuta na nekom tipičnom web poslužitelju i koja šalje

push sadržaj i informacije o isporuci PPG-u. Na slici su PPG i PI prikazani kao odvojeni

entiteti, što najčešće i je slučaj, ali isto tako mogu i biti na jednom mjestu.

Protokol PAP je sredstvo kojim PI šalje sadržaj prema pokretnoj mreži adresirajući njen PPG.

PAP je izveden tako da bude neovisan o transportnom protokolu koji se nalazi na nižoj razini

pa tako može biti prenesen svakim protokolom koji dopušta transport MIME tipova preko

Interneta. PAP podržava sljedeće operacije:

• Slanje push sadržaja (PI prema PPG)

• Obavijest o rezultatu (PPG prema PI)

• Odustajanje od slanja (PI prema PPG)

• Zamjena push sadržaja (PI prema PPG)

• Upit o statusu (PI prema PPG)

• Upit o mogućnostima klijenta (PI prema PPG)

6

Push poruka sastoji se od tri entiteta: kontrolnog entiteta, sadržajnog entiteta, i opcionalnog

entiteta za posebne mogućnosti. Kontrolni entitet je XML dokument koji sadrži upute o

isporuci namijenjene PPG-u, a sadržajni entitet je namijenjen klijentu.

PPG obavlja funkciju pristupne točke za slanje sadržaja s Interneta na pokretnu mrežu te sve

funkcije koje idu uz to, kao što su autentifikacija, rezolucija adresa i slično. PPG pruža

okosnici Push razne usluge kao:

• Identifikaciju i autentifikaciju PI-a, te kontrolu pristupa

• Analizu sintakse (engl. parsing) i detekciju pogrešaka u push sadržaju i kontrolnoj

informaciji

• Usluge pronalaska klijenta, uključujući pronalazak klijentovih mogućnosti

• Rezolucija adrese primatelja push sadržaja

• Binarno kodiranje i kompilacija određenih tipova sadržaja, ili općenito sažimanje, u

svrhu poboljšanja efikasnosti OTA-e

• Konverzija protokola

Nakon što PPG primi sadržaj od PI-a putem PAP-a, on ga dijeli na nekoliko dijelova ovisno o

namjeni. Za PPG je najvažniji prvi dio u kojem se nalazi kontrolna informacija za njega

samog. Ta informacija sadrži primateljevu adresu, ograničenja vremena isporuke, informaciju

o kvaliteti usluge (engl. Quality of Service, skraćeno QoS), zahtjeve za obavijestima itd.

Nakon što je sadržaj odobren za isporuku, PPG pokušava pronaći pravog klijenta i isporučiti

sadržaj tom klijentu koristeći Push-OTA-u.

Push OTA je dizajniran tako da radi na vrhu HTTP (engl. HyperText Transport Protocol)

protokola ili WSP (engl. Wireless Session Protocol) protokola. Prva varijanta naziva se još i

OTA-HTTP, a druga OTA-WSP. Dijelovi OTA-WSP-a koji se odnose na beskonekcijski

push moraju uvijek biti izvedeni i u PPG-u i u klijentima. Konekcijski-orijentiran push, koji

koristi ili OTA-HTTP, ili OTA-WSP, je opcionalan.

Protokolna varijanta OTA-WSP je arhitekturno tanki protokolni sloj na vrhu WSP-a i može

stoga biti korišten u kombinaciji s bilo kojom vrstom prijenosa spomenutom u specifikaciji

WAP. OTA-WSP koristi osobine ponuđene od WSP-a i proširuje iste kako bi udovoljila

7

posebnim potrebama push-a. Naprimjer, OTA-WSP se oslanja na WSP-ovu sposobnost

pregovaranja o mogućnostima, vjerojatno koristeći UAProf, i pruža i beskonekcijske

(nepotvrđeni push) i konekcijski orijentirane push (potvrđeni i nepotvrđeni push) usluge.

Protokolna varijanta OTA-HTTP koristi HTTP za OTA komunikaciju između PPG-a i

klijenta i stoga je primarno korištena u zajednici s IP nosiocima. HTTP varijanta pruža jedino

konekcijski orijentirani push. Push sadržaj se isporučuje putem metode HTTP POST,

implicirajući da se PPG ponaša kao HTTP klijent, a WAP klijent kao HTTP poslužitelj. Da bi

se izbjegla zabuna, WAP klijent se stoga naziva terminalom kad se raspravlja o OTA-HTTP-

u.

Push OTA definira dvije metode za uspostavljanje aktivne TCP (engl. Transmission Control

Protocol) konekcije. Metode su PO-TCP (PPG Originated TCP) i TO-TCP (Terminal

Originated TCP). PO-TCP omogućuje uspostavljanje aktivne TCP konekcije kada je

prijenosna veza aktivna (ili može biti aktivirana od strane PPG-a) i kada je IP (Internet

Protocol) adresa terminala poznata PPG-u. TO-TCP metoda se bavi drugim slučajevima i

obično se koristi u kombinaciji sa SIR (engl. Session Initiation Request) mehanizmom .

Koristeći koncept (dugotrajnih) sjednica, OTA-WSP pruža načine na koje klijent može

priopćiti svoje mogućnosti PPG-u. U OTA-HTTP-u terminal se registrira kod PPG-a kako bi

ostvario sličnu funkcionalnost. To se ostvaruje tako da PPG šalje terminalu zahtjev HTTP

OPTIONS gdje terminal u odgovoru šalje CPI (Capability and Preference Information) tj.

informacije o mogućnostima i postavkama. Postoji i mehanizam koji sprječava slanje te

informacije kada je ona već poznata PPG-u kako bi se poboljšala efikasnost OTA-e. OTA

HTTP također pruža načine za identifikaciju i moguću autentifikaciju terminala i PPG-a.

Neovisno o tome koristi li se OTA-WSP ili OTA-HTTP, često je potrebno da klijent inicira

komunikaciju. SIA (engl. Session Initiation Application) je aplikacija za pokretanje sjednice i

nalazi se na strani klijenta, a namijenjena je upravo u svrhu iniciranja komunikacije od

klijenta. SIA osluškuje i čeka SIR od PPG-a, a odgovara aktivacijom odgovarajućeg nosioca i

kontaktiranjem željenog PPG-a.

Kad se koristi OTA-WSP, uvijek je na klijentu da preuzme inicijativu uspostavljanja WSP

sjednice. PPG šalje SIR klijentu kad želi uspostaviti WSP sjednicu za push. Nakon što klijent

8

primi SIR, on aktivira nosioca specificiranog u SIR-u i uspostavlja WSP sesiju prema

naznačenom PPG-u preko tog nosioca.

SIR mehanizam se koristi i zajedno s OTA-HTTP-om, naročito onda kad IP adresa klijenta

nije poznata PPG-u i/ili kad PPG ne može aktivirati željenog nosioca. U tom slučaju SIR

upućuje klijenta da aktivira određenog nosioca i uspostavi aktivnu TCP vezu prema PPG-u

naznačenom u SIR-u (koristeći TO-TCP metodu).

SIR se obično šalje klijentu korištenjem beskonekcijskog push-a (podržanog od OTA-WSP)

koji je neovisan o tome da li će klijent koristiti OTA-WSP ili OTA-HTTP kad poslije

kontaktira PPG. Pažnja je naročito posvećena tome da SIR bude dovoljno kompaktan kako bi

stao unutar jedne SMS poruke u normalnom slučaju jer SMS pruža načine na koje se može

koristiti dobro poznata adresa klijenta (MSIDSN – Mobile Station International Subscriber

Directory Number) i sigurnost na transportnom sloju.

2.1. Vrste podataka za Push OTA-u

Okosnica WAP push dopušta prijenos bilo koje MIME (engl. Multipurpose Internet Mail

Extensions) vrste podataka između PI-a i klijenta. Vrste podataka opisane u ovom dijelu su

stvorene kako bi se dodale mogućnosti koje nisu već omogućene od postojećih MIME vrsta

podataka. Kako bi se zadovoljile potrebe određenih aplikacija (npr. MMS, WTA, pružanje

usluga), druge vrste podataka sa posebnom push semantikom su definirane od strane WAP-a.

Vrsta podataka SI (Service Indication) pruža mogućnost slanja obavijesti krajnjim

korisnicima asinkronim putem. Takve obavijesti mogu biti, naprimjer, primitak novog e-mail-

a, promjena cijena dionica, novinski naslovi, oglasi, podsjetnici itd. U najosnovnijem obliku,

SI sadrži kratku poruku i URI koji označava uslugu. Poruka se prezentira korisniku po

primitku i korisniku se daje na odabir da uslugu naznačenu URI-jem odmah aktivira ili da

odgodi odluku o SI za kasnije. Ako se SI odgodi, klijent ga pohranjuje i krajnjem korisniku se

daje mogućnost da djeluje na njega kasnije.

Vrsta podataka SL (Service Loading), za razliku od SI, ne uključuje nikakvo uplitanje

korisnika. SL sadrži URI koji pokazuje na neki sadržaj kojeg klijent preuzima bez odobrenja

9

krajnjeg korisnika, i uputu da li sadržaj treba pokrenuti, obraditi ili spremiti u priručnu

memoriju (engl. cache). Ako sadržaj treba pokrenuti ili obraditi, PI može odrediti određenu

razinu uplitanja od strane korisnika.

Vrsta podataka CO (Cache Operation) pruža načine poništavanja određenih objekata ili svih

objekata koji dijele isti URI prefiks u klijentskoj cache memoriji. Ova mogućnost je korisna u

situacijama kada se ne može odrediti istek vrijednosti sadržaja u cache memoriji i kad se

sadržaj mijenja češće nego što mu korisnik pristupa.

10

3. OTA unutar J2ME okruženja

Kao što smo već ranije spomenuli, tehnologija OTA unutar J2ME okruženja temelji se na

specifikaciji MIDP 2.0 koja definira mehanizme i daje sučelja za podršku over-the-air

pružanja usluga. Isto tako, kad govorimo o pružanju usluge OTA-om u J2ME okruženju

najčešće mislimo na pronalazak i preuzimanje željenih J2ME aplikacija tj. MIDlet-a, kako ih

inače nazivamo u ovom okruženju. U prvom smo poglavlju već prikazali jednostavni prikaz

arhitekture OTA koja omogućava pružanje usluga OTA-om, a sad ćemo malo detaljnije

pogledati tu arhitekturu i njene dijelove.

3.1. Arhitektura pružanja usluga

Sustav za pružanje usluga OTA-om obično obuhvaća objavljivanje i upravljanje sadržajem,

instalaciju i ažuriranje aplikacija te praćenje uporabe aplikacija (sadržaja) u svrhu naplate. Na

slici (Sl. 3.1) možemo vidjeti te funkcijske dijelove.

Sl. 3.1 Detaljni prikaz arhitekture OTA

11

Kao što vidimo, procesi u pozadini su više uključeni, nego što to korisnik vidi pa tako

uočavamo:

• upravljanje sadržajem (engl. Content Management) – Ovo je software na

poslužiteljskoj strani koji upravlja spremnikom, obično bazom podataka, i podržava

razvrstavanje sadržaja, načine na koje treća strana može dodati svoje aplikacije itd.

Neki operateri zahtijevaju da aplikacije budu certificirane prije nego što budu

dostupne za OTA-u.

• otkrivanje sadržaja (engl. Content Discovery) – Kao što smo već vidjeli, korisnik

upućuje DA na poslužitelj za pružanje usluge koji pristupa spremniku aplikacija i

omogućava pravilno oblikovane izbornike raspoloživih aplikacija i sadržaja.

• autentifikaciju – Ako poslužitelj za pružanje usluge podržava autentifikacijski modul,

korisnik se autentificira prije nego što dobije pristup spremniku.

• preuzimanje aplikacije i instalaciju – Jednom kad je autentifikacija završena,

počinje preuzimanje sadržaja koje se izvodi u dva dijela i kojim upravlja sustav za

upravljanje aplikacijama (engl. Application Management System, skraćeno AMS) tj.

software u pokretnom uređaju koji upravlja preuzimanjem sadržaja, izvršavanjem i

brisanjem aplikacija te ostalim resursima unutar uređaja. Ako postoji opisnik

aplikacije u obliku Java opisnika aplikacije (engl. Java Application Descriptor,

skraćeno JAD), AMS ga preuzima iz spremnika poslužitelja za pružanje usluga. Na

osnovi informacije pronađene iz preuzetog opisnika, AMS automatski preuzima

aplikaciju (MIDlet suite JAR dokument) iz spremnika. Ako je potrebno, korisnik se

ponovno autentificira. Ako je aplikacija uspješno prenesena, automatski se instalira.

• potvrda – AMS šalje potvrdu o statusu kako bi naznačio je li prijenos uspio ili nije.

• praćenje – Potvrda o statusu može se koristiti za praćenje korištenja aplikacije,

naprimjer u svrhu naplate. Sustav naplate je obično integriran unutar poslužitelja za

pružanje usluge.

Kao dodatak osnovnim obilježjima opisanim gore, neki OTA poslužitelji za pružanje usluga

pružaju slijedeće funkcionalnosti:

• personalizaciju – mogućnost ponude određenih aplikacija ovisno o postavkama

svakog korisnika,

• klasifikaciju temeljenu na uređajima – ponuda se ograničava samo na one

aplikacije koje se mogu izvoditi na korisnikovom uređaju,

12

• sigurnost – stroga autentifikacija korisnika i kontrola pristupa,

• upozorenja – obavijesti korisnicima da postoje nove aplikacije koje zadovoljavaju

njihove postavke.

3.2. Profil pokretnog informacijskog uređaja

Profil pokretnog informacijskog uređaja (engl. Mobile Information Device Profile, skraćeno

MIDP) je ključni element J2ME platforme. U kombinaciji s CLDC-om (Connected Limited

Device Configuration), MIDP pruža standardnu Java izvršnu okolinu za današnje

najpopularnije pokretne informacijske uređaje, kao naprimjer pokretne telefone i osobne

digitalne pomoćnike (engl. Personal Digital Assistant, skraćeno PDA). Specifikacija MIDP,

definirana kroz JCP (Java Community Process), definira platformu za dinamičku i sigurnu

isporuku optimiziranih, grafičkih, mrežnih aplikacija. CLDC i MIDP pružaju jezgrenu

aplikacijsku funkcionalnost zahtjevanu od pokretnih aplikacija u obliku standardizirane Java

izvršne okoline i bogatog skupa Java API-ja (Application Program Interface) kako bi se

omogućila otvorena okolina za razvoj aplikacija od treće strane za pokretne informacijske

uređaje (engl. Mobile Information Device, skraćeno MID). Ljudi koji razvijaju aplikacije ne

moraju ih pisati više puta za razne uređaje, već ih napišu jednom i brzo ih isporučuju širokoj

lepezi različitih pokretnih uređaja. MIDP je stoga široko prihvaćena platforma za pokretne

aplikacije.

Dosad su objavljene dvije verzije MIDP-a, to su MIDP 1.0 i MIDP 2.0. MIDP 1.0 je

originalna specifikacija koja pruža jezgrenu aplikacijsku funkcionalnost za pokretne

aplikacije, uključujući osnovno korisničko sučelje i mrežnu sigurnost. MIDP 2.0 je revidirana

verzija specifikacije MIDP 1.0. Nove mogućnosti uključuju poboljšano korisničko sučelje,

proširenu povezivost, višemedijsku i zabavnu (igre) funkcionalnost, pružanje usluga OTA, i

sigurnost s kraja na kraj. MIDP 2.0 je kompatibilan s MIDP 1.0 i također je usmjeren na

uređaje kao što su pokretni telefoni i PDA-ovi.

Pokretni informacijski uređaji, MID-ovi, obuhvaćaju potencijalno jako široki skup

mogućnosti. Umjesto da se pokušaju uhvatiti u koštac sa svim tim mogućnostima, razvojni

tim za MIDP je odlučio ograničiti skup API-ja samo na one iz onih funkcijskih skupina za

13

koje se smatra kako predstavljaju apsolutnu nužnost kako bi se ostvarila široka portabilnost i

uspješna isporuka [2]. Ovo uključuje:

• isporuku i naplatu aplikacija

• životni ciklus aplikacije

• model za verificiranje aplikacije i sigurnosni model za privilegirane domene

• transakcijsku sigurnost s kraja na kraj (HTTPS)

• MIDlet push registraciju

• mrežnu povezanost

• trajnu pohranu

• zvuk

• mjerače vremena (engl. timer)

• korisničko sučelje

3.2.1. Arhitektura visoke razine i MIDP

Pogledajmo arhitekturu visoke razine, prikazanu na slici (Sl. 3.2), i gdje se MIDP nalazi

unutar nje. Prije nego objasnimo pojedine dijelove arhitekture, treba napomenuti kako neće

svi uređaji koji implementiraju specifikaciju MIDP imati sve elemente prikazane na ovoj slici,

niti će njihova programska podrška biti ovako posložena po slojevima.

Sl. 3.2 Prikaz arhitekture visoke razine

14

U arhitekturi visoke razine, blok na najnižoj razini (MID) predstavlja sklopovlje (engl.

hardware) pokretnog informacijskog uređaja. Iznad tog hardware-a nalazi se sistemski

software uređaja i to je sloj u kojem se nalaze njegove biblioteke i operacijski sustav. Na

sljedećoj razini, gledajući slijeva nadesno, nalazi se CLDC. Ovaj blok predstavlja virtualni

stroj (engl. Virtual Machine, skraćeno VM) tj. virtualni stroj i pripadne povezne biblioteke

definirane CLDC specifikacijom te također pruža podslojnu Java funkcionalnost na koju se

mogu nadograđivati Java API-ji više razine.

Dvije kategorije API-ja su prikazane iznad CLDC-a:

• MIDP API-ji - skup API-ja definiran specifikacijom MIDP i

• API-ji specifični za OEM (engl. Original Equipment Manufacturer) tj.

proizvođača - moguće je da ove aplikacije nisu prenosive na druge MID-ove.

Blokovi na najvišoj razini predstavljaju tipove aplikacija koje su moguće na MID-u. Tako

imamo sljedeće tipove aplikacija:

• MIDP aplikacije – Ove aplikacije se zapravo već spomenuti MIDleti i koriste API-je

definirane specifikacijama MIDP i CLDC. Ova vrsta aplikacije je u središtu

specifikacije MIDP i očekuje se da bude najčešća vrsta aplikacije na MID-u.

• Aplikacije specifične za OEM – Ove aplikacije ovise o klasama koje nisu dio

specifikacije MIDP i nisu prenosive između MID-ova.

• Aplikacije uređaja – Ove aplikacije nisu napisane u Javi i izgrađene su iznad

postojećeg MID-ovog sistemskog software-a.

3.2.2. Zahtjevi za pokretne informacijske uređaje

Zahtjevi koje ćemo ovdje navesti su zapravo dodatni zahtjevi uz one koji su već navedeni u

specifikaciji CLDC. Na visokoj razini, MIDP specifikacija pretpostavlja da je MID ograničen

u jačini procesora, memoriji, povezivosti i veličini prikaza.

Zahtjevi koji se odnose na hardware su:

Prikaz:

• Veličina ekrana: 96 x 54

• Dubina prikaza: 1 bit

• Oblik pixela: omjer otprilike 1:1

15

Unos:

• Jedan ili više sljedećih mehanizama: jednoručna tipkovnica, dvoručna tipkovnica ili

ekran na dodir

Memorija:

• 256 KB postojane memorije za MIDP implementaciju, više nego što je zahtjevano

CLDC-om

• 8 KB postojane memorije za perzistentne podatke kreirane od aplikacije

• 128 KB nepostojane memorije za Java izvršnu okolinu

Mrežna povezivost:

• Dvosmjerna, bežična, po mogućnosti nekontinuirana, s ograničenom brzinom

Zvuk:

• Mogućnost reprodukcije tonova, ili preko dodijeljenog hardware-a, ili preko

programskog algoritma

Zahtjevi koji se odnose na software su:

• Minimalna jezgra (engl. kernel) za upravljanje hardware-om (npr. rad s prekidima,

iznimkama itd.)

• Mehanizam za čitanje i pisanje u postojanu memoriju kako bi se zadovoljili zahtjevi

RMS (engl. Record Management System) API-ja za trajnu pohranu

• Pristup za čitanje i pisanje bežičnoj mrežnoj komponenti uređaja kao podrška za

mrežne API-je

• Mehanizam koji će pružiti temelj za uporabu vremena u vremenskom označavanju

podataka upisanih u spremnik podataka (engl. Record Storage) i za API-je koji se

odnose na timer-e.

• Minimalnu sposobnost pisanja na bit-mapirani grafički prikaz

• Mehanizam za registriranje korisničkog unosa iz jednog (ili više) od 3 ulazna

mehanizma spomenuta ranije

• Mehanizam za upravljanje životnim ciklusom aplikacije

Konačne implementacije uređaja koje su kompatibilne s specifikacijom MIDP moraju

zadovoljavati niz zahtjeva koje mi sad nećemo sve nabrajati, već ćemo samo navesti neke od

njih koje su najzanimljivije. Dakle, MIDP uređaji moraju:

• podržavati MIDP 1.0 i MIDP 2.0 MIDlete i skupine MIDleta (MIDlet Suites)

16

• sadržavati sve pakete, klase i sučelja definirana u MIDP-u

• implementirati pružanje usluga OTA-om na zahtjev korisnika

• pružiti podršku za pristup HTTP 1.1 poslužiteljima i uslugama, bilo direktno, bilo

preko spojnog pristupa

• podržavati generiranje tonova u medijskom paketu

• podržavati SP-MIDI (Scalable Polyphony MIDI)

• podržavati bar UTF-8 kodiranje znakova za API-je koji dozvoljavaju aplikacijama

definiranje kodiranja znakova

3.3. OTA unutar specifikacije MIDP 2.0

Specifikacija MIDP OTA definira kako MIDP uređaji surađuju s poslužiteljima za pružanje

usluga, uključujući i to kako preuzimaju (engl. download) aplikacije. Ona definira OTA

proces pokrenut od korisnika, a ne mehanizam push OTA koji pokreće poslužitelj. OTA je u

specifikaciji MIDP 1.0 bila samo preporučena praksa, a u MIDP 2.0 ona je unaprijeđena i

postala je obavezna. S obzirom da je sada dio standarda, sve slijedeće verzije MIDP-a će

podržavati OTA-u na konzistentan i standardan način. Dvije verzije OTA-e su vrlo slične, ali

postoje neke razlike, kao naprimjer novo svojstvo JAD-a koje koristi AMS kako bi izvjestio

da je MIDlet suite obrisan ili striktnije provjeravanje kod ažuriranja MIDlet-a. Korištenje

cookie-sa je također zamijenjeno ponovnim pisanjem URL-a.

Specifikacija MIDP OTA se može podijeliti na sljedeća područja interesa:

• očekivanu funkcionalnost uređaja (kao podrška za OTA-u)

• životni ciklus OTA aplikacije

• promjene u JAD-u za podršku OTA-i

• međusobnu suradnju između AMS-a i poslužitelja za pružanje usluga

3.3.1. Očekivana funkcionalnost uređaja

Kako bi mogao podržavati OTA-u, uređaj kompatibilan s MIDP-om mora biti sposoban za:

• Pregledavanje sadržaja ili neki drugi način lociranja opisnika MIDlet suite aplikacija u

mreži

17

• Prijenos MIDlet suite-a i njegovog pripadnog aplikacijskog opisnika (engl.

Application Descriptor, skraćeno AD) od poslužitelja do pokretnog uređaja koristeći

HTTP 1.1 ili drugi protokol sjednice koji implementira funkcionalnost HTTP 1.1

• Odgovaranje na odgovore 401 (Unauthorized) i 407 (Proxy Authentication Required),

primljene nakon HTTP zahtjeva, tako što će od korisnika zatražiti korisničko ime i

lozinku i ponovno poslati HTTP zahtjev s uključenim podacima za provjeru identiteta

• Instaliranje MIDlet suite-a na uređaj

• Pozivanje MIDlet-a

• Dopuštanje korisniku da obriše MIDlet suite koji je pohranjen na njegovom uređaju.

Samo jedan MIDlet ne može se obrisati jer je jedinica prijenosa MIDlet suite.

3.3.2. Životni ciklus pružanja usluge

Na slici (Sl. 3.3) je prikazan kompletni životni ciklus OTA aplikacije. Uočavamo da se

životni ciklus sastoji od 5 dijelova. To su otkrivanje aplikacije, preuzimanje aplikacije i

instalacija, pokretanje aplikacije, ažuriranje aplikacije i brisanje aplikacije.

Sl. 3.3 Životni ciklus OTA aplikacije

Sve počinje kad korisnik da naredbu pokretnom uređaju, koristeći DA, da traži željenu

aplikaciju na određenom portalu za pružanje usluga u mreži. Nakon što pronađe aplikaciju,

korisnik je odabire za preuzimanje i instalaciju. Nakon uspješne instalacije, aplikacija se može

pokrenuti, ažurirati ili obrisati s uređaja. Svim ovim koracima upravlja AMS.

18

3.3.3. Otkrivanje i odabir aplikacije

Kao što je već rečeno, otkrivanje aplikacije je proces u kojem korisnik locira MIDlet suite

koristeći svoj uređaj. Otkrivanje aplikacije pokrenuto od korisnika i instalacija MIDlet suite-a

mora biti podržana na slijedeći način:

• Za vrijeme korištenja DA, korisniku se nudi veza (engl. link) na MIDlet suite ili na

opisnik aplikacije

• Korisnik odabire jedan od ponuđenih link-ova kako bi pokrenuo proces instalacije

• Ako postoji opisnik aplikacije, on se prvi prenosi na uređaj. Ovaj opisnik sadrži

informaciju o MIDlet suite-u i može ga koristiti AMS od uređaja u svrhu pokretanja

instalacije

• Ako ne postoji opisnik aplikacije, ili nakon što je AMS preuzeo opisnik aplikacije i

zaključio da instalaciju treba nastaviti, započinje preuzimanje MIDlet suite JAR (Java

ARchive) datoteke

Kad govorimo o aplikaciji za otkrivanje sadržaja tj. DA, mislimo prvenstveno na dva moguća

rješenja. U prvom slučaju radi se o najobičnijem web pregledniku za pokretne uređaje koji

učitava HTML ili WAP stranice na kojima su ponuđeni link-ovi na aplikacije, a u drugom

slučaju radi se o aplikaciji unutar samog uređaja koja se spaja na određeni mrežni resurs i

prezentira ponuđene aplikacije na određeni način. U ovom drugom slučaju, često se radi o već

ugrađenim aplikacijama od strane operatera.

Koristeći DA, korisnik bi trebao biti u mogućnosti pristupiti mrežnoj lokaciji i vidjeti opis

MIDlet suite-a kao i link, koji kad se odabere, pokreće instalaciju odabranog MIDlet suite-a.

Ako link pokazuje na JAR datoteku, JAR datoteka i njen jedinstveni identifikator resursa

(engl. Uniform Resource Locator, skraćeno URL) se proslijeđuju AMS-u na uređaju kako bi

on započeo proces instalacije. Ako link pokazuje na opisnik aplikacije, onda:

1. Nakon što je link odabran, poslužitelj mora naznačiti u odgovoru da je podatak koji se

prenosi MIME (Multipurpose Internet Mail Extensions) tip "text/vnd.sun.j2me.app-

descriptor".

2. Nakon što je prijenos završen, opisnik aplikacije i njen URL se proslijeđuju AMS-u na

uređaju kako bi započeo proces instalacije. AMS koristi opisnik aplikacije kako bi

odredio da li odabrani MIDlet suite može biti uspješno instaliran i pokrenut na

19

uređaju. Ako to nije slučaj, korisnik mora biti obaviješten o razlozima koji sprječavaju

njegovu instalaciju. Korisnik bi trebao biti što prije informiran o neuobičajenim

uvjetima kako bi se smanjio gubitak vremena i korištenje mrežnih resursa.

3. Opisnik aplikacije mora biti konvertiran iz svog prijenosnog oblika u Unicode oblik,

koji je specificiran MIDP-om, prije nego što ga se može korisiti. Predefinirani skup

znakova za MIME tip "text/vnd.sun.j2me.app-descriptor" je "UTF-8". Atributi u

opisniku moraju biti oblikovani na način propisan specifikacijom MIDP i svi atributi

zahtijevani istom specifikacijom moraju biti prisutni u opisniku. Ako to nije slučaj,

klijent mora odgovoriti sa Status Code 906 u izvještaju o statusu.

4. Koristeći informaciju iz opisnika aplikacije koja uključuje ime proizvođača, ime

aplikacije, verziju i veličinu, korisniku se treba dati na odabir da potvrdi želi li

instalirati taj MIDlet suite. Korisnik bi trebao biti upozoren u situaciji kad pokušava

instalirati stariju verziju aplikacije ili pak istu verziju. Isto tako, trebalo bi ustvrditi

moguće razloge koji bi sprječili uspješnu instalaciju i pokretanje MIDlet suite-a te o

tome obavijestiti korisnika. Naprimjer, ako se zna da je na raspolaganju nedovoljna

količina memorije, program bi trebao pomoći korisniku u pregledu korištenja i

oslobađanju dovoljne količine memorije za instalaciju novog MIDlet suite-a.

Proces otkrivanja MIDlet suite-a korištenjem DA može biti prilagođen od strane pokretnog

uređaja tako da pokretni uređaj pošalje poslužitelju informacije o sebi. DA mora pružiti

mrežnom poslužitelju informacije kako bi poslužitelj mogao doznati podatke o mogućnostima

pokretnog uređaja. Za vrijeme preuzimanja MIDlet suite-a, pokretni uređaj bi trebao pružiti

poslužitelju što je više moguće podataka o svojim karakteristikama i tipu sadržaja koji želi.

HTTP zahtjev u kojem se dohvaća željeni sadržaj mora sadržavati zaglavlja User-Agent,

Accept-Language i Accept, a poslužitelji bi trebali iskoristiti ovu dodatnu informaciju kako bi

odabrali prikladni opisnik aplikacije za uređaj.

3.3.4. Instalacija aplikacije

Instalacija aplikacije je proces u kojem uređaj preuzima MIDlet suite i čini ga raspoloživim

korisniku. Naravno, instalacija aplikacije mora biti podržana od strane uređaja. Mreža u kojoj

se nalazi uređaj, kao i bilo koji proxy ili izvorni poslužitelj koji se koriste tokom pružanja

20

usluge, moraju moći podržati ovaj zahtjev. Korisnik zadržava kontrolu resursa koje koristi

MIDlet suite u uređaju i mora biti u mogućnosti instalirati ili izbrisati MIDlet suite. Isto tako,

uređaj mora korisniku omogućiti pokretanje MIDlet-a unutar MIDlet suite-a. Tijekom

instalacije, korisnik bi trebao biti obaviješten o njenom napredovanju i mora mu biti

omogućeno da je prekine. Prekidanje instalacije mora ostaviti uređaj u stanju u kakvom je bio

prije nego je instalacija počela. Ako je MIDlet suite već instaliran, onda se ovo treba tretirati

kao ažuriranje o kojem ćemo govoriti nešto kasnije. Kako bi obavio instalaciju MIDlet suite-

a, AMS obavlja sljedeći niz koraka i provjera te obavještava korisnika o napretku:

1. Uređaj pokreće preuzimanje MIDlet suite-a preko HTTP-a. Ako je prvo bio preuzet

opisnik aplikacije, zahtjev za MIDlet suite-om mora biti točno za onaj URL definiran u

opisniku.

2. Ako poslužitelj ili proxy odgovori na zahtjev za MIDlet suite-om s 401(Unauthorized)

ili 407(Authentication Required), uređaj bi trebao ponovno poslati zahtjev s podacima

za utvrđivanje identiteta u zaglavljima Authorization ili Proxy-Authorization. Ove

podatke treba dati korisnik, naprimjer putem dijaloga korisniku za unos korisničkog

imena i lozinke. Uređaj mora moći podržati barem osnovnu autentifikacijsku shemu

definiranu RFC-om (engl. Request For Comment) 2617.

3. MIDlet suite i zaglavlja se moraju provjeriti kako bi se ustanovilo da je preuzeti

MIDlet suite valjan i da ga se može instalirati na uređaj. Ako je došlo do nekih

problema koji sprječavaju instalaciju, korisnik o tome mora biti obaviješten i

odgovarajuća statusna poruka iz skupa – 901, 903, 904, 905, 907, 909, 910, 911 –

mora biti poslana nazad poslužitelju. U tablici (Tablica 3.1) vidimo skup svih mogućih

statusnih poruka i što one znače.

Tablica 3.1 Statusne poruke za OTA-u

Statusni kod Statusna poruka

900 Uspješno

901 Nedovoljna količina memorije

902 Otkazano od strane korisnika

903 Gubitak usluge

904 Pogrešna veličina JAR datoteke

905 Pogrešne vrijednosti atributa

906 Pogrešni opisnik

21

907 Pogrešna JAR datoteka

908 Nekompatibilna konfiguracija ili profil

909 Neuspješna autentifikacija aplikacije

910 Neuspješna autorizacija aplikacije

911 Neuspješna registracija za push

912 Obavijest o brisanju

4. Ako nije došlo do nikakvih problema pri instalaciji, MIDlet suite se instalira i stavlja

na raspolaganje korisniku koji ga onda može pokrenuti odabirom u selekcijskom

mehanizmu za MIDlet-e koji se nalazi u uređaju. Instalacija je završena kada je

MIDlet suite na raspolaganju unutar uređaja ili kad je došlo do neoporavljive

pogreške. U bilo kojem slučaju, status mora biti prijavljen kako je već ranije rečeno.

3.3.5. Ažuriranje aplikacije

Ažuriranje MIDlet suite aplikacije definirano je kao operacija instaliranja određenog MIDlet

suite-a kada je taj isti MIDlet suite (ista verzija ili neka druga) već instaliran na uređaju.

Uređaji moraju podržavati ažuriranje MIDlet suite-a. Kako bi operacija bila logična korisniku,

uređaj omogućuje korisniku da sazna informaciju o MIDlet suite-u na uređaju i odluči koja

verzija programa je instalirana. Kada je ažuriranje pokrenuto, uređaj obavještava korisnika da

li je MIDlet suite novija, starija ili ista verzija postojećeg MIDlet suite-a i dobija potvrdu od

korisnika prije nego što nastavi dalje. RMS (Record Management System) tj. sustav za

upravljanje podacima smještenim u perzistentnoj memoriji, na slijedeći način upravlja

podatkovnim zapisima o MIDlet suite aplikaciji koja se ažurira:

• Ako je digitalni potpisnik novog MIDlet suite-a i originalnog MIDlet suite-a identičan,

onda RMS zapis mora biti zadržan i stavljen na raspolaganje novom MIDlet suite-u.

• Ako su shema, domaćin i put URL-a s kojeg je preuzet novi opisnik aplikacije

identični shemi, domaćinu i putu URL-a s kojeg je preuzet originalni opisnik

aplikacije, onda RMS zapis mora biti zadržan i stavljen na raspolaganje novom

MIDlet suite-u.

22

• Ako su shema, domaćin i put URL-a s kojeg je preuzet novi MIDlet suite identični

shemi, domaćinu i putu URL-a s kojeg je preuzet originalni MIDlet suite, onda RMS

zapis mora biti zadržan i stavljen na raspolaganje novom MIDlet suite-u.

• Ako su gornje tvrdnje netočne, onda uređaj mora upitati korisnika da li da zadrži

podatke originalnog MIDlet suite-a i da li da ih stavi na raspolaganje novom MIDlet

suite-u

U svakom slučaju, ne smije se dozvoliti nepotpisanom MIDletu da ažurira potpisani MIDlet

suite. Dozvole koje su bile dane od korisnika originalnom MIDlet suite-u bi isto trebale biti

dane i novom MIDlet suite-u, ako su u sigurnosnoj domeni novog MIDlet suite-a.

3.3.6. Izvršavanje aplikacije

Kada korisnik odabere MIDlet za izvršavanje, uređaj mora pozvati MIDlet zajedno s CLDC i

MIDP klasama zahtijevanim u specifikaciji MIDP. Ako je prisutno više MIDleta, korisničko

sučelje mora dopustiti korisniku mogućnost odabira za izvršavanje svakog posebno.

3.3.7. Brisanje aplikacije

Uređaji moraju dopustiti uklanjanje MIDlet suite-ova korisniku. Kada se MIDlet suite treba

obrisati s uređaja, korisnika bi trebalo upitati za potvrdu. Uređaj bi također trebao upozoriti na

bilo kakve specijalne okolnosti koje mogu proizaći brisanjem MIDlet suite-a. Ako opisnik

aplikacije uključuje atribut MIDlet-Delete-Confirm, njegova vrijednost bi trebala biti

uključena u zahtjev. Ovo će omogućiti autoru MIDlet suite-a da naznači bilo kakve specijalne

uvjete koji mogu nastati kao rezultat brisanja aplikacije. Nakon brisanja aplikacije, AMS šalje

poslužitelju statusni kod 912.

3.3.8. Promjene u JAD-u za podršku OTA-i

U Java Application Descriptoru treba napraviti neke promjene kako bi mogao podržavati

pružanje usluga koristeći OTA-u. Četiri atributa u JAD-u koji se odnose na OTA-u su:

• MIDlet-Jar-URL – Ovaj atribut sadrži URL na kojem se nalazi MIDlet suite (JAR

dokument).

23

• MIDlet-Install-Notify – Ovaj atribut sadrži URL na koji se šalje POST zahtjev u kojem

se izvještava o statusu instalacije (ili ažuriranja) MIDlet suite-a. Uređaj mora koristiti

ovaj URL bez ikakvih promjena i on ne smije biti duži od 256 UTF-8 kodiranih

znakova. Ako uređaj primi URL duži od 256 UTF-8 kodiranih znakova, mora odbiti

instalaciju i vratiti poslužitelju Status Code 906.

• MIDlet-Delete-Notify – Ovaj atribut sadrži URL na koji se šalje POST zahtjev kako bi

se moglo izvjestiti o brisanju MIDlet suite-a. Uređaj mora koristiti ovaj URL bez

ikakvih promjena i on ne smije biti duži od 256 UTF-8 kodiranih znakova. Ako uređaj

primi URL duži od 256 UTF-8 kodiranih znakova, mora odbiti instalaciju i vratiti

poslužitelju Status Code 906.

• MIDlet-Delete-Confirm – Ovaj atribut sadrži tekstualnu poruku koja se prikazuje

korisniku kad se od njega zahtijeva potvrda brisanja pripadnog MIDlet suite-a i time

upravlja AMS.

Ovi atributi dodani su jer je uspjeh ili neuspjeh instalacije, ažuriranja ili brisanja MIDlet suite-

a u interesu pružatelja usluge. Pružatelj usluge može specificirati URL-ove u opisniku

aplikacije koji moraju biti upotrijebljeni za izvještaj o instalaciji i brisanju. Ako uređaj ne

može poslati izvještaj o statusu instalacije, tražena akcija svejedno mora biti dovršena. Isto

tako, ako uređaj ne može poslati izvještaj o statusu brisanja aplikacije, brisanje MIDlet suite-a

svejedno mora biti dovršeno.

Status određene akcije se dojavljuje poslužitelju korištenjem metode HTTP POST na URL

specificiran u atributu MIDlet-Install-Notify ako se radi o instalaciji tj. na URL specificiran u

atributu MIDlet-Delete-Notify ako se radi o brisanju. Jedini protokol koji mora biti podržan je

"http://". Sadržaj tijela zahtjeva POST mora uključivati statusni kod i statusnu poruku u prvoj

liniji. U slučaju da se radi o izvještaju o brisanju aplikacije, obavijest se šalje tek kad je

MIDlet obrisan te mora biti poslan statusni kod 912 koji je signal da je došlo do uklanjanja

aplikacije s korisničkog uređaja. U odgovoru na statusni izvještaj, poslužitelj mora odgovoriti

odgovorom "200 OK". Uređaju natrag ne bi trebao biti poslan nikakav sadržaj, a ako je takav i

poslan, mora biti ignoriran.

24

3.3.9. Međusobna suradnja između AMS-a i poslužitelja za

pružanje usluga

Ukratko ćemo prikazati suradnju između klijentskog uređaja i poslužitelja tijekom pružanja

usluge korištenjem OTA-e. Kao i u svakoj drugoj mrežnoj komunikaciji između dviju krajnjih

točaka, ovdje također postoji protokol koji definira skup pravila i dijaloga korištenih između

dva kraja komunikacije. U MIDP-u, protokol OTA se sastoji od HTTP zahtjeva i odgovora,

preuzimanja JAD i JAR datoteka, osnovne HTTP autentifikacije i izvještavanja o statusu. Ako

pretpostavimo da je vrijednost atributa MIDlet-Jar-URL jednaka

www.j2medeveloper.com/ota/demos.jad, onda je komunikacija između klijenta i poslužitelja u

procesu preuzimanja JAD i JAR datoteka jednaka onoj prikazanoj na slici (Sl. 3.4). Ako se

dogodi neka pogreška prilikom preuzimanja ili instalacije, AMS odgovara odgovarajućim

statusnim kodom.

Sl. 3.4 Međusobna suradnja AMS-a na klijentu i poslužitelja

25

4. Lokacijske usluge i OTA

Lokacijskim uslugama (engl. Location Based Services, skraćeno LBS) nazivamo usluge koje

korisnicima pružaju određenu informaciju na temelju njihovog trenutnog položaja koristeći za

to neku od postojećih lokacijskih tehnologija za lociranje korisnika i bazu podataka iz koje se

dohvaćaju odgovarajući podaci. Podaci koji se isporučuju korisniku su povezani s njegovom

lokacijom te njegovim zahtjevima i korisnik do njih može doći koristeći push ili pull

komunikaciju. Lokacijske usluge i OTA su često povezane i isprepliću se. Tako, recimo,

aplikacija koju smo na svoj pokretni uređaj preuzeli i instalirali koristeći OTA-u za svoju

svrhu može imati upravo pružanje lokacijskih usluga. Može se reći da se skoro sve lokacijske

usluge odvijaju u stvarnom vremenu putem bežične komunikacije tj. over-the-air.

4.1. Vrste lokacijskih usluga

Lokacijske usluge imaju veliko područje primjene i kao takve nude operaterima i trećoj strani

mogućnost kreiranja i implementacije velikog broja potencijalnih usluga koje će im donijeti

dodatni prihod, a korisnicima poboljšati kvalitetu usluge [4]. U većini primjena lokacijske

usluge odgovaraju na jedno ili više od ova 3 pitanja:

• Gdje sam?

• Što je u mojoj blizini?

• Kako da dođem tamo?

Naravno, postoje i specifične primjene kao lokacijski orijentirano oglašavanje koje korisnika

push komunikacijom obavještava o nekoj trgovini, hotelu ili restoranu u blizini, a koje

zapravo ne uključuje interakciju korisnika već samo njegovo odobrenje za primanje takvog

sadržaja.

Lokacijske usluge se mogu podijeliti na 2 vrste kad promatramo komunikaciju s mrežom:

• push usluge – mrežno inicirana komunikacija

• pull usluge – korisnički inicirana komunikacija

26

U push lokacijske usluge spadaju usluge kao:

• usluga pokretnog oglašavanja (engl. mobile advertisements)

• usluga upozorenja na gužve u prometu

• usluga upozorenja na pogoršanje vremena

U pull lokacijske usluge spadaju usluge kao:

• usluga pružanja cestovnih uputa

• usluga pokretnih "žutih stranica"

• usluga pomoći pri kupovini

• usluga lociranja i rezervacije za kina, kazališta, restorane i drugo

• informacijske usluge (vijesti, stanje na burzi, sportski rezultati, …)

• usluga pronalaska neke osobe

Općenito, lokacijske usluge možemo podijeliti u 4 grupe:

• okidne (engl. trigger) usluge

• informacijske usluge

• usluge praćenja treće strane

• usluge pružanja pomoći korisniku

4.1.1. Okidne usluge

Okidne usluge su automatski pokrenute kad korisnik uđe u neko prethodno definirano

područje. Iako su ove usluge dizajnirane da obuhvaćaju relativno velika područja, unatoč

tome zahtijevaju prilično dobru razinu preciznosti. Dva glavna tipa okidnih usluga su:

• Lokacijski zasnovana naplata – Pretplatnici mogu birati različiti broj zona, različitih

veličina, unutar kojih će bilo koji poziv biti naplaćen po jeftinijoj tarifi. Ova usluga se

temelji na pretpostavci da je većina korisničkih poziva najčešće uspostavljena sa samo

nekoliko lokacija. Zato je ova usluga izvedena da potakne korisnike na prebacivanje s

fiksnih na mobilne operatere.

• Usluge oglašavanja – Ovo uključuje usluge poput informacija za putnike koji su

upravo sletjeli na aerodrom i kojima treba informacija o taksi tvrtkama ili stanju

spajajućih letova. Isto tako, moguće je i slanje oglasa za koje korisnik ima interesa kad

27

prolazi blizu određene trgovine s tim da, kako bi se izbjeglo nepotrebno ometanje,

korisnik prethodno odabere vrste informacija koje ga zanimaju.

4.1.2. Informacijske usluge

Ovaj tip usluga uključuje bilo koju primjenu gdje je informacija filtrirana i prenesena

korisniku na način da ovisi o njegovoj lokaciji. Razina preciznosti za ovakve usluge značajno

varira ovisno o tipu informacije pa je tako moguće ostvarivanje ovih usluga bilo kojom od

postojećih lokacijskih metoda. Primjeri ovakvih usluga su:

• Gdje sam/Gdje je...? – Korisniku treba informacija o nečemu u blizini ili mu treba

najbliži put do tražene destinacije.

• Promet i navigacija – Korisniku treba informacija, najčešće za vrijeme vožnje, o

prometnim gužvama, radovima na cesti ili o najboljem putu do određene destinacije.

• Razne usluge – Postoji mnogo mogućih dodatnih informacijskih usluga kao

regionalni izvještaji o vremenu ili informacije o turističkim atrakcijama.

• Lokacijski zasnovane igre – Ovo je kombinacija informacijske usluge i usluge

praćenja.

4.1.3. Usluge praćenja treće strane

Ove usluge, gdje je potrebna informacija o lokaciji treće strane, uključuju i poslovnu i osobnu

primjenu. Preciznost ovog tipa usluga često mora biti prilično visoka s obzirom da je korisnik

obično u pokretu. Tri glavna tipa ovih usluga su:

• Upravljanje voznim parkom/Upravljanje radnom snagom – Ova usluga je

namijenjena za poslovni sektor, naročito za one tvrtke koje se bave prijevozom, taksi

uslugama, dostavom i slično, kako bi kontinuirano znale lokaciju svojih vozila i/ili

radnika.

• Praćenje vrijedne imovine – Ova usluga je namijenjena i privatnim i poslovnim

korisnicima kako bi mogli pratiti ili lako pronaći nešto njima vrijedno.

• Pronalaženje ljudi – Usluga namijenjena privatnim korisnicima koja bi, recimo,

mogla roditeljima omogućiti da znaju gdje im je dijete preko njegovog pokretnog

uređaja. Isto tako, korisnika se može obavijestiti, automatski ili na zahtjev, o lokaciji

nekog prijatelja u njegovoj blizini.

28

• Lokacijski zasnovane igre – Ovo je zapravo već spomenuto u informacijskim

uslugama kao kombinacija njih i usluge praćenja.

4.1.4. Usluge pružanja pomoći korisniku

Ovo su usluge koje se ne koriste često, a osmišljene su kako bi korisniku pružile sigurnosnu

mrežu u slučaju da se nađu u nevolji. Dva glavna tipa ove vrste usluga su:

• Pomoć na cesti – Cilj ove usluge je dati lokaciju korisnika i ubrzati vrijeme odziva za

korisnike kojima se pokvarilo vozilo.

• Usluge vezane uz hitne službe – Ova usluga određuje lokaciju s koje dolazi poziv

policiji/vatrogascima/hitnoj pomoći kako bi se što više smanjilo vrijeme odziva tih

službi.

Ovakve usluge bi uskoro mogle pružiti veliki poticaj u korištenju lokacijskih usluga s

obzirom da bi države, u svrhu poboljšanja pružanja pomoći osobama u nevolji, mogle

propisati operaterima postizanje određene točnosti pri lociranju korisnika, a da korisnici ne

moraju za to mijenjati svoje pokretne uređaje, već da koriste postojeće. Veća preciznost

lociranja, koja bi tada bila omogućena korisnicima, omogućila bi im pristup i cijelom nizu

ostalih lokacijskih usluga te bi na taj način širenje lokacijskih usluga bilo znatno ubrzano.

4.2. Lokacijska tehnologija i lokacijske metode

Kako bi mogli ostvariti ranije navedene usluge, svaka od njih zahtijeva određenu preciznost u

određivanju lokacije korisnika kako bi se ostvarila prihvatljiva kvaliteta usluge. Zahtijevana

kvaliteta usluge, naravno, varira ovisno o tome o kojem se tipu usluge radi pa je tako logično

da će usluga pružanja cestovnih uputa zahtijevati puno veću kvalitetu od, recimo, usluge

pokretnog oglašavanja. Uzevši to obzir, očito je da će one usluge koje zahtijevaju veću

preciznost koristiti naprednije i preciznije metode lociranja korisnika, što znači i veću cijenu

za korisnika, dok će za one usluge kod kojih veća preciznost nije potrebna biti prihvatljive i

jednostavnije, ali i jeftinije metode. Zato ćemo se sada osvrnuti na tehnologiju i metode

lociranja korisnika te ih međusobno usporediti i analizirati koje su prikladne za različite vrste

usluga.

29

Pod pojmom lokacije korisnika mislimo na mjesto na kojem je korisnik smješten u stvarnom

svijetu. Ta lokacija može biti izražena na više načina koristeći razne referentne okvire kao, za

primjer, apsolutne prostorne koordinate, opisne lokacije i relativne lokacije. Različiti načini

izražavanja lokacije će odrediti lokaciju objekta u određenoj točki, području ili regiji na ili u

blizini zemlje. Kada govorimo o lokaciji izraženoj u apsolutnim prostornim koordinatama

onda je važan odabir koordinatnog sustava koji se za to koristi. Tako je moguće koristiti

sustav zemljopisne širine, dužine i visine, geocentrični sustav ili univerzalni Mercatorov

koordinatni sustav. Nama je najzanimljiviji sustav zemljopisne širine, dužine i visine gdje su

širina i dužina izražene u stupnjevima, a visina u metrima iznad morske površine. Taj sustav

je i najrašireniji u današnje vrijeme kad je tolika preciznost potrebna za ostvarenje određene

usluge. Ipak, za dosta usluga ta razina preciznosti nije potrebna, već je često dovoljno znati

nalazi li se korisnik u nekom području ili zoni.

Na slici (Sl. 4.1) je prikazana okosnica visoke razine za lokacijske usluge koja sadrži četiri

kritične komponente.

Sl. 4.1 Vrijednosni lanac određivanja lokacije

Te komponente su:

• Lokacijska rješenja (engl. Positioning Solutions) – Ovo se odnosi na sredstva kojima

lociramo pokretni uređaj. Njihov je zadatak dohvatiti poziciju i pretvoriti je u smislenu

lokacijsku informaciju. Lokacijsko rješenje koristi razne lokacijske metode koje ćemo

naknadno opisati.

• Sadržaji i usluge (engl. Content Product and Services) – Ovaj dio se odnosi na skup

referentnih informacija za podršku lokacijski osjetljivih usluga, uključujući rad s

kartama, informacije o adresama, modele odabira puta, područja interesa i stvarno-

30

vremenske informacije. Za ovo je potrebno prikupiti, objediniti, formatirati i

kontrolirati veliku količinu geografskih informacija. Važno je napomenuti da je ovo

kontinuirani proces čiji je cilj poboljšati potpunost, konzistentnost i točnost

informacija.

• Lokacijski zasnovane posredničke komponente (engl. Location Based Middleware

Components) – Ovaj pak dio pruža sučelje prema sustavima lokacijskog sadržaja i

naplate kako bi pružilo bogati API koji razvojnim timovima omogućava brzo i lagano

integriranje lokacijske osjetljivosti u usluge. Ova je komponenta glavna radionica

čitavog rješenja i bavi se velikim brojem kompleksnih zadaća koje uključuju:

geokodiranje, reverzno geokodiranje, istančano lociranje, prostorno pretraživanje,

generiranje cestovnih uputa i crtanje geografskih karata.

• Lokacijski zasnovana aplikacija – Ovo se odnosi na samu aplikaciju koja koristi

lokacijsku okosnicu kako bi pružila uslugu korisniku.

Sada ćemo se upoznati s glavnim metodama određivanja lokacije korisnika te mogućnostima

njihove primjene i njihove prikladnosti za određene tipove usluga.

4.2.1. Identifikacija ćelije

Identifikacija ćelije (Cell-ID) je metoda lociranja korisnika tj. pokretnog uređaja koja radi u

GSM (Global System for Mobile Communications), GPRS (General Packet Radio Service) i

WCDMA (Wideband Code Division Multiple Access) pokretnim mrežama. Ova metoda traži

od mreže da identificira s kojom baznom stanicom (engl. Base Transceiver Station, skraćeno

BTS) pokretni uređaj komunicira i na kojoj se lokaciji nalazi bazna stanica. Usluga lociranja

putem Cell-ID-a poistovjećuje lokaciju pokretnog telefona u GSM-u tj. korisničke opreme u

UMTS-u s lokacijom bazne stanice i prosljeđuje ovu informaciju aplikaciji koja pruža

lokacijsku uslugu. Cell-ID se koristio više u početku primjena lokalnih usluga kad visoka

razina preciznosti još nije bila toliko potrebna, a ni obavezna. Ipak, zbog svoje jednostavnosti,

lake implementacije i cijene još uvijek se može koristiti za usluge gdje veća preciznost nije

potrebna.

Ako uređaj koristimo za ostvarivanje poziva, onda će informacija o ćeliji u kojoj se uređaj

nalazi biti ažurirana i proslijeđena mreži u stvarnom vremenu. U drugom slučaju, kad je

uređaj u stanju mirovanja (uključen, ali ništa ne šalje), onda će zadnja lokacija s koje je uređaj

31

nešto slao biti spremljena od strane mreže u domaći lokacijski registar (engl. Home Location

Register, skraćeno HLR). Kako bi mreža osvježila informaciju o lokaciji uređaja, ona će

dozvati uređaj tražeći od njega da nadgleda jačinu signala obližnjih baznih stanica i na taj

način će dobiti informaciju o njegovom Cell-ID-u.

Preciznost ove metode lociranja prvenstveno ovisi o veličini ćelije u kojoj se nalazi uređaj i u

puno slučajeva može biti dosta loša s obzirom da tipična GSM ćelija može promjeru imati

između 2 i 20 kilometara. Sa tzv. piko ćelijama može se postići preciznost i do 150m.

Korištenjem tehnika TA (Timing Advance) ili RX mjerenja (Signal Strength) može se podići

razina preciznosti.

Metoda Cell-ID + TA temelji se na principu da pokretni uređaj kad šalje podatke to čini nešto

prije njegovog dodijeljenog odsječka kako bi, zbog prostorne udaljenosti uređaja i bazne

stanice, podaci stigli do bazne stanice točno u trenutku početka njegovog odsječka. Ovo

vrijeme je vrlo važno za efikasno funkcioniranje GSM/GPRS mreže. S obzirom da je vrijeme

ovog uranjenog slanja za svaki uređaj ovisno o njegovoj udaljenosti od bazne stanice, moguće

je iskoristiti ovu informaciju za određivanje koliko daleko je korisnik od bazne stanice. Ipak,

postoji ograničenje, a to je da je ova metoda korisna u povećanju preciznosti samo za one

ćelije s radijusom većim od 550 metara zato što se prilagođavanje vremena slanja pokretnog

uređaja računa na osnovu toga koliko je puta po 550 metara pokretni uređaj udaljen od bazne

stanice.

Metoda Cell-ID + RX mjerenje temelji se na tome da pokretni uređaj mjeri snagu signala sa

svake bazne stanice koju „vidi“ i šalje ovu informaciju natrag baznoj stanici koja ga trenutno

poslužuje. Ovo se radi zato da bi pokretni uređaj mogao slati i primati podatke od bazne

stanice za koju ima optimalnu snagu signala povećavajući tako kvalitetu poziva krajnjem

korisniku i efikasnost korištenja mrežne infrastrukture. S ovom informacijom o snazi signala,

teoretski je moguće izračunati lokaciju korisnika uzimajući u obzir brzinu kojom opada snaga

odašiljućeg signala kako se povećava udaljenost između odašiljača i primatelja. Ipak, postoje

brojni faktori koji ograničavaju efikasnost ove metode kao što su konfiguracija terena i

zatvoreni prostori.

32

4.2.2. Metoda poboljšanog promatranja vremenske razlike

Metoda poboljšanog promatranja vremenske razlike (engl. Enhanced Observed Time

Difference, skraćeno E-OTD) radi samo u GSM i GPRS mrežama. Temelji se na promatranju

vremenskih razlika u dolasku GSM okvira na pokretni uređaj od različitih baznih stanica s

kojima komunicira. Potrebno je da uređaj mjeri vremenske razlike s bar 3 bazne stanice kako

bi bilo moguće dvodimenzionalno određivanje lokacije. Isto tako za ostvarenje ove metode

potrebni su lokacijski mjerni uređaji (engl. Location Measurement Units, skraćeno LMU) koji

nadziru bazne stanice. Najvažnije je da je svaka bazna stanica u mreži promatrana od bar

jednog LMU-a. Potreba za LMU uređajima stvara potrebu za velikim infrastrukturnim

promjenama što zahtjeva puno planiranja, procjena, ulaganja i troškova pa to otežava

primjenu E-OTD kao lokacijskog rješenja. Isto tako, ova metoda generira velik promet u

mreži i smanjuje mrežnu propusnost. E-OTD je precizniji od Cell-ID-a, ali postaje dosta

neprecizan u ruralnim područjima. Isto tako, refleksije signala i višestazno prostiranje signala

dosta utječu na preciznost.

Postoji još metoda OTDOA (Observed Time Difference of Arrival) koja je zapravo ekvivalent

E-OTD metodi u WCDMA mreži, ali postiže čak lošije rezultate od E-OTD metode ako se ne

koriste LMU uređaji.

4.2.3. Potpomognuti GPS

GPS (Global Positioning System) metoda lociranja je širom svijeta raširena metoda koja je

ostvarena sustavom satelita i uređaja koji je podržavaju. Radi na principu mjerenja vremena

koje potrebno da signal pređe put od satelita do prijemnika te bi za preciznu vremensku

informaciju primljeni satelitski signal trebao biti relativno snažan. Kako bi se nadvladalo ovo

ograničenje osmišljena je metoda potpomognutog GPS-a tj. A-GPS (Wireless Assisted GPS).

A-GPS prijemnik koristi pomoćne podatke koje dobije od A-GPS lokacijskog poslužitelja

(engl. Location Server, skraćeno LS) uz pomoć kojih se poboljšava početna osjetljivost za

25dB i smanjuje vrijeme pokretanja za 5 sekundi. Ovaj pristup eliminira dugačka vremena

pokretanja karakteristična za obični GPS i omogućava GPS prijemniku da funkcionira u

okolini problematičnoj za GPS signal. A-GPS pruža veću preciznost od Cell-ID-a, E-OTD-a

ili OTDOA, a skupi element poput LMU-a nije potreban. A-GPS ima skoro neprimjetan

utjecaj na infrastrukturu i može lako podržati roaming, ali zahtjeva GPS sklopovlje unutar

telefona.

33

4.2.4. Hibridna rješenja

A-GPS radi u GSM, GPRS i WCDMA mrežama. Hibridna rješenja kombiniraju A-GPS s

drugim lokacijskim metodama na način koji dopušta da bolje strane jedne metode

kompenziraju slabije strane druge metode i tako pruže pouzdanije i robusnije lokacijsko

rješenje. Najčešća implementacije hibridne tehnologije je združivanje A-GPS-a sa Cell-ID-

om. Ovo rješenje povećava postotak uspješnih lociranja u područjima u kojima A-GPS ne

može odrediti lokaciju i pruža preciznost A-GPS-a u svim ostalim situacijama.

4.2.5. Usporedba lokacijskih metoda

U tablici (Tablica 4.1) vidimo usporedbu lokacijskih metoda u pogledu performansi, troškova,

implementacijskih prilagodbi i podržanih standarda. Kao što vidimo, metoda poput A-GPS-a

prikladna je za lokacijske usluge koje zahtijevaju veću preciznost poput usluge lokacijski

zasnovane naplate, usluga praćenja treće strane ili usluga vezanih uz navigaciju. E-OTD

metoda pruža manju preciznost od A-GPS-a i mogla bi biti pogodna za razne informacijske

usluge, lokacijski zasnovane igre ili usluge pružanja pomoći korisniku, ali ima veliku manu u

pogledu troškova i jednostavnosti implementacije. Što se tiče metode Cell-ID, očito je da ona

dosta varira u pogledu preciznosti i da nije previše pouzdana. Ipak, zbog njene lake

implementacije i malih troškova, dobro je rješenje za usluge koje ne zahtijevaju veliku

preciznost, i to naročito u većim gradovima gdje imamo velik broj baznih stanica, zbog većeg

broja korisnika, pa je samim tim i prosječni promjer ćelije dosta manji i pruža veću preciznost

od uobičajenih slučajeva. Isto tako treba uzeti u obzir da u današnjem svijetu većina

stanovništva živi upravo u većim gradovima i da je najvećih broj korisnika pokretnih uređaja

upravo iz takvih sredina, što daje dobru podlogu za usluge ostvarene metodom Cell-ID u

pogledu postotka pokrivenosti korisnika uslugom. Cell-ID je, zbog ovih navedenih razloga,

tako najčešće pogodan za lokacijske usluge informacijskog tipa poput informacija o prometu,

vremenu, najbližem traženom objektu i slično.

34

Tablica 4.1 Prikaz usporedbe lokacijskih metoda

Karakteristika Cell-ID E-OTD, OTDOA A-GPS

Performanse

Preciznost Cell-ID-a

varira i često je dosta

loša.

Pruža dobru pokrivenost.

Pruža poboljšanu

preciznost u usporedbi sa

Cell-ID-om.

Problemi u područjima s

malim brojem baznih

stanica.

Pruža optimalnu

preciznost u usporedbi s

ostalim lokacijskim

metodama.

Problemi s pokrivenošću

unutar zgrada.

Implementacijske

prilagodbe

Lak za izvedbu.

Nema promjena u

samom uređaju.

Može biti podržan bez

većih promjena u

infrastrukturi.

Jednostavan roaming na

širim područjima ili u

drugim mrežama.

Težak za izvedbu.

E-OTD zahtjeva

promjenu u uređaju.

Zahtjeva LMU-e.

Teže podržava roaming

na širim područjima i u

drugim mrežama.

Lak za izvedbu.

Zahtjeva promjene u

uređaju.

Ne zahtjeva veće

promjene u

infrastrukturi.

Jednostavan roaming na

širim područjima i u

drugim mrežama.

Procjena ukupnog troška

Nizak početni trošak.

Trošak održavanja nizak.

Loš povrat ulaganja.

Početni trošak visok

zbog potrebe 1 LMU-a

po 1.5 baznoj stanici.

Trošak održavanja visok.

Loš povrat ulaganja.

Početni trošak vođen

cijenom uređaja.

Trošak održavanja

zanemariv.

Dobar povrat ulaganja.

Podržani standardi

GSM, GPRS i WCDMA E-OTD – samo GSM

OTDOA – samo

WCDMA

GSM, GPRS i WCDMA

35

5. Usluga pružanja lokacijski zavisnih informacija

pokretnom korisniku uz pomoć OTA-e

5.1. Analiza problema i predložena rješenja

Kao praktični dio ovoga rada, cilj je ostvariti lokacijsku uslugu za pokretnog korisnika koja će

korisniku pružati uslugu informacije o njemu najbližoj benzinskoj crpki, a koja će ovisiti o

trenutnoj lokaciji korisnika. Predviđeno je da korisnik sam odabere neku od ponuđenih tvrtki

koje prodaju gorivo te da onda dobije povratnu informaciju koja uključuje adresu najbliže

benzinske crpke tražene tvrtke. Usluga će biti izvedena uz pomoć aplikacije na pokretnom

uređaju korisnika, a koju će korisnik pribaviti uz pomoć tehnologije OTA. Aplikacija će,

nakon uspješne instalacije i pokretanja, u komunikaciji s poslužiteljem usluge, dati korisniku

povratnu informaciju na njegov upit. Problematika same realizacije usluge može se podijeliti

na:

• Otkrivanje, preuzimanje i instalaciju aplikacije

• Određivanje lokacije korisnika

• Obradu lokacije i dohvat odgovora na poslužitelju

• Komunikaciju između aplikacije i poslužitelja

5.1.1. Otkrivanje, preuzimanje i instalacija aplikacije

Kao što je već rečeno, predviđeno je da korisnik aplikaciju, koja će mu omogućiti korištenje

lokacijske informacijske usluge, pribavi korištenjem tehnologije OTA. Prvo što korisnik

treba, je otkriti tj. pronaći aplikaciju kako bi je mogao preuzeti. U skladu s tehnologijom

OTA, korisnik će aplikaciju pronaći uz pomoć web preglednika ili web mikro-preglednika, na

svom pokretnom uređaju, utipkavanjem URL-a na kojem će biti ponuđene određene

aplikacije. Dobro je još jednom napomenuti da su aplikacije o kojima govorimo zapravo

MIDleti, tj. aplikacije za pokretne uređaje. Korisnik će odabirom željene aplikacije, klikom na

njen link, započeti preuzimanje i instalaciju aplikacije na svom uređaju. Korisnik će prvo

preuzeti opisnik aplikacije, a nakon što iz njega utvrdi da je to ono što traži, odobrit će

preuzimanje same aplikacije i potom njene instalacije. O ovom dijelu se brine AMS na

36

pokretnom uređaju. Nakon što je instalacija završena, aplikacija je spremna za pokretanje i za

pružanje lokacijske usluge korisniku.

5.1.2. Određivanje lokacije korisnika

Kako bi mogli pravilno odrediti metodu lokacije korisnika, potrebno je uzeti u obzir prirodu i

karakteristike usluge koja traži lokacijsku informaciju. Kao što smo već rekli, usluga koja se

namjerava praktično ostvariti u ovom radu ima zadatak pružanja informacije o korisniku

najbližoj benzinskoj crpki. Benzinske crpke su, kad gledamo područja van gradova, obično

smještene na glavnim prometnicama poput autocesta, brzih cesta ili magistralnih cesta te je do

njih uglavnom lako doći i često nisu potrebne dodatne informacije o njihovim lokacijama.

Nasuprot tome, u većim gradovima benzinske crpke su smještene na raznim mjestima te

potencijalni kupci često ne znaju gdje je najbliža crpka. Ovo je naročito problem za one koji

slabije poznaju određeni dio grada ili za one koji uopće nisu iz tog grada. Zbog ovih razloga,

uslugu koju želimo ostvariti ograničit ćemo na područja većih gradova tj. bit će namijenjena

korisnicima u gradovima. Uzevši u obzir da tvrtke benzinske crpke često po gradovima

raspoređuju tako da nisu preblizu jedna drugoj tj. da su udaljene bar 1 do 2 km, kao lokacijska

metoda koja bi mogla ponuditi zadovoljavajuću preciznost nudi se Cell-ID tj. metoda

identifikacije ćelije. Naime, u gradskim sredinama promjer ćelija u GSM i GPRS mrežama je

dosta manji, nego u područjima van gradova, zbog većeg broja korisnika te je uglavnom u

rasponu od 500 metara do 2 km. Ova činjenica čini metodu Cell-ID dosta pogodnom zbog

toga što je jednostavna i ne zahtjeva ulaganja u infrastrukturu već koristi postojeću mrežnu

tehnologiju. Naime, mreža sama šalje pokretnim uređajima Cell-ID ćelije u kojoj se trenutno

nalaze te oni tu informaciju zapisuju. Korištenjem te informacije tj. njenim uzimanjem i

slanjem poslužitelju lokacijske usluge, poslužitelj određuje lokaciju i ovisno o njoj dostavlja

traženi sadržaj.

5.1.3. Obrada lokacije i dohvat odgovora na poslužitelju

Nakon što je lokacijska informacija uspješno poslana na poslužitelj, poslužitelj mora tu

informaciju obraditi te na temelju nje konstruirati odgovor korisniku. Lokacijska informacija

se sastoji od Cell-ID-a, a cijeli upit još od oznake tvrtke čiju najbližu benzinsku crpku

korisnik želi pronaći. Očito je da na neki način treba povezati identifikatore ćelija s

37

benzinskim crpkama koje se nalaze u gradu. To je najlakše postići stvaranjem baze podataka

koja će se sastojati od informacija o benzinskim crpkama i informacijama o ćelijama. Svaka

će benzinska crpka pripadati određenim ćelijama, te će se korisnik upućivati na tu crpku ako

se nalazi u nekoj od tih ćelija. Odgovor koja je crpka najbliža dobit će se upitom prema bazi

te će se nakon primljene povratne informacije ona proslijediti korisniku u pravilnom obliku.

5.1.4. Komunikacija između aplikacije i poslužitelja

Uz komunikaciju između aplikacije i poslužitelja postoji još, prije toga, komunikacija između

uređaja tj. njegovog AMS-a i portala za pružanje usluga s kojeg se preuzima sama aplikacija.

S obzirom da se radi o sadržaju za koji je pouzdanost komunikacije vrlo bitna, otkrivanje

aplikacije i njeno preuzimanje vrši se protokolom TCP/IP. Još jedan razlog korištenja ove

vrste komunikacije, a ne recimo komunikacije kratkim porukama (engl. Short Message

Service, skraćeno SMS), je veličina aplikacije koja potencijalno može biti veća od

maksimalno dozvoljene veličine za SMS poruke. Ipak, glavni je razlog sama specifikacija

tehnologije OTA kojom se vrši prijenos i koja se oslanja na HTTP koji koristi TCP/IP.

Komunikacija između same aplikacije i poslužitelja lokacijske informacijske usluge je

sljedeća na redu. S obzirom da se radi o prijenosu tekstualne informacije u oba smjera, i od

ove komunikacije očekujemo pouzdanost. U obzir treba uzeti i to da je sama obrada lokacije

na poslužitelju prilično jednostavna i brzo se izvodi tako da korisnik skoro trenutno može

dobiti odgovor na svoj upit. Zbog toga se kao najbolje rješenje opet nameće komunikacija

protokolom TCP/IP s kraja na kraj korištenjem mrežnih utičnica (engl. socket).

5.2. Izvori informacija za lokacijsku uslugu

Kako je već rečeno, informacije koje će se slati korisniku crpe se iz baze podataka. Očito je da

se nameće pitanje odakle se te informacije pribavljaju i tko ih u bazu unosi. Predviđeno je da

unos u bazu vrši jedna osoba koja jednom do dva puta mjesečno provjerava izvore

informacija te vrši dodatne unose ili ispravke u bazu ako za to postoji potreba. Izvori

informacija za tu bazu bit će internetske stranice trenutno triju glavnih tvrtki za opskrbu

benzinom u Hrvatskoj, a to su INA, OMV i Tifon, dok su adrese njihovih stranica

www.ina.hr, www.omvistrabenz.hr i www.tifon.hr. Pretpostavlja se da su informacije na tim

stranicama ispravne i smatramo ih pouzdanima.

38

5.3. Arhitektura usluge

Nakon što smo analizirali probleme vezane oko ostvarenja lokacijske usluge uz pomoć OTA-

e te predložili rješenja za svaki od njih, potrebno je sve skupa objediniti u jednu cijelinu tj.

oblikovati arhitekturu cijele usluge. Na slici (Sl. 5.1) je prikazana arhitektura unutar koje je

ostvarena usluga.

Sl. 5.1 Arhitektura usluge

Uočavamo njene glavne dijelove, klijenta i poslužitelje. Kao što vidimo, komunikacija

između njih je ostvarena već spomenutim protokolom TCP/IP. Između pokretne stanice i

jezgrene mreže TCP veza je ostvarena korištenjem tehnologije GPRS te njenih uslužnih

potpornih čvorova (engl. Serving GPRS Support Node, skraćeno SGSN) i pristupnih

potpornih čvorova (engl. Gateway GPRS Support Node, skraćeno GGSN). GGSN čvorovi se

39

nalaze u IP mreži i pružaju klijentu izlaz prema njoj. S obzirom da se poslužitelji nalaze u

TCP/IP mreži koja je osjenčena na slici, imamo podržanu TCP/IP vezu s kraja na kraj. Na

slici (Sl. 5.1) vidimo da se prvo uspostavlja veza između korisnika i OTA portala za pružanje

usluga koja služi za otkrivanje i prijenos aplikacije do korisnika, a raskida se nakon što je to

završeno. Nakon što korisnik instalira i pokrene aplikaciju, slanjem upita, koji se sastoji od

identifikatora ćelije i odabrane tvrtke, pokrenut će uspostavu nove TCP/IP veze s kraja na

kraj, ovaj put s poslužiteljem lokacijske informacijske usluge. Nakon što poslužitelj primi i

obradi upit, šalje natrag odgovor korisniku koristeći istu vezu. Kod sljedećeg korištenja

usluge, korisnik ne treba ponovno uspostavljati vezu s OTA portalom, jer je aplikacija trajno

spremljena na njegov uređaj, već samo s poslužiteljem lokacijske informacijske usluge.

5.4. Funkcionalnost OTA poslužitelja

Kako bi korisnik mogao pronaći, preuzeti i instalirati željenu aplikaciju od OTA poslužitelja

se očekuje da obavlja sljedeće:

• Omogući spajanje klijenta na web poslužitelj

• Nudi prikaz ponuđenih aplikacija u obliku HTML ili WAP stranica

• Omogući preuzimanje opisnika aplikacija i samih aplikacija od strane klijenta

• Pravilno naznači MIME tipove koji se koriste pri prijenosu opisnika aplikacija i samih

aplikacija

5.5. Funkcionalnost klijentske aplikacije

Prije nego što navedemo tražene funkcionalnosti klijentske aplikacije treba napomenuti da se

podrazumijeva da je aplikacija prije toga preuzeta i instalirana na korisnički uređaj u skladu s

tehnologijom OTA kako je opisano u 3. poglavlju. Od aplikacije se očekuje da obavlja

sljedeće funkcije, kronološkim redom:

• Mogućnost odabira tvrtke čiju benzinsku crpku korisnik želi pronaći

• Čitanje i spremanje identifikatora ćelije

• Konstruiranje upita za poslužitelj

• Spajanje na poslužitelj i slanje upita istome

• Primanje odgovora od poslužitelja i prikaz na ekranu korisničkog uređaja

40

Na slici (Sl. 5.2) je prikazan standardni slijed događaja pri korištenju klijentske aplikacije.

Sl. 5.2 Funkcionalnost klijentske aplikacije

41

5.6. Funkcionalnost poslužiteljske aplikacije

Kao što smo već naveli funkcionalnosti koje mora ispunjavati klijentska aplikacija, sad ćemo

navesti koje se sve funkcionalnosti očekuju od poslužiteljske aplikacije. Dakle, od

poslužiteljske aplikacije se očekuju sljedeće radnje, kronološkim redom:

• Spajanje s klijentom nakon primanja zahtjeva

• Prihvat upita od klijenta

• Raščlanjivanje i spremanje podataka o ćeliji i tvrtki iz upita

• Otvaranje veze s bazom podataka

• Postavljanje upita bazi podataka, primanje odgovora i prekid veze s bazom podataka

• Raščlanjivanje odgovora od baze podataka i oblikovanje u odgovor za klijenta

• Slanje odgovora klijentu

• Prekid veze s klijentom

Na slici (Sl. 5.3) vidimo slijed događaja koji se odvijaju na poslužiteljskoj aplikaciji.

Sl. 5.3 Funkcionalnost poslužiteljske aplikacije

42

6. Opis programskog rješenja usluge

6.1. Opis rješenja klijentske aplikacije

Klijentska aplikacija, koja predstavlja jednu od dvije strane u ostvarenju lokacijske usluge,

izvodi se na pokretnom uređaju klijenta. S obzirom da pokretni uređaji nemaju mogućnosti

poput standardnih računala zbog ograničenja veličine memorije, procesorske snage, veličine

ekrana te izvora napajanja, klijentska aplikacija mora biti prilagođena za ovakve uvjete.

Takve aplikacije nazivaju se MIDlet-i i realizirane su u J2ME okruženju. Za izvođenje ovih

aplikacija, pokretni uređaj korisnika mora podržavati profil pokretnog informacijskog uređaja

(MIDP).

Klijentska aplikacija sadrži dvije klase čiji odnos možemo vidjeti na slici (Sl. 6.1).

+KlijentPumpa()#startApp()#pauseApp()#destroyApp(in unconditional : boolean)+commandAction(in command : Command, in form : Displayable)

KlijentPumpa

+Find(in kp : KlijentPumpa)+start()+run()+commandAction(in command : Command, in form : Displayable)+getLocationMD() : String+getLocationEM() : String

Find

Sl. 6.1 Dijagram klasa klijentske aplikacije

Kao što vidimo, klasa KlijentPumpa je glavna klasa unutar klijentske aplikacije i pokreće se

na početku izvršavanja aplikacije. Klasa Find poziva se iz klase KlijentPumpa u trenutku kad

korisnik aplikaciji da zahtjev za pronalaženje najbliže crpke.

43

6.1.1. Klasa KlijentPumpa

Klasa KlijentPumpa (Sl. 6.2) je, kao što smo već rekli, glavna klasa u klijentskoj aplikaciji i

prva se pokreće. Ova klasa nasljeđuje klasu MIDlet i samim tim mora sadržavati neke metode

iz te klase. Uz to, ova klasa služi za inicijalizaciju atributa unutar aplikacije, pokretanje

prikaza za korisnika i definiciju nekih metoda koje se koriste u aplikaciji. Ova klasa sadrži

formu koja je zapravo ono što se na početku prikazuje korisniku, a sadrži izbornik kojim

korisnik odabire tvrtku čiju benzinsku crpku želi pronaći.

Sl. 6.2 Struktura klase KlijentPumpa

Klasa sadrži i metodu commandAction(Command command, Displayable form) koja se brine

o pokretanju određenih radnji unutar aplikacije nakon što korisnik odabere neku od ponuđenih

naredbi.

Metode koje klasa nasljeđuje od klase MIDlet su:

• startApp() – metoda koja se poziva kod pokretanja aplikacije i izvodi početne radnje

• pauseApp() – metoda koja se poziva kad aplikacija treba nakratko prekinuti s radom,

npr. ako korisnik prima poziv

• destroyApp – metoda koja se poziva prilikom izlaska iz aplikacije i najčešće služi za

oslobađanje resursa i spremanje podataka prije potpunog prekida rada aplikacije

44

6.1.2. Klasa Find

Klasa Find poziva se iz klase KlijentPumpa kao odvojena nit i služi za obradu korisničkog

zahtjeva za pronalaskom određene crpke i dohvat odgovora korisniku. S obzirom da se izvodi

kao nit, klasa implementira sučelje Runnable te metode start() i run(). Klasi se kao argument

predaje klasa KlijentPumpa, koja ju i poziva, te su na taj način ovoj klasi dohvatljivi podaci o

prikazu i izboru korisnika.

Sl. 6.3 Struktura klase Find

Nakon pokretanja ove niti otvara se TCP konekcija s poslužiteljem korištenjem socket-a kojeg

definira IP adresa i port. Za ovaj slučaj, IP adresa je localhost, a port je 1906. Nakon toga

dohvaća se identifikator ćelije jednom od dvije moguće metode. Metoda getLocationMD()

koristi se u slučaju kad se aplikacija izvršava na pokretnom uređaju, što korisnik odabire

istovremeno kad odabire tvrtku, i tada ona nasumice generira identifikator ćelije u rasponu od

1 do 132, s obzirom da je 132 broj ćelija u ovoj realizaciji. U slučaju da se aplikacija izvršava

na emulatoru na računalu, na osnovu korisničkog odabira, poziva se metoda getLocationEM()

u kojoj se identifikator ćelije dohvaća korištenjem sučelja WMA (Wireless Messaging API).

Pomoću njega simuliramo slanje CBS (Cell Broadcast Service) poruka od mreže koje sadrže

identifikator ćelije koji mi upisujemo [6].

Nakon toga dolazi do formiranja upita za poslužitelj u obliku "Tvrtka//ćelija" te slanje upita

na poslužitelj. Nakon što je poslužitelj završio obradu i poslao odgovor preko socket-a, dolazi

do obrade i razdvajanja primljenog sadržaja koji je stigao u obliku "Ime pumpe/Adresa#Grad"

te stvaranje nove forme unutar koje se prikazuju rezultati pretrage. Nakon ovoga, korisnik

može izaći iz aplikacije ili se vratiti na njen početak i zatražiti novu pretragu za neku drugu

tvrtku.

45

6.2. Opis rješenja poslužiteljske aplikacije

Poslužiteljska aplikacija predviđena je za izvođenje na poslužiteljskom računalu sa stalnim

pristupom Internetu. Njeno izvođenje mora biti stalno i neprekinuto kako bi usluga uvijek bila

dostupna. S obzirom da ovdje nismo ograničeni mogućnostima uređaja, poslužiteljska je

aplikacija izvedena standardnim Java jezikom tj. u J2SE (Java 2 Standard Edition). Glavna

zadaća poslužiteljske aplikacije je povezivanje s klijentom, primanje upita od klijenta te

stvaranje i slanje odgovora na primljeni upit. Kako se očekuje da aplikacija može primiti više

upita istovremeno, povezivanje s klijentom se vrši preko klase ServerSocket koja omogućava

primanje više korisničkih zahtjeva odjednom. Strukturu poslužiteljske aplikacije čine dvije

klase prikazane u međusobnom odnosu na slici (Sl. 6.4).

Sl. 6.4 Dijagram klasa poslužiteljske aplikacije

Kao što vidimo, glavna klasa u poslužiteljskoj aplikaciji je klasa PosluziteljPumpa, koja

osluškuje i prima korisničke zahtjeve, te klasa Worker koja vrši obradu korisničkih zahtjeva i

šalje odgovor natrag klijentu. Klasa Worker izvodi se kao nit i poziva se unutar klase

PosluziteljPumpa.

46

6.2.1. Klasa PosluziteljPumpa

Klasa KlijentPumpa je, kao što smo već rekli, glavna klasa unutar poslužiteljske aplikacije.

Struktura klase prikazana je na slici (Sl. 6.5). Klasa sadrži dvije metode: listen() i main().

Metoda main() služi za pokretanje same poslužiteljske aplikacije tj. stvaranje instance klase

KlijentPumpa te pozivanje metode listen(). Metoda listen() služi za stvaranje instance klase

ServerSocket te pokreće osluškivanje korisničkih zahtjeva. Kad stigne zahtjev od korisnika,

ostvaruje se TCP veza s klijentskom aplikacijom i pokreće nit Worker koja obrađuje zahtjev.

Sl. 6.5 Struktura klase PosluziteljPumpa

6.2.2. Klasa Worker

Klasa Worker poziva se iz klase PosluziteljPumpa kao odvojena nit i služi za obradu

korisničkog zahtjeva za pronalaskom određene crpke te pronalazi i šalje odgovor korisniku. S

obzirom da se izvodi kao nit, klasa nasljeđuje klasu Thread te implementira metodu run().

Klasi se kao argument predaje instanca s klase Socket, koja predstavlja vezu s klijentskom

aplikacijom, te je na taj način ovoj klasi omogućena komunikacija s klijentskom aplikacijom.

Nakon što je nit pokrenuta, prima upit od klijenta u obliku "Tvrtka//ćelija" te ga raščlanjuje na

dva dijela i poziva metodu makeResponse(int id, String celija) kojoj kao argumente predaje

oznaku tvrtke i oznaku ćelije u kojoj se nalazi korisnik. Ova metoda otvara vezu s bazom

podataka te joj postavlja upit na osnovu primljenih argumenata. Po primitku odgovora od

baze, raščlanjuje ga i formira odgovor za klijentsku aplikaciju u obliku "Ime pumpe:

ime/Adresa: adresa#Grad: grad" te prekida vezu s bazom. Nakon povratka u metodu run(),

odgovor se putem socketa šalje klijentskoj aplikaciji nakon čega se prekida veza s istom.

Sl. 6.6 Struktura klase Worker

47

6.3. Opis rješenja OTA poslužitelja

Pogledajmo što je sve nužno kako bi se ostvarila minimalna konfiguracija koja bi podržavala

OTA funkcionalnost. Sve što minimalna OTA konfiguracija zahtijeva je web poslužitelj koji

je ispravno konfiguriran za posluživanje različitog sadržaja, u našem slučaju JAD i JAR

datoteka. Konfiguriranje poslužitelja sastoji se od definiranja pripadnih MIME tipova za JAD

i JAR datoteke kao što je prikazano u tablici (Tablica 6.1).

Tablica 6.1 MIME tipovi potrebni za OTA-u

Datotečna ekstenzija MIME tip

JAD text/vnd.sun.j2me.app-descriptor

JAR application/java-archive

Poslužitelj s kojeg se preuzima aplikacija identificira ove datoteke postavljanjem HTTP

Content-Type zaglavlja na "text/vnd.sun.j2me.app-descriptor" za JAD i "application/java-

archive" za JAR datoteke. AMS koristi Content-Type zaglavlje kod otkrivanja aplikacije i

instalacije.

6.3.1. Konfiguriranje Apache web poslužitelja za OTA-u

Apache poslužitelj se konfigurira tako da se unutar datoteke mime.types, koja je obična

tekstualna datoteka i nalazi se u mapi conf, dodaju vrijednosti za JAD i JAR datoteke u

obliku:

MIME tip ekstenzija

Nakon što je datoteka spremljena, konfiguracija je završena.

48

6.4. Preuzimanje, pokretanje i rad s aplikacijom

Prije nego što opišemo korištenje same usluge, treba reći koja je sve programska podrška

potrebna kako bi se to ostvarilo. Kako bi ostvarili funkcionalnost OTA poslužitelja, trebamo

na računalu instalirati i pokrenuti Apache HTTP Server 2.0.55 te izvršiti potrebnu

konfiguraciju za OTA-u kako je opisano u dijelu 6.3.1. Potom je potrebno na taj isti

poslužitelj staviti web stranicu na kojoj se nalazi link na opisnik aplikacije, kao i sama

aplikacija.

Kako bi mogli testirati preuzimanje i korištenje klijentske aplikacije potrebno je na računalu

instalirati Sun Java Wireless Toolkit 2.3 Beta koji sadrži emulator pokretnog uređaja koji

podržava profil MIDP. Uz to, potrebno je i omogućiti izvršavanje Java aplikacija na računalu

pa je zbog toga potrebno instalirati okruženje za izvođenje Jave (engl. Java Runtime

Environment, skraćeno JRE), J2SE 1.4.2. Za rad poslužiteljske aplikacije potrebna nam je

baza podataka kao i poslužitelj baze podataka, a u tu svrhu koristimo MySQL Server 5.0.

6.4.1. Preuzimanje aplikacije

Kako bi demostrirali OTA funkcionalnost i preuzeli aplikaciju na uređaj, u ovom slučaju

emulator, trebamo nakon uspješne instalacije Sun Java Wireless Toolkit 2.3 Beta učiniti

sljedeće:

• Kliknuti na ikonu Start u Windows-ima

• Odabrati All Programs, pa Sun Java Wireless Toolkit 2.3 Beta

• Odabrati OTA Provisioning

Nakon što smo ovo napravili otvara se prozor kao na slici (Sl. 6.7). Na emulatoru je u tom

trenutku označena opcija Install Application, što nama i treba, te tad kliknemo na opciju Menu

nakon koje se otvara pop-up meni u kojem odaberemo opciju Launch kao na slici (Sl. 6.8).

Sada nam se otvara prikaz u kojem je potrebno unijeti adresu OTA poslužitelja. U ovom

slučaju adresa je localhost pa to i unosimo, te opet odabiremo opciju Menu i u novom pop-up

prozoru odabiremo opciju Go kao što se vidi na slici (Sl. 6.9). Nakon toga pokreće se spajanje

na poslužitelja i otvara se stranica s ponuđenim MIDlet-ima, u ovom slučaju samo jednim koji

se zove Pumpe. Označavamo MIDlet Pumpe i odabiremo opciju Install kao na slici (Sl. 6.10).

49

Sl. 6.7 OTA Provisioning 1 Sl. 6.8 OTA Provisioning 2

Sl. 6.9 OTA Provisioning 3 Sl. 6.10 OTA Provisioning 4

50

Ovime smo pokrenuli proces instalacije tijekom kojeg nas se još jednom pita za njenu

potvrdu, što i činimo odabirom opcije Install. Potom dolazi do preuzimanja aplikacije s

poslužitelja te njene instalacije na emulator, nakon čega je postupak završen i aplikacija je

ponuđena korisniku za pokretanje.

6.4.2. Pokretanje poslužiteljske aplikacije

Prije pokretanja klijentske aplikacije, potrebno je pokrenuti poslužiteljsku aplikaciju. Ona se

pokreće klikom na ikonu start koja se nalazi u mapi PosluziteljPumpa. Nakon klika na ikonu

start, otvara se prozor poslužiteljske aplikacije kao na slici (Sl. 6.11).

Sl. 6.11 Prozor poslužiteljske aplikacije

6.4.3. Pokretanje klijentske aplikacije i demonstracija usluge

Klijentsku aplikaciju pokrećemo u već otvorenom OTA Provisioning prozoru, tj. emulatoru,

označavanjem aplikacije KlijentPumpa u glavnom izborniku te odabirom opcije Menu i opcije

Launch u pop-up prozoru koji se pojavljuje nakon odabira opcije Menu. Ovaj postupak

prikazan je na slici (Sl. 6.12). Nakon što smo pokrenuli klijentsku aplikaciju, potrebno je

pokrenuti aplikaciju KToolbar do koje se dolazi na isti način kao i do aplikacije OTA

Provisioning tj. Start / All Programs / Sun Java Wireless Toolkit 2.3 Beta / KToolbar. U

KToolbar-u odaberemo izbornik File te unutar njega opciju Utilities nakon čega se otvara

51

prozor prikazan na slici (Sl. 6.13). U tom prozoru odabiremo opciju Open Console u dijelu

WMA nakon čega se pojavljuje prozor prikazan na slici (Sl. 6.14).

Sl. 6.12 Pokretanje klijentske aplikacije Sl. 6.13 Prozor Utilities

Sl. 6.14 WMA konzola

52

Ova konzola nam služi za slanje CBS poruka, u kojima se nalaze identifikatori ćelija,

klijentskoj aplikaciji. Sada možemo demonstrirati rad aplikacije tj. lokacijske usluge.

Pokretanjem klijentske aplikacije prikazuje nam se prozor na slici (Sl. 6.15). U njemu pomoću

navigacijske tipke možemo odabrati tvrtku čiju crpku želimo pronaći i slučaj korištenja

aplikacije. Potonje se odnosi na pitanje koristi li se aplikacija na emulatoru ili pokretnom

uređaju korisnika što mijenja način dohvata identifikatora ćelije. U ovom slučaju odabrat

ćemo opciju Emulator, a za tvrtku ćemo odabrati opciju INA i nakon toga kliknuti na opciju

Pronađi. Ovime smo pokrenuli traženje najbliže crpke i sada aplikaciji trebamo poslati

identifikator ćelije. To činimo tako da u WMA konzoli odaberemo opciju Send CBS... i u

novootvorenom prozoru u rubriku Message Identifier upišemo 50, a u rubriku Message broj

ćelije od 1 do 132, na primjer 99. Nakon toga kliknemo na opciju Send i poruka je poslana.

Ovaj postupak prikazan je na slici (Sl. 6.16).

Sl. 6.15 Odabir tvrtke i slučaja korištenja

53

Sl. 6.16 Slanje CBS poruke

Istovremeno se u klijentskoj aplikaciji prikazuju prozor i poruke prikazani na slici (Sl. 6.17).

Sl. 6.17 Traženje lokacije

54

U ovom koraku dolazi do komunikacije s poslužiteljem koji prima upit i šalje odgovor natrag

korisniku. U poslužiteljskoj aplikaciji se tada ispisuje ono što je prikazano na slici (Sl. 6.18).

Sl. 6.18 Obrada podataka na poslužiteljskoj aplikaciji

Nakon što klijent primi odgovor od poslužitelja na ekranu se prikazuju rezultati pretrage kao

što je prikazano na slici (Sl. 6.19).

Sl. 6.19 Prikaz podataka pronađene pumpe

55

Poslije ovoga, korisnik može izaći iz aplikacije odabirom opcije Izlaz ili se vratiti na izbor

tvrtke i slučaja korištenja, kako bi započeo novu pretragu, odabirom opcije Nazad.

Napomenimo još da je kod slučaja korištenja Pokretni uređaj jedina razlika u prikazu

korisniku ona kod traženja lokacije kad umjesto Pronašao lokaciju piše Generiram lokaciju.

56

7. Poslovni aspekti lokacijskih usluga

Pružatelji usluga su, potaknuti brzim porastom broja korisnika i širokim prihvaćanjem

pokretne telefonije i prijenosa podataka, željni iskorištavanja informacija o korisnicima, koje

su skupili tijekom vremena, kako bi njihovom uporabom ponudili dodatne usluge koje će im

povećati prihode, a korisnicima donijeti veće zadovoljstvo pri korištenju. Jedna od najvažnijih

informacija koje im pri tome mogu koristiti je lokacija korisnika koja je zbog svoje dinamike i

nepredvidivosti često bila problematična za određivanje. Ipak, potaknuto zakonskim

propisima i novim tehnologijama, određivanje lokacije postalo je s vremenom nešto lakše.

Tako su tehnologije poput GPS-a, identifikacije pokretnog telefona i mrežne triangulacije

omogućile operaterima točnije određivanje korisničke pozicije u fizičkom prostoru. Kako ove

tehnologije postaju sve pristupačnije, točnije i stvarnovremenske, pojavile su se razne

mogućnosti za nove usluge. Te usluge se nazivaju lokacijskim uslugama i predstavljaju

potencijalno važnu komponentu na području poslovanja u pokretnim komunikacijama. Ono

na što treba paziti kod ostvarivanja lokacijskih usluga je usklađenost između tehnološke

izvodivosti sustava i cjelokupne tržišne strategije koja će voditi njihovu uporabu [7].

Pružatelji lokacijskih usluga moraju se usredotočiti na stapanje programske i sklopovske

podrške te bežične povezivosti u plan za posluživanje lokacijski zavisnog sadržaja. U 4.

poglavlju smo već spomenuli postojeće metode lociranja korisnika, a odabir one koja će se

koristiti za ostvarivanje neke usluge zasniva se na tri strateški važna razmatranja:

• dometu pokrivenosti uslugom i skalabilnošću aplikacija

• stupnjem kvalitete usluge koji se može izvesti i održavati uz prihvatljiv trošak

• pažljivom usklađivanju cjelokupnih tehnoloških troškova s vrstom usluga koja će

ponuditi korisnicima

Kako bi razmotrili poslovne aspekte lokacijskih usluga, najbolje je usluge razvrstati po

vrstama korisničkih potreba koje trebaju ispuniti i vrsti informacija koje se mogu isporučiti u

danom prostoru i vremenu. Glavni voditelji korisničkih zahtjeva su globalno tržište, grupe

korisnika sa specifičnim zahtjevima te poslovni i industrijski korisnici. U tablici (Tablica 7.1)

su prikazane tipične usluge i poslovni modeli za ove kategorije korisničkih zahtjeva.

57

Tablica 7.1 Poslovni aspekti lokacijskih usluga

Razina zahtjeva Tipične usluge Tipični poslovni modeli

Korisnički zahtjevi:

Lokacija i navigacija

Personalizirani sadržaj

Karte, cestovne upute, "žute"

stranice

Pretplatnički zasnovane

usluge, plati-pa-gledaj model,

udruživanje, mikronaplata

Specijalizirani zahtjevi

korisnika i tvrtki

Karte, usluge lociranja

trgovina, kuponski popusti,

usluge upozorenja

Pretplatnički zasnovane

usluge/oglašavanja, podjela

prihoda, mikronaplata

Industrijski/korporacijski

zahtjevi

Upravljanje lancem dostave,

upravljanje inventarom,

upravljanje odnosima s

korisnicima, inteligentni

prijevoz, infrastruktura

sustava

Isporučitelj aplikacijske

usluge, savjetodavne usluge,

pružatelj infrastrukture

Promotrimo zasebno svaku od ovih razina zahtjeva i njihove karakteristike.

Lokacija i navigacija predstavljaju prvu vrstu korisničkih zahtjeva i najčešće se odnose na

korisnička pitanja "Gdje sam?" i "Kako da dođem tamo?". Odgovori na ova pitanja su razne

karte, cestovne upute, izlistavanja "žutih" stranica, podaci o tvrtkama u danom dometu i

slično. Ove vrste lokacijskih usluga su naročito pogodne za gusto naseljena i urbana područja

i povezujemo ih s fizičkim korisnikom, dok se u rijeđe naseljenim i ruralnim područjima

pruža mogućnost povezivanja usluge sa sredstvom prijevoza, najčešće autom, kao glavnim

uzročnikom promjene lokacije fizičkog korisnika. Pažljivom izvedbom usluga, za koju su

jako važne specifičnosti područja za koje se usluga izvodi, može se ostvariti značajni porast

korištenja lokacijskih usluga ove vrste te porast prihoda za pružatelje usluga što sve skupa

može voditi do porasta korištenja i ostalih lokacijskih usluga te njihovoj integraciji u

svakodnevnu uporabu.

Personalizirani sadržaj predstavlja drugu vrstu korisničkih zahtjeva i odnosi se na korisne,

korisnički definirane informacije koje se isporučuju po potrebi korisnika. Ovo uključuje

informacije o novim proizvodima, uslugama, promocijama i slično. Kako bi to bilo izvedivo,

kreatori usluga trebaju pristup podacima o interesima svakog korisnika. To mogu izvesti kroz

58

vlastitu bazu korisničkih profila ili u sklopu dogovora s pružateljem same lokacijske usluge.

Za uspjeh ovih usluga naročito će biti važan napredak u modularnoj programskoj podršci i

kodiranju te u mogućnostima alata za prilagodbu i personalizaciju sadržaja.

Specijalizirani zahtjevi korisnika i tvrtki su treća vrsta korisničkih zahtjeva i odnose se na

specijalizirane aplikacije ciljane za određene koncentrirane dijelove tržišta. Na razini

individualnih korisnika već postoje ili su razvoju određene specijalizirane usluge. Ciljane

skupine korisnika su, recimo, sportski entuzijasti, obitelji, ljudi koji provode puno vremena na

otvorenom, i njima isporučeni sadržaji bi bili izrazito bogati i usko fokusirani. Iako se možda

čini da se u ovom segmentu ne mogu ostvariti veći prihodi zbog manjeg broja potencijalnih

korisnika, probitak leži u lojalnosti korisnika te u tome da se bude prvi na određenom

području s obzirom da se veće tvrtke time vjerojatno neće baviti, a manje možda neće ni znati

za to.

Industrijske/korporacijske aplikacije su četvrta vrsta korisničkih zahtjeva od koje se

očekuje da zauzme značajan položaj na tržištu. Već sad postoje tvrtke koje koriste i

isporučuju lokacijski zasnovane tehnologije za praćenje materijala, ljudi i projekata

korištenjem inovativnih sredstava. Ovo se može pripisati postignutom razvoju u tri područja:

• široko prihvaćenom korištenju relativno jeftinih bar-kod čitača i bar kodova s kojih se

u zadnje vrijeme sve više prelazi na radio-frekvencijske identifikacijske čipove, (engl.

Radio-frequency identification, skraćeno RFID) a koji zbog svojih mogućnosti donose

prednosti u odnosu na bar kodove jer ih je moguće očitati s puno veće udaljenosti i bez

potrebe za direktnom vidljivosti, kao i zbog lakog ugrađivanja u razne objekte bez

narušavanja njihovog vanjskog izgleda [8]

• kombinaciji mrežne povezivosti, identifikacije i novih algoritama i tehnika

zaključivanja

• mogućnosti zaključivanja velike razine tj. konceptu inteligentne okoline koja će moći

"osjetiti" što kupcu treba i to mu isporučiti neovisno o vremenu i prostoru

Čak i korištenjem sadašnjih tehnologija, industrijski analitičari predviđaju značajan porast

korisničkih zahtjeva u područjima kao što su praćenje voznog parka, upravljanje

vrijednostima, sigurnost osoba i imovine, detekcija mrežnih kvarova i održavanje.

Ako promatramo lokacijsku uslugu razvijenu u ovom radu kroz ove razine zahtjeva i

poslovne modele, možemo je smjestiti u razinu korisničkih zahtjeva koji se odnose na

lokaciju i navigaciju. Poslovni model bi mogao biti specifičan po tome što je tvrtkama u

interesu da korisnik lako pronađe njihove crpke i time donese dodatan prihod, pa je posebnost

59

u tome da bi tvrtke trebale većim dijelom financirati korištenje usluge s obzirom da se radi o

formi oglašavanja koja će im donijeti višestruki prihod. To bi potaklo korisnike na češće

korištenje usluge koja bi se od njih naplaćivala u malim iznosima tj. modelom mikronaplate s

obzirom da je komunikacija ipak korisnički inicirana i da korisnik zauzima manji dio mrežnih

resursa.

60

Zaključak

U ovom diplomskom radu opisane su tehnologije koje omogućuju bežično pružanje usluga

pokretnim korisnicima te realizacija jedne lokacijske usluge koja se tim putem dostavlja

korisniku. Posebna je pozornost pridana bežičnom pružanju usluga unutar J2ME okruženja s

naglaskom na otkrivanje, preuzimanje i instalaciju usluge. Kao drugo moguće rješenje za

bežično pružanje usluga, opisan je protokol Push-OTA te dijelovi mrežne arhitekture potrebni

za njegovu izvedbu. Kod razvoja lokacijske usluge, pojavio se problem odabira metode

lociranja korisničkog pokretnog uređaja. Trebalo je odabrati metodu koja će za taj tip usluge

pružiti zadovoljavajuću razinu preciznosti i koja će zahtijevati što manju prilagodbu

korisničkog uređaja te koristiti postojeće mrežne mogućnosti. U radu je zato dan pregled

nekoliko najvažnijih metoda lociranja te se analizom došlo do zaključka da je najbolje

rješenje metoda identifikacije ćelije. Drugi problem koji se pojavio kod razvoja usluge bio je

kako povezati lokacijsku informaciju s traženim sadržajem. Kao očito rješenje, s obzirom na

moguću količinu sadržaja i ograničenost memorijskih kapaciteta pokretnih uređaja, nametnulo

se da se povezivanje odvija na udaljenom poslužitelju koji će upitima prema lokalnoj

relacijskoj bazi podataka dobiti traženi sadržaj i isporučiti ga natrag korisniku. Treći problem

je bio kako ostvariti komunikaciju između pokretnog uređaja i poslužitelja bežičnog pružanja

usluga te između pokretnog uređaja i poslužitelja lokacijske usluge. U oba slučaja se kao

rješenje ponudila komunikacija protokolom TCP/IP. U prvom navedenom slučaju to je

proizašlo iz same specifikacije bežičnog pružanja usluga, a u drugom se to ponudilo kao

najbolje rješenje s obzirom na prirodu usluge te potrebno vrijeme obrade na poslužitelju.

Praktična verifikacija navedenih rješenja provedena je izvedbom poslužitelja za bežično

pružanje usluga te lokacijske usluge koja korisniku dostavlja lokacijski zavisni sadržaj i koja

se na korisnički uređaj instalira korištenjem bežičnog pružanja usluga. Izvedena lokacijska

usluga spada u lokacijske informacijske usluge i lako se može prilagoditi i za pružanje neke

druge vrste informacijskog sadržaja. Također je provedena i analiza poslovne izvedivosti

lokacijskih usluga u općenitom smislu kao i usluge realizirane u ovom radu te su u tom

pogledu i predložena neka praktična rješenja.

61

Literatura

[1] Enrique Ortiz, C. 2002. Introduction to OTA Application Provisioning

http://developers.sun.com/techtopics/mobility/midp/articles/ota/

[2] Sun Microsystems 2002. Mobile Information Device Profile Specification v2.0

http://java.sun.com/j2me/download.html

[3] WAP Forum 2001. Push OTA Protocol

http://www.wapforum.org

[4] Sharad Chandra Agrawal 2003. Location Based Services

http://www.tcs.com/0_whitepapers/htdocs/atc/location_based_services_sep03.pdf

[5] Ladas, Edwards, Peersman 2001. Use of Wireless Application Protocol service

configuration provision over the Short Messaging System for nomadic device adaptation

http://www.cms.livjm.ac.uk/pgnet2001/papers/REdwards.zip

[6] Marin Vuković 2006. Isporuka lokacijski specifičnog sadržaja pokretnim korisnicima,

diplomski rad, Fakultet elektrotehnike i računarstva, Zagreb

[7] Bharat Rao, Louis Minakakis 2003. Evolution of Mobile Location-based Services

Communications of the ACM, Vol. 46, No.12

[8] Gaetano Borriello 2005. RFID: Tagging the World, Communications of the ACM,

Vol. 48, No.9

[9] Bažant, Lovrek, Mikac i drugi 2003. Osnovne arhitekture mreža

Element, Zagreb