Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
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
ii
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
1
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 lokacijski-
zasnovane 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.
2
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.
3
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
4
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).
5
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;
6
• 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.
7
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
8
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.
9
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
10
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.
11
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
12
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.
13
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:
<?xml version="1.0" encoding="UTF-8"?>
<sip-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jcp.org/xml/ns/sipservlet
http://www.jcp.org/xml/ns/sipservlet/sip-app_1_1.xsd"
version="1.1">
<display-name> SIP Primjer </display-name>
<description> primjer SIP konfiguracijske datoteke </description>
<servlet>
14
<servlet-name> SIPServlet1 </servlet-name>
<servlet-class>
seminar.SIPServlet1
</servlet-class>
</servlet>
<servlet>
<servlet-name> SIPServlet2 </servlet-name>
<servlet-class>
seminar.SIPServlet2
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name> SIPServlet1 </servlet-name>
<pattern>
<or>
<equal>
<var>request.method</var>
<value>MESSAGE</value>
</equal>
<equal>
<var>request.method</var>
<value>INVITE</value>
</equal>
</or>
</pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name> SIPServlet2 </servlet-name>
<pattern>
<equal>
<var>request.method</var>
<value>INVITE</value>
</equal>
</pattern>
</servlet-mapping>
</sip-app>
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.
15
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.
16
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
17
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: <sip:[email protected]>;tag=1982152035
Max-Forwards: 70
Cseq: 1 MESSAGE
Event: geolocation
18
To: <sip:127.0.0.1:6080>
Content-Type: text/plain
Via: SIP/2.0/UDP
192.168.1.2:5060;branch=z9hG4bKebf8eb1d4eeabb1cdcd2a96f0db5820f;receiv
ed=127.0.0.1
Call-Id: [email protected]
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: <sip:127.0.0.1:6080>;tag=fsuck844-1
Expires: 0
Cseq: 1 SUBSCRIBE
Contact: <sip:5.28.254.69:6080;fid=server_1>
Event: geolocation
To: <sip:[email protected]>
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: <sip:[email protected]>;tag=643a35df
Expires: 0
Cseq: 1 NOTIFY
Contact: "Location Server" <sip:127.0.0.1:6090;id=not>
Event: geolocation
To: <sip:127.0.0.1:6080>;tag=fsuck844-1
19
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: <sip:[email protected]>;tag=643a35df
Expires: 0
Cseq: 2 NOTIFY
Contact: "Location Server" <sip:127.0.0.1:6090>
Event: geolocation
To: <sip:127.0.0.1:6080>;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
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:shema-xsd:feature:v3.0">
<tuple id="5cdabb60">
<status><gp:geopriv><gp:location-info><gml:position><gml:Point
srsName="urn:ogc:def:crs:EPSG:6.6:4326"><gml:pos>45.802499999999995
15.9425</gml:pos></gml:Point></gml:position></gp:location-
info><method>manual</method><gp:usage-rules
/></gp:geopriv></status></tuple></presence>
Iz gore navedeno primjera druge NOTIFY poruke se može vidjet kako se informacije o
lokaciji prenose. Geografske koordinate korisnika nalaze se unutar taga <gml:pos>.
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: <sip:[email protected]>;tag=629134088
Cseq: 1 MESSAGE
Longitude: 15.9425
To: <sip:127.0.0.1:6080>
Server: Glassfish_SIP_1.0.0
Latitude: 45.802499999999995
Call-Id: [email protected]
Via: SIP/2.0/UDP
192.168.1.2:5060;branch=z9hG4bK5c3cdbc865fb28e17e0b705af9999c31;receiv
ed=127.0.0.1
20
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
21
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
22
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.
23
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.
<?xml version="1.0" encoding="UTF-8"?>
<sip-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jcp.org/xml/ns/sipservlet
http://www.jcp.org/xml/ns/sipservlet/sip-app_1_1.xsd"
version="1.1">
<display-name> Location Servlet </display-name>
<servlet>
<servlet-name> LocationServlet </servlet-name>
<servlet-class>
hr.fer.tel.seminar.LocationServlet
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name> LocationServlet </servlet-name>
<pattern>
<or>
<equal ignore-case="false">
<var>request.method</var>
<value>MESSAGE</value>
</equal>
<equal ignore-case="false">
<var>request.method</var>
<value>NOTIFY</value>
</equal>
</or>
</pattern>
</servlet-mapping>
</sip-app>
24
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.
25
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: J2METM 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.]
26
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
Register Local Default Domain. Na sljedećem ekranu je još samo potrebno upisati
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
27
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.