Lokacijska usluga za pokretne ureÄaje temeljena na ... - FER

Lokacijska usluga za pokretne ureÄaje temeljena na ... - FER Lokacijska usluga za pokretne ureÄaje temeljena na ... - FER

from tel.fer.hr More from this publisher

06.04.2015 Views

SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA SEMINARSKI RAD LOKACIJSKA USLUGA ZA POKRETNE UREĐAJE TEMELJENA NA PROTOKOLU SIP Matej Gjurković Mentor: Doc.dr.sc. Mario Kušek Zagreb, travanj 2009.

SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

SEMINARSKI RAD

LOKACIJSKA USLUGA ZA POKRETNE

UREĐAJE TEMELJENA NA PROTOKOLU

SIP

Matej Gjurković

Mentor: Doc.dr.sc. Mario Kušek

Zagreb, travanj 2009.

Sadržaj

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

1. Java na malim uređajima.................................................................................................... 2

1.1. Izvođenje Java aplikacija na malim uređajima .......................................................... 2

1.2. J2ME programska okolina ......................................................................................... 3

1.2.1. Connected Device Configuration....................................................................... 4

1.2.2. Connected Limited Device Configuration ......................................................... 5

1.3. MIDlet ........................................................................................................................ 6

2. Servlet................................................................................................................................. 9

2.1. SIP servlet ................................................................................................................ 10

3. SailFin .............................................................................................................................. 12

4. IMS Location Server ........................................................................................................ 15

5. Studijski slučaj usluge...................................................................................................... 17

5.1. Klijentska aplikacija................................................................................................. 20

5.2. Poslužiteljska aplikacija ........................................................................................... 22

6. Zaključak.......................................................................................................................... 24

Literatura .................................................................................................................................. 25

Dodatak A: Instalacija programske podrške ............................................................................ 26

Uvod

Napretkom telekomunikacijskih i pratećih tehnologija iste su postale pristupačne sve većem

broju korisnika. U današnje vrijeme je sve teže naći nekoga tko se ne služi računalima,

Internetom, a još je teže naći nekoga tko ne posjeduje mobilni telefon. Razvojem malih,

mobilnih uređaja, isti su izbili u prvi plan jer omogućavaju korisnicima da koriste usluge na

koje su navikli u pokretu. U skladu sa zahtjevima korisnika koji žele što više i povoljnije,

bogato su opremljeni različitim komunikacijskim i drugim tehnologijama koje omogućavaju

razvoj sve inovativnijih usluga. Kao primjer takvih usluga mogu poslužiti lokacijskizasnovane

usluge (engl. location based services) koje korisniku isporučuje razne informacije

zasnovane na lokaciji.

U ovom radu su obrađene neke od tehnologija koje se koriste za razvoj usluga kojima se

pristupa s malog uređaja. SIP (Session Initiation Protocol) [1] je postao ključni protokol u

telekomunikacijskim mrežama novije generacije, pogotovo dijelu jezgrene mreže IMS-u (IP

Multimedia Subsystem) [2], omogućujući usluge poput prijenosa govornih i video poziva,

video konferencija, prijenosa podataka, poruka, informacija o prisutnosti, video igara i dr. U

omogućavanju navedenih usluga veliku ulogu imaju SIP servleti [3] koji su zaduženi za

poslužiteljsku stranu sustava. Njihovo izvođenje ne bi bilo moguće bez aplikacijskih

poslužitelja na kojima se izvode pa je u radu obrađen i korišten SailFin [4] kao aplikacijski

poslužitelj. Sve to nema smisla ako korisnik ne može pristupiti navedenim uslugama. Stoga je

dio rada posvećen J2ME (Java 2 Micro Edition) [5] tehnologiji koja omogućava razvoj i

izvođenje klijentskih aplikacija na malim uređajima.

Cilj ovog rada je bio upoznati se sa svim navedenim tehnologijama i stečena znanja

primijeniti u izradi jedne lokacijski-zasnovane usluge.

1. Java na malim uređajima

Posljedica naglog razvoja mobilnih tehnologija u posljednje vrijeme je nastanak mnoštva

različitih malih uređaja prilagođenim svim vrstama korisnika i usluga. Upravo zbog te

raznolikosti malih uređaja, njihovih mogućnosti i operacijskih sustava i činjenice da je

neovisna o platformi Java je postala vodeći programski jezik za razvoj aplikacija za male

uređaje. Pošto mali uređaji imaju ograničenu procesorsku moć, ograničenu količinu memorije

te ograničenja ulazno-izlaznih jedinica, bilo je potrebno prilagoditi Java platformu da se može

izvoditi na takvim uređajima. Reducirana verzija Jave za male uređaje je Java 2 Micro

Edition (J2ME). Pod pojmom mali uređaji podrazumijevamo širok spektar uređaja s različitim

mogućnostima, među kojima su npr. mobilni telefoni, ručna računala (PDA), pametni telefoni

(engl. smart phones) i dr. S obzirom na raznolikost uređaja bilo je potrebno prilagoditi J2ME

programsku okolinu, što se postiglo definirajući različite konfiguracije, profile i dodatne

pakete koji su prilagođeni određenoj vrsti uređaja.

1.1. Izvođenje Java aplikacija na malim uređajima

Da bi se bolje razumjelo kako se Java izvodi na malim uređajima potrebno je prvo objasniti

proces nastanka Java koda i izvođenja na Java 2 Standard Edition (J2SE) platformi. Kao

vizualna pomoć može poslužiti Sl. 1.1.

Sl. 1.1 Razvoj i izvođenje J2SE aplikacija

Vidimo da se prvo napiše izvorni kod u nekom editoru. Prevodilac (engl. compiler) prevodi

taj kod u međukod koji se u Java svijetu zove bajt-kod (engl. bytecode). Važnost međukoda je

u činjenici da je prevodilac puno složeniji od pokretača aplikacija. Pošto se prevođenje odvija

samo jednom dobiva se na brzini izvođenja aplikacija. Također, takav međukod je neovisan o

platformi te se zbog toga može izvoditi na različitim operacijskim sustavima.

Javin pokretač aplikacija (engl. Java Application Launcher) pokreće okolinu za izvršavanje

aplikacija (engl. Java Runtime Environment, skraćeno JRE). JRE se sastoji od Java virtualnog

stroja (engl. Java Virtual Machine), jezgrenih klasa i pratećih datoteka i pruža minimalnu

okolinu potrebnu za izvođenje aplikacija. Zadaća pokretača aplikacija je da učita specificirane

klase te poziva odgovarajuću metodu main koja pokreće aplikaciju. Prilikom učitavanja klasa

Java virtualni stroj vrši verifikaciju međukoda.

Upravo je u verifikaciji međukoda glavna razlika između izvođenja aplikacija na malom

uređaju. Na Sl. 1.2 je prikazan proces razvoja Java aplikacije za mali uređaj. Može se

primijetiti da se procesorski najzahtjevniji dio obavlja na osobnom računalu na kojem se

razvija aplikacija. J2ME virtualni stroj vrši samo daleko jednostavnije, linearno pregledavanje

međukoda prilikom učitavanja klasa.

Sl. 1.2 Razvoj i izvođenje J2ME aplikacija

1.2. J2ME programska okolina

J2ME programsku okolinu čine konfiguracije, profili i dodatni paketi.

J2ME konfiguracije su specifikacije koje definiraju programsku okolinu za skup uređaja sa

zajedničkim karakteristikama poput:

• vrste i brzine procesora;

• vrste i količine memorije;

• vrsta mrežnih konekcija dostupnih malom uređaju.

Konfiguracija predstavlja minimalnu platformu za pojedinu skupinu uređaja, a sastoji se od

kombinacije Java virtualnog stroja i osnovnih biblioteka funkcija koje čine osnovu za razvoj

aplikacija namijenjenih nekoj vrsti uređaja.

U nastavku su detaljnije opisane konfiguracije Connected Device Configuration (CDC) [6] i

Connected Limited Device Configuration (CLDC) [7], te profili koji su dodani tim

konfiguracijama. Profili dodaju specifične biblioteke funkcija konfiguraciji ovisno o

konkretnoj vrsti uređaja i njegovoj namjeni.

1.2.1. Connected Device Configuration

CDC konfiguracija je definirana u JSR-36 i namijenjena je grupi jačih malih uređaja koji

imaju jači procesor, više memorije i bolji izbor konekcija. Ciljani uređaji kojima je

namijenjen CDC moraju imati 32-bitni procesor, najmanje 2MB RAM-a i 2.5MB ROM-a

raspoloživih za Java okolinu. Radi se o uređajima poput pametnih telefona, PDA uređaja,

telematičkih sustava ugrađenih u vozila, kućne elektronike i dr.

Java virtualni stroj je sličan onom iz J2SE platforme, no svojim zahtjevima prema resursima,

performansama i pouzdanošću prilagođen malim uređajima.

CDC ima bogatu biblioteku klasa koju minimalno čine:

• java.lang – sadrži klase potrebne za funkcioniranje Java virtualnog stroja;

• java.util – podskup općenitih metoda i sučelja iz J2SE ekvivalentnog paketa;

• java.net – sadrži klase i sučelja za rukovanje TCP/IP i HTTP protokolima;

• java.io – sadrži standardne klase za rukovanje ulazno-izlaznim jedinicama;

• java.text – sadrži minimalne klase potrebne za lokalizaciju i internacionalizaciju

aplikacije;

• java.security – sadrži osnovne klase i sučelja za implementaciju sigurnosti.

CDC podržava tri glavna profila i mnoštvo opcionalnih.

Tri glavna profila su:

• Foundation – biblioteka klasa zasnovanih na J2SE, ne sadrži podršku za GUI;

• Personal Basis – sadrži Foundation profil uz dodatak podrške za lagane (engl.

lightweight) komponente i Xlete koji su slični Java appletima no koji su dizajnirani

za izradu aplikacija za digitalnu televiziju;

• Personal – osim Personal Basis profila sadrži i punu podršku za GUI i applete.

Opcionalni paketi uvode dodatne funkcionalnosti koje se ne pojavljuju u osnovnim profilima

poput podrške za RMI (Remote Method Invocation) i JDBC (Java Database Connectivity).

1.2.2. Connected Limited Device Configuration

CLDC konfiguracija je definirana u JSR-30 i JSR-139 i namijenjena je grupi slabijih malih

uređaja koje karakterizira česti gubitak veze s mrežom, ograničena količina memorije, spori

procesori i jako ograničene ulazno-izlazne jedinice. To su uređaji poput mobilnih telefona,

pagera i manje naprednih ručnih računala. Minimalni uvjeti koje moraju zadovoljavati su:

• 16 ili 32-bitni procesor brzine najmanje 16MHz;

• 160KB na raspolaganju za Java virtualni stroj i njegove pripadajuće biblioteke, od

kojih su 32KB izbrisive (engl. volatile) memorije, a ostalih 128KB neizbrisive

(engl. non-volatile) ;

• 192KB ukupno memorije dostupno Java okolini;

• mogućnost spajanja na mrežu.

CLDC konfiguracija se sastoji od virtualnog stroja nazvanog Kilobytes Virtual

Machine(KVM) veličine između 40 i 80KB, biblioteka osnovnih klasa iz J2SE, te dodatnih

klasa koje ne postoje u J2SE. Može se reći da je CLDC konfiguracija podskup CDC

konfiguracije, a sadrži sljedeće biblioteke klasa:

• java.io – sadrži podskup osnovnih klasa iz ekvivalentnog J2SE paketa;

• java.lang – sadrži klase potrebne za funkcioniranje Java virtualnog stroja;

• java.util – podskup općenitih metoda i sučelja iz J2SE ekvivalentnog paketa ;

• javax.microedition.io – klase za rukovanje ulazno-izlaznim jedinicama specifično

napravljene za CLDC konfiguraciju.

Za CLDC konfiguraciju postoji mnoštvo API-ja i profila, no detaljnije će biti opisan

najpopularniji među njima – Mobile Information Device Profile (MIDP) [8].

Trenutna verzija MIDP 2.0 definiran u JSR-118 je zamijenila MIDP 1.0 koji je bio definiran u

JSR-37, dodajući mu nove funkcionalnosti poput poboljšanog korisničkog sučelja, podrške za

multimediju i igre te bolju podršku za mrežne konekcije i sigurnost.

MIDP podržavaju svi noviji mobilni uređaji pa postoji široka baza korisnika aplikacija

zasnovanih na njemu. Razvijateljima aplikacija nudi mogućnosti manipuliranja kamerom,

GPS-om, konekcijama preko GPRS/EDGE tehnologije te uz prije navedeno ne čudi što je

upravo on danas najpopularniji profil.

Uvjeti koje uređaj mora zadovoljavati da bi se na njemu mogle izvršavati MIDP aplikacije su:

• ekran veličine 96x52 piksela;

• dubina prikaza boja od 1 bita;

• mora postojati tipkovnica ili ekran osjetljiv na dodir;

• 128KB za MIDP aplikacije;

• 8KB za trajno pohranjene podatke aplikacija;

• 32KB memorije za izvršavanje;

• dvosmjerna bežična mreža.

MIDP se osim osnovnih CLDC paketa sastoji i od niže navedenih:

• javax.microedition.lcdui – klase i sučelja za upravljanje prikazom;

• javax.microedition.rms – Record Management System (RMS) koji služi za trajno

pohranjivanje podataka;

• javax.microedition.midlet – klase i sučelja namijenjene stvaranju MIDP aplikacija.

1.3. MIDlet

MIDlet (skraćeno od Mobile Information Device Application) je aplikacija koja se izvodi na

uređajima koji podržavaju CLDC i MIDP. Jedan ili više MIDleta pakiranih u jedan JAR (Java

Archive) čine MIDlet Suite.

Razvojni ciklus MIDleta sastoji se od pet ili šest faza. To su redom:

• pisanje koda – nužno je prvo proučiti dokumentaciju i naučiti se služiti

bibliotekama dostupnim za razvoj MIDleta;

• prevođenje koda u međukod – prevođenje vrši prevodilac (javac), rezultat

prevođenja su .class datoteke;

• predprovjera koda – traže se reference na klase koje MIDP ne podržava; cilj je

smanjiti opterećenje KVM prilikom izvršavanja MIDleta jer on mora samo linearno

provjeriti kod što ne traži puno resursa;

• pakiranje u JAR – izvršne datoteke se pakiraju u jednu zajedničku datoteku u ZIP

formatu;

• stvaranje JAD datoteke – tekstualna datoteka koja služi za opis aplikacije;

• potpisivanje MIDleta – uvedeno od verzije MIDP 2.0; olakšava definiranje

sigurnosne politike izvršavanja MIDleta na malom uređaju, a korisniku olakšava

korištenje jer ne mora svaki put iznova odobravati pristup zaštićenim API-jima.

Svaki MIDlet nasljeđuje klasu javax.microedition.midlet.MIDlet koja definira tri apstraktne

metode i koje definiraju njegov životni ciklus (Sl. 1.3):

• pauseApp - MIDlet je inicijaliziran, no ne smije koristiti zajedničke resurse;

• startApp – normalno fukncioniranje MIDleta;

• destroyApp – završetak rada, oslobađanje svih resursa.

Sl. 1.3 Životni ciklus MIDleta

MIDlet se izvodi u okolini koju kontrolira aplikacijski upravitelj (engl. application manager).

Aplikacijski upravitelj je zadužen za instalaciju, izvršavanje, pauziranje i uništavanje MIDleta

te omogućavanje pristupa pojedinim MIDletima do izvršnih datoteka Java virtualnog stroja

odnosno CLDC-a. Također je zadužen i za dojavljivanje MIDletu ako se dogodi neki događaj

na što se onda u njemu pokreću određene metode.

Jedan takav događaj je i samo pokretanje MIDleta nakon kojeg će se pokrenuti metoda

startApp koja tipično pokreće početni prikaz za odabir opcija korisniku. Ako korisniku npr.

zazvoni mobilni uređaj, aplikacijski upravitelj će pozvati metodu pauseApp koja će zaustaviti

izvršavanje MIDleta. Moguća je situacija da MIDlet više nije potreban ili da nekoj

prioritetnijoj aplikaciji treba memorijski prostor – ukoliko se to dogodi, aplikacijski upravitelj

će pozvati metodu destroyApp čime će životni ciklus MIDleta biti završen.

MIDlet se distribuira na uređaj u JAR datoteci koja sadrži sve izvršne (.class) datoteke i ostale

za aplikaciju potrebne datoteke poput npr. slika i konfiguracijskih datoteka, no u pravilu

dolazi i sa JAD (Java Definition) datotekom koja opisuje MIDlet.

Da bi JAR datoteka bila izvršna, uz gore navedene datoteke, dolazi i posebna manifest

datoteka koja između ostalog govori koja je glavna izvršna datoteka. Manifest datoteka se

sastoji od više parova ime-vrijednost kojih ima devet, ali samo je šest obavezno. Ovako

izgleda jedna takva datoteka (manifest.mf):

Manifest-Version: 1.0

MIDlet-Vendor: Midlet Suite Vendor //isporučitelj

MIDlet-Version: 1.0.0 //verzija

MIDlet-1: LocationMIDlet,,hr.tel.fer.seminar.midlet.LocationMIDlet

//paket

MicroEdition-Configuration: CLDC-1.1 //vrsta konfiguracije

MIDlet-Name: LocationMIDlet Midlet Suite //ime

MicroEdition-Profile: MIDP-2.0 //vrsta profila

JAD datoteka se koristi za prosljeđivanje parametara MIDletu bez modificiranja JAR datoteke

i za pružanje dodatnih informacija o JAR datoteci aplikacijskom upravitelju koje mu između

ostaloga govore može li se MIDlet pokrenuti na dotičnom uređaju.

Struktura unutar JAD-a je slična kao kod manifest datoteke, a neka polja poput imena, verzije

i isporučitelja moraju odgovarati onima iz manifest datoteke.

Jedna takva datoteka (LocationMIDlet.jad) izgleda ovako:

MIDlet-1: LocationMIDlet,,hr.tel.fer.seminar.midlet.LocationMIDlet

//paket

MIDlet-Jar-Size: 4306 //veličina JAR datoteke

MIDlet-Jar-URL: LocationMIDlet.jar

MIDlet-Name: LocationMIDlet Midlet Suite

MIDlet-Vendor: Midlet Suite Vendor

MIDlet-Version: 1.0.0

MicroEdition-Configuration: CLDC-1.1

MicroEdition-Profile: MIDP-2.0

Polje MIDlet-Jar-URL je zanimljivo jer omogućava da se na malom uređaju pokrene samo

JAD datoteka, a da se JAR naknadno skine preko mreže.

2. Servlet

Servleti [9] su komponente napisane u Javi koje se izvode na poslužiteljskoj strani i koje

dinamički obrađuju zahtjeve klijenata i stvaraju odgovarajuće odgovore na te zahtjeve.

Ubrzo nakon što se Web počeo koristiti za usluge, prepoznata je potreba za stvaranje

dinamičkog sadržaja. Jedan od prvih pokušaja u ostvarivanju tog cilja su bili Java appleti koji

su se izvodili na klijentskoj strani i omogućavali interakciju s korisnicima. Otprilike u isto

vrijeme su se počele koristiti CGI (Common Gateway Interface) skripte koje su se izvodile na

poslužiteljskoj strani i omogućavale dinamičko generiranje sadržaja. Iako vrlo popularne,

imale su mnogo nedostataka poput ovisnosti o platformi te loše skalabilnosti. Upravo da bi se

riješili ti problemi razvili su se servleti koji su pružali dinamički sadržaj, a mogli su se

izvoditi na različitim platformama.

Kao i svaki drugi Java kod, da bi se mogao izvršavati servlet se mora prevesti u međukod.

Servleti se izvršavaju na aplikacijskom poslužitelju koju učitava i pokreće datoteke servleta.

Dio aplikacijskog poslužitelja koji upravlja životnim vijekom servleta, prihvaća zahtjeve od

klijenata i šalje odgovore generirane u servletu naziva se servlet kontejner.

Servlet kontejner može biti ugrađen u poslužitelj ili instaliran kao njegova dodatna

komponenta, a izvoditi se može unutar istog procesa kao poslužitelj, drugog procesa unutar

računala ili na nekom drugom računalu.

Svaki servlet mora implementirati Servlet sučelje koje se nalazi unutar paketa javax.servlet.

To sučelje propisuje metode koje zapravo definiraju životni ciklus servleta koji se sastoji od

sljedećih koraka:

1. Servlet se instancira i učitava u kontejner prilikom pokretanja kontejnera.

2. Kontejner poziva init() metodu koja inicijalizira servlet. Metoda init() se pokreće

samo jednom, a nužna je da bi servlet mogao početi primati zahtjeve.

3. Normalni rad servleta. Servlet može primati zahtjeve koji se poslužuju u zasebnim

nitima. Servletu zahtjeve prosljeđuje kontejner koji prilikom dolaska zahtjeva

poziva metodu service() koja služi za razvrstavanje zahtjeva po tipu i koja zove

odgovarajuće metode zadužene za obradu tih zahtjeva. Za implementaciju tih

metoda je zadužen programer, a ukoliko to ne učini, pozvat će se metode nadklase

što će rezultirati slanjem poruke o grešci klijentu koji je poslao zahtjev.

4. Životni vijek servleta završava pozivanjem metode destroy() od strane kontejnera.

Metoda destroy() se kao i metoda init() poziva samo jednom.

Ilustraciju životnog ciklusa servleta možete vidjet na Sl. 2.1.

Sl. 2.1 Životni ciklus servleta

Servlet tehnologija je u početku razvijana za HTTP. Prvotna specifikacija servleta naglašava

da servlet kontejner mora podržavati HTTP protokol. Pošto se u ovom radu koriste SIP

servleti koji su slični HTTP servletima, objasnit će se njihov način rada, a eventualne razlike

između njih će biti spomenute.

2.1. SIP servlet

SIP servlet je komponenta temeljena na Javi kojom upravlja SIP servlet kontejner i koja se

koristi SIP signalizacijom. SIP kontejner prihvaća zahtjeve klijenata te ih prosljeđuje do

servleta koji generira odgovore i opet preko SIP kontejnera šalje natrag klijentima.

SIP specifikacija zahtjeva da SIP elementi podržavaju TCP i UDP transportne protokole, no

mogu podržavati i TLS, SCTP i ostale protokole za ugrađenim sigurnosnim mehanizmima.

SIP servlet kontejner osluškuje SIP promet na svojim priključnicama (engl. socket) koje

koriste gore navedene protokole te dobivene zahtjeve prosljeđuje servletu.

SIP Servlet API, slično kao i HTTP Servlet API, nadograđuje generički servlet API

javax.servlet, a nalazi se u javax.servlet.sip.

Glavnu razliku HTTP i SIP aplikacija čini činjenica da se SIP aplikacije mogu ponašati i kao

klijent i kao poslužitelj odnosno primati, ali i generirati zahtjeve, za razliku od HTTP

aplikacija koje su isključivo u klijent-poslužitelj odnosu.

SIP Servlet API između ostalog mora podržavati sljedeće mogućnosti:

• primanje odgovora i zahtjeva;

• slanje zahtjeva i odgovora – dodatno slanje višestrukih odgovora; npr. poruke 100

Trying, pa nakon toga 180 Ringing;

• preusmjeravanja zahtjeva uz mogućnost odabira više odredišnih destinacija.

SIP aplikacije se pokreću ako se dogodi događaj na koji su one registrirane. Ti događaji mogu

biti zahtjevi ili odgovori koje kontejner predaje aplikaciji preko service() metode koja se

nalazi u javax.servlet.Servlet sučelju. Metoda service() ustanovljuje radi li se o zahtjevu ili

odgovoru te ih na temelju toga prosljeđuje do doRequest(SipServletRequest request) ili do

doResponse(SIPServletResponse response) metode kako je prikazano na Sl. 2.2. Metode

doRequest i doResponse na temelju vrste zahtjeva ili odgovora pozivaju metodu koja je

zadužena za obradu tih događaja i koju je programer dužan implementirati. Metoda doRequest

prima objekt SipServletRequest koji predstavlja zahtjev, a za odgovor, odnosno objekt tipa

SipServletResponse se mora pobrinuti programer zbog zahtjeva komunikacije jedan na više.

Sl. 2.2 Obrada događaja kod SIP servleta

3. SailFin

SailFin je aplikacijski poslužitelj nastao spajanjem Ericssonove SIP Servlets tehnologije i

Sunovog GlassFish [10] aplikacijskog poslužitelja.

Sun GlassFish Enterprise Server je open source aplikacijski poslužitelj koji se razvija pod

nadzorom Sun Microsystema za Java Enterprise Edition platformu. Projekt je pokrenut kada

su Sun i Oracle donirali kod na kojem je temeljen razvoj GlassFisha. GlassFish je kao

besplatan softver pod dvije licence, CDDL [11] i GPL [12]. On kao poslužitelja Web

aplikacija koristi inačicu Apache Tomcata [13] sa dodatnom komponentom Grizzly koja je

zadužena za skalabilnost i brzinu izvođenja, dok je sustav za perzistenciju podatka preuzet od

Oracle TopLink [14] sustava.

Glavni cilj SailFin projekta je napraviti kontejner za SIP servlete koji će implementirati JSR-

289 [15]. Java Specification Request (JSR) je dokument koji Java Community Process (JCP)

podnosi Program Management Officeu (PMO), a u kojem se predlaže nova specifikacija ili

znatno poboljšanje stare specifikacije. JSR-289 definira poboljšanja specifikacije SIP Servlet

API-ja u skladu sa zahtjevima industrije te definira model međudjelovanja SIP Servleta s Java

EE (Enterprise Edition) komponentama.

U trenutnoj verziji SailFina je implementiran JSR-116 u kojem je definiran osnovni SIP

Servlet API, a na implementaciji JSR-289 se još uvijek radi.

SailFin omogućuje izvođenje konvergiranih aplikacija pošto njegov kontejner osim SIP

servleta podržava i HTTP servlete. Pod pojmom konvergiranih aplikacija se misli na one

aplikacije koje korištenjem više protokola omogućavaju telekomunikacijske usluge. Jedna

takva usluga bi na primjer mogla biti mogućnost pozivanja zaposlenika prilikom kupovine u

Web dućanu pritiskom na link u svrhu dobivanja dodatnih informacija o proizvodu.

Da bi se aplikacije mogle izvoditi moraju se poštivati određena pravila smještaja tih aplikacija

unutar strukture direktorija SailFina. Unutar direktorija SIP aplikacije mora postojati WEB-

INF direktorij unutar kojeg se nalazi sip.xml konfiguracijska datoteka. Izvršne datoteke se

smještaju u direktorij WEB-INF/classes, a sve ostale klase i biblioteke klasa koje aplikacija

koristi se smještaju u direktorij WEB-INF/lib.

Kako bi kontejner znao koji servlet treba pozvati nakon prispjelog zahtjeva, servleti se moraju

mapirati. Mapiranje se vrši unutar sip.xml.

Zahtjevi se razvrstavaju na temelju:

• Vrste zahtjeva

• Razlikovanja početnih i naknadnih zahtjeva, te početnih i naknadnih odgovora

• Korištenja logičkih operatora među poljima zaglavlja

Glavni dijelovi zahtjeva su:

• method – definira metodu zahtjeva;

• uri – URI zahtjeva;

• from – sadržaj From polja zaglavlja;

• to – sadržaj To polja zaglavlja.

Glavni dijelovi se mogu sastoji od više unutarnjih dijelova. Npr. from može biti SIP URI koji

se sastoji od scheme, user, host i port dijelova.

Logički uvjeti koji se mogu koristiti nad tim poljima zaglavlja i njihovim dijelovima su:

• equal – uspoređuje varijablu s nekim znakovnim nizom;

• exists – provjerava postoji li neka varijabla;

• contains – provjerava sadrži li neka varijabla određeni znakovni niz;

• subdomain-of – provjerava je li neki znakovni niz poddomena određenog URI-ja;

• and – provjerava jesu li svi uvjeti zadovoljeni;

• or – provjerava je li neki od svih uvjeta zadovoljen;

• not – negira vrijednost.

Važno je napomenuti da SIP kontejner poziva servlete po određenim pravilima. Prvo pravilo

je da se pozivaju svi servleti koji su mapirani na određenu vrstu zahtjeva ako oni

zadovoljavaju uvjete. Drugo pravilo je da se pozivaju onim redom kojim su navedeni u

konfiguracijskoj datototeci ako ih ima više koji zadovoljavaju uvjete.

Primjer jedne konfiguracijske datoteke izgleda ovako:

SIP Primjer

primjer SIP konfiguracijske datoteke

SIPServlet1

seminar.SIPServlet1

SIPServlet2

seminar.SIPServlet2

SIPServlet1

request.method

MESSAGE

request.method

INVITE

SIPServlet2

request.method

INVITE

U ovom primjeru možemo vidjeti kako u praksi izgleda mapiranje. Elementi display-name i

description služe za definiranje imena servleta koje će se pokazati i njegov opis. Unutar

elementa servlet se navode ime stvarnog servleta i njegova glavna klasa sa punom putanjom

do nje. Unutar elementa servlet-name potrebno je navesti točno ime servleta koje se mora

slagati s onim koje je navedeno prije u elementu servlet, dok se unutar pattern elementa

navodi uvjete koje zahtjev mora ispuniti da bi se pokrenuo dotični servlet. U ovom slučaju će

se zahtjevi doći do servleta SIPServlet1 ako su oni tipa MESSAGE ili INVITE, a do

SIPServlet2 ako su oni tipa INVITE. Na ovom primjeru se može vidjeti i kako se primjenjuje

pravilo pozivanja servleta u slučaju da više njih ima zadovoljava postavljene uvjete. Ako npr.

dođe INVITE zahtjev morat će se pozvati oba servleta jer oba zadovoljavaju uvjet, no pozivat

će se onim redom kojim su navedeni u konfiguracijskoj datoteci. Pošto je SIPServlet1

naveden prvi, u ovom slučaju će se prvo on pozvati, a tek nakon njega SIPServlet2.

4. IMS Location Server

IMS Location Server (ILS) je SIP aplikacijski poslužitelj razvijen u Ericsson Nikoli Tesli.

Njegova uloga u IMS-u je da služi kao spona sa sustavom za pozicioniranje. ILS nije

odgovoran za pronalaženje krajnje lokacije korisnika, već za saznavanje lokacije korisnika

slanjem zahtjeva do raspoloživog sustava za pozicioniranje.

Drugi aplikacijski poslužitelji kojima trebaju lokacijski podaci ne trebaju tako izravno

komunicirati sa sustavom za pozicioniranje već za njih to čini ILS koji zbog svojih ugrađenih

funkcionalnosti ne ovisi o pojedinim pružateljima usluga. ILS je prema tome omogućitelj

usluge (engl. service enabler).

ILS se trenutno sastoji od dva glavna dijela:

• Location Retrieval Function (LRF) – koristi se za dohvat lokacijskih informacija

preko SIP sučelja

• Position Manager – simulator sustava za pozicioniranje

Lokacijske informacije se prenose preko SUBSCRIBE/NOTIFY SIP komunikacijskog

mehanizma. IMS aplikacijski poslužitelji, klijenti i ostali IMS entiteti lokaciju korisnika

mogu zatražiti na više načina slanjem SUBSCRIBE zahtjeva ILS-u te primiti lokaciju:

• Jednokratno – nakon primanja zahtjeva ILS šalje trenutnu lokaciju korisnika;

Expire polje u zaglavlju zahtjeva se postavlja na 0,

• Periodično – nakon primanja zahtjeva ILS periodički šalje lokaciju korisnika;

Expire polje se postavlja na broj sekundi koje predstavljaju interval između slanja

lokacije korisnika,

• Uvjetno periodično – nakon primanja zahtjeva ILS periodički šalje lokaciju

korisnika ako je ispunjen određeni uvjet određen filterom; Expire polje se također

postavlja na broj sekundi koje predstavljaju interval između slanja lokacije

korisnika.

Prema preporuci IETF-a ILS koristi protokolno nezavisni format za prijenos lokacijskih

informacija - Presence Information Data Format (PIDF) zasnovan na XML-u. PIDF koristi

Geography Markup Language (GML) kao osnovni format zapisa lokacijskih informacija.

Position Manager unutar LIS-a služi kao emulator sustava za pozicioniranje. Lokacija

korisnika se može mijenjati pomoću miša, a moguće je dodavanje i brisanje korisnika te

dodavanje različitih mapa. Za dodavanje mapa je osim samih mapa u nekom slikovnom

formatu potrebno definirati koordinatama gornju lijevu i donju desnu točku koordinata u

posebnoj XML datoteci s ekstenzijom .map u direktoriju maps. Kako Position Manager

izgleda, može se vidjeti na Sl. 4.1.

Sl. 4.1 Position Manager

5. Studijski slučaj usluge

Seminarski zadatak je bio napraviti jednostavnu lokacijski zasnovanu uslugu korištenjem

J2ME i SIP servlet tehnologije koja omogućuje korisniku da na zaslonu svog malog uređaja

primi informaciju o lokaciji na kojoj se trenutno nalazi.

Za realizaciju usluge LocationInfo bilo je potrebno napraviti klijentsku aplikaciju koja će se

izvršavati na malom uređaju i preko koje će korisnik zahtijevati i primiti uslugu te aplikaciju

na poslužitelju koja će primati zahtjeve od korisničke aplikacije, slati upite za lokacijom

korisnika do IMS Location Servera te vratiti korisniku njegovu lokaciju.

Slijedni dijagram na Sl. 5.1 prikazuje izmjenu poruka između pojedinih entiteta.

Sl. 5.1 Slijedni dijagram komunikacije

Komunikacija među entitetima realiziranim u usluzi se zasniva tek na malom podskupu

mogućnosti SIP protokola. Zbog jednostavnosti usluge nije bilo potrebno koristiti ništa osim

MESSAGE i SUBSCRIBE zahtjeva, obrade NOTIFY zahtjeva poslanih od strane IMS Location

Servera te slanja i primanja odgovora. Sljedeći primjeri poruka koje se šalju će pojasniti kako

je realizirana komunikacija.

Korisnikov upit za lokacijom se prenosi SIP zahtjevom tipa MESSAGE, a izgleda ovako:

MESSAGE sip:127.0.0.1:6080 SIP/2.0

Content-Length: 0

From: ;tag=1982152035

Max-Forwards: 70

Cseq: 1 MESSAGE

Event: geolocation

To:

Content-Type: text/plain

Via: SIP/2.0/UDP

192.168.1.2:5060;branch=z9hG4bKebf8eb1d4eeabb1cdcd2a96f0db5820f;receiv

ed=127.0.0.1

Call-Id: 78196c28baa627397d234a03753634b6@192.168.1.2

Zahtjev se šalje SailFin poslužitelju koji se nalazi na adresi 127.0.0.1:6080 i na kojem se

izvršava SIP aplikacija koja obrađuje zahtjeve što se vidi iz prve linije zahtjeva. Da bi

poslužiteljska aplikacija znala da se radi o zahtjevu za lokacijom postavlja se polje zaglavlja

Event na ključnu riječ geolocation. Osim toga, vrlo je bitno i polje From koje sadrži

korisnikov SIP URI na temelju kojeg će se pronaći njegova lokacija posredstvom ILS-a.

Kada zahtjev dođe do poslužitelja, on prepoznaje da se radi o zahtjevu za lokacijom korisnika,

te konstruira novi SIP zahtjev tipa SUBSCRIBE koji se šalje ILS-u. Taj zahtjev također ima

polje Event postavljeno na geolocation da bi ILS mogao prepoznati kao zahtjev za lokacijom.

Nakon što je prepoznao zahtjev, treba mu i korisnikov SIP URI na temelju kojeg će pronaći

njegovu lokaciju, a koji se mora nalaziti u polju To zaglavlja SUBSCRIBE poruke. Zahtjev

izgleda ovako:

SUBSCRIBE sip:127.0.0.1:6090 SIP/2.0

Max-Forwards: 70

From: ;tag=fsuck844-1

Expires: 0

Cseq: 1 SUBSCRIBE

Contact:

Event: geolocation

To:

Call-Id: 5.28.254.69_1_5472694183377990708

Kako je navedeno u poglavlju o ILS-u, polje Expire se postavlja na vrijednost 0, jer se tako

lokaciju korisniku dostavlja samo jednom.

ILS nakon SUBSCRIBE zahtjeva šalje dvije NOTIFY poruke kao što se može vidjeti u

slijednom dijagramu. Prva NOTIFY poruka sadrži pending status jer ILS prvo provjerava

postoji li korisnik s navedenim URI-jem i traži njegovu lokaciju. Poruka izgleda ovako:

NOTIFY sip:5.28.254.69:6080;fid=server_1 SIP/2.0

Content-Length: 0

Max-Forwards: 69

From: ;tag=643a35df

Expires: 0

Cseq: 1 NOTIFY

Contact: "Location Server"

Event: geolocation

To: ;tag=fsuck844-1

Subscription-State: Pending

Call-Id: 5.28.254.69_1_5472694183377990708

Via: SIP/2.0/UDP

127.0.0.1:6090;branch=z9hG4bK9772bd67897c4b15ba21005490a6a4c2

Nakon što nađe lokaciju korisnika šalje drugu NOTIFY poruku u kojoj se nalaze podaci o

lokaciji korisnika zapisani u PIDF odnosno GML formatu.

NOTIFY sip:5.28.254.69:6080;fid=server_1 SIP/2.0

Content-Length: 499

Max-Forwards: 69

From: ;tag=643a35df

Expires: 0

Cseq: 2 NOTIFY

Contact: "Location Server"

Event: geolocation

To: ;tag=fsuck844-1

Content-Type: application/pidf+xml

Subscription-State: terminated;reason=expired

Call-Id: 5.28.254.69_1_5472694183377990708

Via: SIP/2.0/UDP

127.0.0.1:6090;branch=z9hG4bKb4b47f0eb0eb144c6f96c00f75d38675

45.802499999999995

15.9425manual

Iz gore navedeno primjera druge NOTIFY poruke se može vidjet kako se informacije o

lokaciji prenose. Geografske koordinate korisnika nalaze se unutar taga .

Poslužitelj izvlači podatke o lokaciji iz primljenog zahtjeva te konstruira odgovor koji sadrži

te podatke i koji se šalje na adresu korisnika. Kako taj odgovor izgleda vidi se iz slijedećeg:

SIP/2.0 200 OK

From: ;tag=629134088

Cseq: 1 MESSAGE

Longitude: 15.9425

To:

Server: Glassfish_SIP_1.0.0

Latitude: 45.802499999999995

Call-Id: e10ee021ef75202baa3116618ad650fa@192.168.1.2

Via: SIP/2.0/UDP

192.168.1.2:5060;branch=z9hG4bK5c3cdbc865fb28e17e0b705af9999c31;receiv

ed=127.0.0.1

5.1. Klijentska aplikacija

Klijentska aplikacija (LocationMIDlet) je realizirana kao MIDlet. Sastoji se od jednostavnog

GUI-ja koji kroz dvije forme omogućava korisniku da unese svoj SIP URI i lokaciju

poslužitelja te vidi svoju lokaciju u obliku geografske širine i dužine te MessageSender klase

koja služi za stvaranje zahtjeva i primanje odgovora od poslužitelja. Tipičan primjer uporabe

klijentske aplikacije se može vidjeti na Sl. 5.2 i Sl. 5.3.

Sl. 5.2 Izbornik koji omogućava unos SIP URI-ja i adrese poslužitelja

Sl. 5.3 Ekran koji prikazuje korisniku njegove geografske koordinate

Za detekciju događaja koje je izvazvao korisnik kao i u svakom MIDletu je zadužena metoda

public void commandAction( Command c, Displayable d ) koja prima komandu koja sadrži

informacije o događaju i objekt tipa Displayable koji zapravo predstavlja trenutnu formu koja

je prikazana. Dan je samo kratki isječak koda da se bolje objasni kako metoda funkcionira:

else if ( d == initialForm )

{

if ( c == nextCommand )

{

msg = new MessageSender();

msg.start();

Display.getDisplay( this ).setCurrent( resultForm );

}

Ovaj dio koda je zadužen za pokretanje klase zadužene za slanje zahtjeva za lokacijom.

Vidimo da se slanje zahtjeva pokreće čim korisnik na formi za unos SIP URI-ja i adrese

poslužitelja stisne komandu next. Također, vidimo da se odmah prikazuje ekran sa

rezultatima. Klasa MessageSender je zadužena za slanje zahtjeva te primanje odgovora i

prikaz na ekranu. Da bi taj zadatak mogla izvršavati ona mora naslijediti klasu Thread da bi se

izvršavala neovisno o ostalim nitima, poput npr. GUI-ja, te implementirati

SipClientConnectionListener da bi mogla primiti odgovor od poslužitelja. Njime je definirana

metoda notifyResponse(SipClientConnection sc) koja služi za primanje odgovora.

Dio koda zadužen za slanje zahtjeva izgleda ovako:

try

{

//otvaranje konekcije prema poslužitelju

sc = (SipClientConnection) Connector.open( "sip:"

+ sailFinAdressField.getString() );

sc.setListener( this ); //osluškuje eventualni odgovor

sc.initRequest( "MESSAGE", null );//zahtjev tipa MESSAGE

SipAddress from = new SipAddress( sipAdressField.getString());

sc.setHeader( "From", from.toString() );

sc.setHeader( "Event", "geolocation" );//definiranje zahtjeva

sc.setHeader( "Content-Type", "text/plain" );

sc.send(); //slanje zahtjeva

}

Dio koda za primanje odgovora u metodi notifyResponse (poziva ju aplikacijski upravitelj):

try

{ //0 znači da je MIDlet odmah spreman primiti odgovor

boolean ok = sc.receive( 0 );

if ( ok )

{

//ispis na ekran

}

sc.close(); }//zatvaranje konekcije nakon primanja odgovora

5.2. Poslužiteljska aplikacija

Poslužiteljska aplikacija (LocationServlet) je realizirana kao SIP servlet. Kad dođe zahtjev

od korisnika za lokacijom SIP kontejner prosljeđuje zahtjev metodi doMessage

(SipServletRequest request) koja provjerava je li Event polje postavljeno na geolocation. Ako

je to slučaj, poziva metodu zaduženu za stvaranje SUBSCRIBE zahtjeva te stvara odgovor koji

će se kasnije nadopunjen podacima o lokaciji poslati natrag korisniku.

Odgovor se kreira na temelju zahtjeva na sljedeći način:

responseTo = request.createResponse(SipServletResponse.SC_OK);

Metoda zadužena za stvaranje zahtjeva je sendSubscribeMessage(SipServletRequest req):

try {

SipFactory factory = (SipFactory) getServletContext().

getAttribute("javax.servlet.sip.SipFactory");

MIDletAddress = req.getFrom().toString();

sailFinAddress = req.getTo().toString();

SipServletRequest request =

factory.createRequest(req.getApplicationSession(), "SUBSCRIBE",

sailFinAddress, MIDletAddress); //stvaranje zahtjeva

request.setRequestURI(factory.createURI(locationEnablerAddress));

request.setHeader("Event", "geolocation");

request.setExpires(0); //traži se samo jednokratno

dostavljanje lokacije

request.send();

}

Kada ILS pošalje odgovor, tj. NOTIFY poruku izvršava se doNotify(SipServletRequest req),

koja je zadužena za komunikaciju s ILS-om, odnosno za slanje odgovora korisniku:

req.createResponse(200).send(); //kreiranje odgovora ILS-u

if (!req.isInitial()) {//samo drugi NOTIFY nosi lokacijske podatke

try {

String gmlContent = new String((byte[])

req.getContent());

String position = XMLHelper.getTagContent(gmlContent,

"pos");

String[] temp = position.split(" ");

responseTo.setHeader("Latitude", temp[0]);

responseTo.setHeader("Longitude", temp[1]);

responseTo.send();

}

Klasa XMLHelper je pomoćna klasa koja na temelju teksta u xml formatu i naziva taga čita

vrijednost zapisanu unutar njega. Da bi se ona mogla izvoditi korištena je biblioteka JDOM

koja sadrži metode za manipulaciju xml podacima, poput parsiranja i ispisa.

Iz gore navedenog koda se jos može vidjeti kako se postavljaju zaglavlja odgovora koji se

šalje klijentu.

U pripadajućoj sip.xml datoteci na temelju koje SIP kontejner prosljeđuje upite

LocationServletu definirano je da se zahtjevi prosljeđuju jedino ako su tipa MESSAGE i

NOTIFY što se može vidjeti ispod.

Location Servlet

LocationServlet

hr.fer.tel.seminar.LocationServlet

LocationServlet

request.method

MESSAGE

request.method

NOTIFY

6. Zaključak

Izrada ovog seminarskog rada je obuhvatila upoznavanje sa osnovnim tehnologijama koje se

koriste za razvoj klijentskih i poslužiteljskih aplikacija temeljenih na Java programskom

jeziku i SIP-u kao protokolu zaduženom za komunikaciju između njih.

Za izradu klijentske aplikacije je korištena J2ME platforma koja kroz svoje API-je nudi

bogate mogućnosti od kojih su tek malobrojne u ovom radu iskorištene. Za izradu

poslužiteljske aplikacije bilo je potrebno naučiti raditi sa SIP servletima i aplikacijskim

poslužiteljom SailFinom na kojem se izvode servleti. Na primjeru komunikacije s ILS-om

dobivena je ideja kako izgleda komunikacija u realnoj mreži sa sustavima za pozicioniranje.

Usluga LocationInfo kreirana kao praktični dio rada na seminaru je samo demonstracija

naučenih tehnologija, te se takvom mora i prihvatiti. S obzirom na tu činjenicu i na očekivani

opseg rada nije se išlo u rješavanje nekih problema koji bi se kod izrade realne usluge morali

riješiti, poput npr. registracije i autorizacije korisnika na poslužiteljskoj strani.

Usprkos vrlo ograničenoj uporabi korištenih tehnologija i alata, stečena su temeljna znanja

koja čine preduvjet za puno iskorištavanje potencijala tehnologija za izradu usluga i aplikacija

u novijim telekomunikacijskim mrežama.

Literatura

[1] RFC 3261 - SIP: Session Initiation Protocol, [http://tools.ietf.org/html/rfc3261,

28.3.2009.]

[2] IP Multimedia Subsystem, [http://www.3gpp.org/ftp/Specs/html-info/23228.htm,

28.3.2009.]

[3] JSR 116: SIP Servlet API Version 1.0, [http://jcp.org/en/jsr/detail?id=116,

28.3.2009.]

[4] SailFin: SIP Servlet Container, [https://sailfin.dev.java.net/, 28.3.2009.]

[5] JSR 30: J2ME TM Connected, Limited Device Configuration, Java Community

Process, 2000, [http://jcp.org/en/jsr/detail?id=30, 28.3.2009.]

[6] JSR 36: Connected Device Configuration, Java Community Process 2005,

[http://jcp.org/en/jsr/detail?id=36, 28.3.2009.]

[7] JSR 139: Connected Limited Device Configuration 1.1, Java Community Process

2007, [http://jcp.org/en/jsr/detail?id=139, 28.3.2009.]

[8] JSR 118: Mobile Information Device Profile 2.0, Java Community Process, 2006,

[http://jcp.org/en/jsr/detail?id=118, 28.3.2009.]

[9] JSR 154: Java Servlet 2.4 Specification, [http://jcp.org/en/jsr/detail?id=154,

28.3.2009.]

[10] GlassFish – Open Source Application Server, [https://glassfish.dev.java.net,

28.3.2009.]

[11] Common Development and Distribution License, [http://www.sun.com/cddl/,

28.3.2009.]

[12] GNU General Public License, [http://www.gnu.org/licenses/licenses.html#GPL,

28.3.2009.]

[13] Apache Tomcat, [http://tomcat.apache.org/, 28.3.2009.]

[14] Oracle TopLink, [http://www.oracle.com/technology/products/ias/toplink/index.html,

28.3.2009.]

[15] JSR 289: SIP Servlet v1.1, [http://jcp.org/en/jsr/detail?id=289, 28.3.2009.]

Dodatak A: Instalacija programske podrške

Da bi se rad isprobao potrebno je slijediti sljedeće korake:

1) Stranice SailFin projekta skinut najnoviju verziju softvera (recimo da se radi o

SailFin 1.0, a skinuta datoteka da se zove sailfin-installer-v1-b60g-windows.jar).

Nakon toga se treba preko konzole (start->run pa upisati cmd i stisnuti ok)

pozicionirati u direktorij gdje se nalazi datoteka te upisati sljedeću naredbu:

java -Xmx256m -jar sailfin-installer-v1-b60g-windows.jar

2) Nakon toga se otvara prozor u kojem je potrebno povući desni slider do kraja te

označiti Enable autoupdate i stisnuti gumb Accept što će rezultirati otpakiravanjem

sadržaja JAR datoteke u direktorij SailFin.

3) Treba se pozicionirati u direktorij SailFin te upisati sljedeću naredbu da bi se SailFin

instalirao na računalo:

lib\ant\bin\ant -f setup.xml

4) Sljedeće je potrebno integrirati SailFin u NetBeans razvojnu okolinu. To se radi tako

što se pod oznakom services klikne desnom tipkom miša na Servers i tamo izabere

Add server. Na popisu je potrebno izabrati SailFin te u sljedećem koraku odabrati

direktorij u kojem je SailFin smješten pod Platform Location. Također, označite

lozinku (npr. adminadmin) i stisnuti gumb Finish čime je integracija gotova.

5) Za razvoj SIP servlet aplikacija postoji plug-in za NetBeans. Instalira se tako da se

ode na Tools->Plugins i nađe na popisu dostupnih pluginova SIP Projects, označi i

klike install.

6) Sada je potrebno pokrenuti poslužiteljsku aplikaciju na SailFinu. Treba otići na File-

>Open project te izabrati direktorij LocationApp koji dolazi s ovim radom te

desnim klikom na projekt izabrati opciju run. Time će se aplikacija prenesti na

SailFin i automatski pokrenuti.

7) Pod service->Servers kliknuti desnim klikom na SailFin te izabrati View Admin

Console nakon čega se u browseru otvara sučelje za upravljanje SailFinom. Treba

podesiti portove na kojima osluškuje SIP promet tako da se ode na Configuration-

>SIP Container i postavi SIP port na 6080 (može i neki drugi, no onda se mora i

svugdje tako postaviti). Nakon toga treba postaviti isti port i pod Sip Service-> SIP

Listeners -> sip-listener-1. Za lakše snalaženje može poslužiti Slika A.

Slika A Postavljanje SIP porta preko administratorskog sučelja

8) Nakon što je SailFin podešen potrebno je instalirati i podesiti IMS Location Server.

Instalacijsku datoteku koja dolazi uz rad potrebno je pokrenuti i slijediti korake dok

instalacija nije završena. Nakon toga je i ILS-u potrebno promjeniti port na kojem

osluškuje promet. Pozicionirajte se u direktorij /Ericsson Nikola Tesla/IMS Location

Server/res gdje ste instalirati ILS te otvorite u uređivaču teksta datoteku

configuration.properties. U njoj trebate naći javax.sip.PORT i postaviti ga na 6090.

ILS se pokreće dvoklikom na runLS.bat.

9) Zadnji korak je pokretanje klijentske aplikacije dvoklikom na LocationMIDlet.jad

datoteku koja dolazi s radom.

Lokacijska usluga za pokretne ureÄaje temeljena na ... - FER

Lokacijska usluga za pokretne ureÄaje temeljena na ... - FER ... View more Lokacijska usluga za pokretne ureÄaje temeljena na ... - FER

Delete template?

Save as template ?

Lokacijska usluga za pokretne ureÄaje temeljena na ... - FER

Lokacijska usluga za pokretne ureÄaje temeljena na ... - FER Lokacijska usluga za pokretne ureÄaje temeljena na ... - FER