SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

DIPLOMSKI RAD br. 924

Geoprostorni sustav objavi pretplati za

obradu toka senzorskih podataka

Luka Babić

Zagreb, lipanj 2015.

Svima koji su dali svoj doprinos na mom putu prema akademskoj tituli.

iv

Sadržaj

UVOD .................................................................................................................................... 1

1. OSNOVNI POJMOVI ................................................................................................... 3

1.1. Senzor, senzorske mreže i senzorska očitanja ....................................................... 3

1.2. Geolokacija ............................................................................................................ 3

1.3. GeoJSON ............................................................................................................... 4

1.4. Arhitektura klijent-poslužitelj ............................................................................... 6

1.5. Representational state transfer, REST ................................................................... 8

1.6. Komunikacija objavi-pretplati ............................................................................. 10

1.7. Mobilna aplikacija ............................................................................................... 11

2. OPIS PROBLEMA I ZAHTJEVA .............................................................................. 13

2.1. Opis problema ..................................................................................................... 13

2.2. Dodavanje konverzije .......................................................................................... 13

2.3. Vrste mjerenja i mjerne jedinice .......................................................................... 15

2.4. Dodavanje pretplate ............................................................................................. 15

2.5. Objava senzorskih očitanja .................................................................................. 16

2.6. Algoritam pretrage pretplata za pristigle objave ................................................. 18

2.7. Prosljeđivanje objave pretplatnicima................................................................... 20

3. IMPLEMENTACIJA .................................................................................................. 21

3.1. Java EE ................................................................................................................ 21

3.2. HTTP i REST sučelje .......................................................................................... 22

3.2.1. Dodavanje konverzije .................................................................................. 23

3.2.2. Dodavanje pretplate ..................................................................................... 25

3.2.3. Objava senzorskih očitanja .......................................................................... 27

3.2.4. Brisanje pretplata ......................................................................................... 29

3.2.5. Lista konverzija ........................................................................................... 30

v

3.2.6. Lista tipova senzora ..................................................................................... 31

3.2.7. Resetiranje poslužitelja ................................................................................ 32

3.3. Geotools i JTS ..................................................................................................... 33

3.4. Mehanizam obaviješćivanja korisnika................................................................. 35

3.4.1. Usluga Google Cloud Messaging ................................................................ 36

3.5. Mobilni uređaj kao senzor i aplikacija kao klijent .............................................. 37

3.5.1. Opis upotrebe aplikacije .............................................................................. 38

4. TESTIRANJE SUSTAVA I REZULTATI ................................................................. 44

4.1. Program za testiranje ........................................................................................... 45

4.1.1. Generiranje pretplata i objava ..................................................................... 45

4.1.2. Konzolni način rada ..................................................................................... 46

4.1.3. Testni način rada .......................................................................................... 47

4.2. Rezultati testiranja ............................................................................................... 50

4.3. Diskusija rezultata ............................................................................................... 56

ZAKLJUČAK ...................................................................................................................... 57

LITERATURA .................................................................................................................... 58

SAŽETAK ........................................................................................................................... 59

SUMMARY ........................................................................................................................ 60

1

UVOD

Današnji napredak tehnologije vidljiv je u mnogim područjima svakodnevnog

života. Napredak je primjenjiv kroz ostvarenje novih funkcionalnosti koje prije nisu bile

ostvarive kao i korištenje određenih rješenja u širem opsegu, zbog cjenovne pristupačnosti

uzrokovane napretkom tehnologije. Kao jedan primjer funkcionalnosti može se spomenuti

globalna mreža Internet. Internet je od svog nastanka, od mreže koja je povezivala svega

nekoliko računala evoluirao do razine da danas umrežava nekoliko milijardi uređaja na

svijetu. Kao posljedica takvog napretka, danas je razmjena informacija lakša i brža nego

prije. S druge strane, tehnološki napredak u svrhu smanjenja troškova proizvoda vidljiv je

u senzorskoj tehnologiji i mobilnim mrežama. Danas su senzorske jedinice koje mjere

zadanu veličinu, (npr. vlagu, temperaturu, buku) cjenovno pristupačnije nego prije.

Također posjeduju napredne mogućnosti poput komunikacije s ostalim senzorima ili

centralnim senzorskim čvorom, što im omogućuje prosljeđivanje izmjerenih veličina

zainteresiranim stranama. Tehnologije mobilnog pristupa Internetu donijele su mogućnost

povezivanja na Internet bez postojanja direktne žične infrastrukture između interesnih

skupina. Korist mobilnog pristupa može biti vidljiva u korištenju senzora i senzorskih

mreža koje su pozicionirane na udaljenim lokacijama s kojih se prikupljene informacije

prenose mobilnom mrežom. Prosljeđivanje informacija ostvaruje se povezivanjem senzora

u Internet stvari (Internet of Things), odnosno omogućavanjem pristupa globalnoj

internetskoj mreži temeljenoj na protokolu IP. Ako se uzme u obzir cjenovna pristupačnost

rješenja koje bi se na taj način moglo biti korišteno, kao i učestalost korištenja takvih

rješenja, postoji mogućnost izrade sustava koji bi mogli dohvaćati senzorske podatke i

prosljeđivati ih zainteresiranim stranama. Jedan od glavnih izazova koje treba riješiti je

omogućiti brzo i efikasno (što podrazumijeva razumno korištenje dostupnih resursa)

dostavljanje izmjerenih podataka stranama koje iskazuju interes za tim podacima. Također,

dobiveni senzorski podaci osim vrijednosti mjerene veličine najčešće uključuju i

geolokacijsku komponentu, koja ukazuje gdje je očitanje provedeno. Geolokacijska

komponenta može biti jedan od uvjeta na temelju kojeg zainteresirane strane mogu

definirati imaju li ili nemaju interes za određenim očitanjem.

Cilj ovog diplomskog rada je osmisliti, izraditi i testirati sustav koji omogućava definiranje

pretplata temeljenih na zadanim parametrima, prosljeđivanje objava zainteresiranim

2

pretplatnicima i definiranje novih vrsta očitanja kao i pripadajućih mjernih jedinica za koje

se mogu definirati pretplate.

U prvom dijelu biti će objašnjeni osnovni pojmovi potrebni za razumijevanje rada. Drugi

dio opisuje razradu problema. Treći dio donosi detalje implementacije sustava. Četvrti dio

opisuje proces pripreme podataka za testiranje, prikazuje rezultate testova te daje osvrt na

njih.

3

1. OSNOVNI POJMOVI

1.1. Senzor, senzorske mreže i senzorska očitanja

Senzor predstavlja uređaj koji ima mogućnost mjerenja određene karakteristika

stvarnog svijeta. Senzori se primjenjuju u mnoge svrhe, primjerice vojne, promatranje

okoliša, nadgledanje vremenskih nepogoda, prostorno istraživanje. Mehanizam koji je

temelj djelovanja senzora je detektiranje određenih događaja ili promjene u kvantiteti

promatranog svojstva, što za posljedicu ima odašiljanje električnog ili optičkog signala.

Valja napomenuti da ne odašilju svi senzori električni ili optički signal uslijed detekcije

svojstava okoline. Primjerice, barometar mehaničkom akcijom (pomicanjem kazaljke) na

vidljiv način pokazuje vrijednost izmjerenog tlaka zraka. Međutim, u ovom radu pod

pojmom „senzor“ pozornost ostaje na onim uređajima koji su kao rezultat očitanja

mjerenja u mogućnosti proizvesti signal koji se može koristiti u elektroničkoj obradi.

Senzorska mreža je računalno dostupni resurs velikog broja međusobno povezanih uređaja

koji koriste senzore za nadziranje uvjeta poput temperature, zvuka, tlaka na raznim

lokacijama. Senzorske mreže postale su dostupne uslijed zadovoljavanja određenih uvjeta

koji su kako slijede; dostupnosti velikog broja jeftinih, pametnih i dimenzijama skromnih

senzora, brzih i sveprisutnih uređaja za obradu informacija te bežičnih komunikacijskih

mreža.

U kontekstu ovog rada od iznimne je važnosti geolokacija senzorskog očitanja, jer je u

praktičnim primjenama osim vrijednosti očitanja veoma korisno znati i lokaciju gdje se

očitanje dogodilo. Primjerice, ako se radi senzor za detektiranje izljeva nafte u more, u

slučaju nesreće odgovorne službe mogu znati točnu lokaciju gdje treba reagirati.

1.2. Geolokacija

Pojam geolokacija označava lokaciju objekta u dvodimenzionalnom koordinatnom

sustavu koji predstavlja Zemljinu površinu. Geolociranje kao pojam uključuje proces ili

mogućnost određivanja točne lokacije navedenih objekata, kao i vrijednost dobivene

lokacije. U uskoj je vezi s korištenjem sustava za globalno utvrđivanje pozicije, uz

korištenje globalnih pozicijskih satelita (Global Positioning Satellite, GPS). Međutim,

4

često naglasak nije samo na dobivanju koordinata u prostoru, nego i na dobivanju lokacije

koja ima razumljivo značenje korisniku, primjerice određivanje ulice i kućnog broja.

Postoji nekoliko načina za utvrđivanje točne ili približne lokacije zadanog objekta:

Lociranje objekta korištenjem globalnog pozicijskih satelita

Lociranje uz pomoć radio-frekvencijskog spektra

U drugoj metodi, koriste se informacije iz obližnjih baznih stanica, te se uz pomoć

triangulacije približno određuje lokacija subjekta. Triangulacija je proces određivanja

lokacije točke u prostoru mjereći kut između dvije krajnje točke neke dužine, umjesto

direktnog mjerenja udaljenosti između zadane točke i rubova dužine.

1.3. GeoJSON

Postavlja se pitanje na koji način prikazati određenu dvodimenzionalnu

geometrijsku strukturu u prostoru. Također je problem valjan zapis lokacija zbog

projekcije karata [2]. Za potrebe ovog rada, koristi se već općeprihvaćena specifikacija

GeoJSON za prikaz raznih geografskih struktura pa se u ovom poglavlju opisuju

standardni elementi koji mogu biti korišteni prilikom definiranja spomenutih struktura.

GeoJSON je tekstualni format za prikaz jednostavnih geoprostornih podataka, temeljen na

formatu JSON (JavaScript Object Notation). Trenutna revizija formata je 1.0, s datumom

objave 16. lipnja 2008. Temeljni element na kojem se zasniva format je koordinata

(coordinate) koja je predstavljena poljem brojeva kojih ima dva u slučaju da se radi o

dvodimenzionalnom prostoru. Prvi broj predstavlja x koordinatu, a drugi broj y

koordinatu. Format podržava kodiranje raznih vrsta geografskih struktura, kao što su:

geometrija (geometry), oblik (feature) ili skupina oblika (feature collection). Geometrija

predstavlja oblik (shape) kao takav i ne sadrži nikakve dodatne informacije. Svaka

geometrija u GeoJSON zapisu predstavljena je sa ključevima tip (type) i koordinate

(coordinates), gdje su koordinate točke koje određuju pojedinu geometriju. Geometrija

sama za sebe ne sadrži dovoljno korisnih informacija, jer objekti u stvarnom prostoru često

imaju dodatne atribute koji ih pobliže opisuju. Iz tog razloga definira se oblik (feature),

struktura koja omogućava definiranje dodatnih atributa u formatu ključ ->

vrijednost. Svaki oblik sadrži tri obavezna ključa, tip (type), geometriju (geometry) i

5

dodatna svojstva (properties). Kolekcija oblika (feature collection) je struktura koja pod

ključem type ima vrijednost „featurecollection“ i dodatno definira skupinu oblika

(feature).

Za svaki GSON objekt nužno je definirati tip geometrije pod ključem type, a mogući

tipovi su:

točka (Point)

linija (LineString)

poligon (Polygon)

skup točaka (Multipoint)

skup linija (MultiLine)

skup poligona (MultiPoligon)

skup geometrija (GeometryCollection).

Točka – geometrija koja je predstavljena samo jednom koordinatom, koja predstavlja točku

u koordinatnom sustavu.

Linija – predstavljena nizom koordinata čija je duljina najmanje dva. Kod linije potrebno je

spomenuti i prsten-liniju (LineRing) koja sama po sebi nije geometrija, ali se koristi kod

definiranja poligona. Prsten-linija je vrsta linije koja sadrži minimalno četiri koordinate te

su prva i posljednja koordinata jednake.

Poligon – geometrija predstavljena nizom „prsten-linija“. Ukoliko jedan poligon sadrži

više prstenova, utoliko prvi prsten mora obuhvaćati sve ostale u tom poligonu.

Skup točaka – geometrija predstavljena nizom koordinata. Može se primijetiti kako je

„točka“, specijalan slučaj „niza točaka“, gdje je duljina niza koordinata jednaka jedan.

Skup linija – geometrija koja sadrži niz „linija“.

Skup poligona – geometrija čiji član coordinates sadrži niz poligona.

Skup geometrija – geometrijski objekt koji predstavlja kolekciju geometrijskih objekata.

Obavezni član mora biti „geometries“, čija je vrijednost niz geometrija definiranih kao

GeoJSON geometrijski objekt.

Dodatno uz geometriju, moguće je dodati proizvoljan broj parametara u obliku ključ

vrijednost.

6

Granični okvir (bounding box) je dodatna informacija o geometriji koju nije obavezno

uključiti u geometriju. Vrijednost graničnog okvira je niz duljine 2*n, gdje je n broj

dimenzija koje su predstavljene geometrijom. Za svaku os u prostoru navodi se prvo

najmanja, a potom najveća vrijednost. Poredak osi odgovara onom kojim su navedene

vrijednosti u geometrijama. Za referentni koordinatni sustav graničnog okvira pretpostavlja

se da odgovara referentnom koordinatnom sustavu GeoJSON objekta kojem pripada.

Primjer jednog valjanog GeoJSON objekta:

1.4. Arhitektura klijent-poslužitelj

Za sustav korišten u praksi, odnosno znanstvenim istraživanjima senzorskih

očitanja, od važnosti je mogućnost pristupa spremljenim podatcima. Za ispunjavanje

navedenih zahtjeva je prikladna arhitektura klijent-poslužitelj, gdje je klijent sudionik koji

pohranjuje i dohvaća senzorska očitanja, a poslužitelj sudionik koji zatražene informacije

čini dostupnima klijentu.

Arhitektura klijent-poslužitelj raspoznaje dva entiteta: klijenta i poslužitelja. Klijent je

sudionik koji traži uslugu od drugog sudionika - poslužitelja. S druge strane, poslužitelj

pruža dotičnu uslugu većem broju klijenata istovremeno. Komunikacija se odvija putem

poruka odnosno zahtjeva, koji se šalju od klijenta prema poslužitelju. Poslužitelj zaprima

zahtjev i ako ima slobodne resurse na raspolaganju kreće u obradu zahtjeva, u suprotnom

{

"type": "Feature",

"geometry": {

"type": "Point",

"coordinates": [125.6, 10.1]

},

"properties": {

"ime": "GeoJSON objekt"

}

}

7

zahtjev se stavlja u red čekanja te biva obrađen kada uvjeti na poslužitelju to dopuste.

Rezultat obrade zahtjeva je slanje odgovora od poslužitelja prema klijentu.

U sustavu za pretplaćivanje na senzorske objave i objavu senzorskih mjerenja razlikujemo

dva tipa klijenta, pretplatnike i objavljivače, koji imaju različite uloge. Međutim, u obliku

komunikacije između poslužitelja nema razlike u pristupu, taj dio je u potpunosti

transparentan.

Postoje varijacije dvoredne arhitekture, čija je razlika u količini posla koji se odrađuje na

klijentu. Razlikujemo arhitekturu s tankim klijentom i debelim klijentom. Tanki klijent na

svojoj strani izvršava jedino korisničko sučelje, dok se na strani poslužitelja izvršavaju

klijentski primjenski program, poslužiteljski primjenski program i baza podataka. U

slučaju debelog klijenta, klijentski primjenski program se ne izvršava na poslužitelju već

na klijentu. Za klijenta u razvijanom sustavu koji ima ulogu pretplatnika, može se smatrati

razmjerno tankim klijentom. Obrađenim podatcima sa poslužitelja on pristupa putem

korisničkog sučelja na mobilnoj aplikaciji i po potrebi šalje podatke poput novih

konverzija na poslužitelj. Senzorski uređaj se u potpunosti može smatrati tankim klijentom.

Izostanak korisničkog sučelja i činjenica da ne obrađuje podatke, već samo izmjerene

veličine objavljuje na poslužitelju, argument su za doneseni zaključak. Dodatno, uz

dvorednu arhitekturu opisanu u dosadašnjem dijelu poglavlja postoji i troredna arhitektura

klijent poslužitelj, Troredna arhitektura, uz klijenta i poslužitelja još ima izdvojenu bazu

podataka, koja komunicira jedino s poslužiteljem. Najčešće se troslojna arhitektura ili

općenito višeslojna arhitektura klijent poslužitelj koristi kako bi se omogućio neovisan

razvoj svake komponente u sustavu. Za mogućnost pohrane senzorskih očitanja, bolja je

troredna arhitektura klijent-poslužitelj, koja se može koristiti i za pretplaćivanje na

senzorska očitanja. Ipak, sustav koji se razvija u ovom radu kao spremište pretplata koristi

radnu memoriju te baza podataka nije prisutna. Razvijani sustav smatra se dvorednom

arhitekturom klijent-poslužitelj te nema predviđenu objavljenih senzorskih mjerenja, već se

radi o sustavu koji prosljeđuje pristigle objave do zainteresiranih sudionika u što kraćem

roku.

8

1.5. Representational state transfer, REST

REST je stil arhitekture za raspodijeljene sustave formalno definiran kao niz

ograničenja i dobrih praksi koje je potrebno poštovati prilikom izgradnje sustava. Pozitivan

rezultat koji se ostvaruje poštivanjem navedenih pravila je skup nefunkcijskih obilježja,

navedenih kasnije ovom poglavlju. Izgradnja pristupnih sučelja u razvijanom sustavu ima

dvije namjene; omogućiti objavu senzorskih očitanja na poslužitelj kao i pristup

spremljenim podatcima. Postojeće implementacije arhitekture REST tvore slabo povezane,

skalabilne i brze sustave, koji se mogu nastaviti nadograđivati bez gubljenja željenih

svojstava. Termin „slaba povezanost“ (loosely coupled) ovdje ne označava sporu razmjenu

informacija ili poteškoće u komunikaciji, već označava skrivanje implementacije

određenog procesa na nekom poslužitelju. Stoga, uslijed promjene u implementaciji, drugi

poslužitelji ne moraju raditi izmjene prilikom pristupanja dotičnom poslužitelju na kojem

su se dogodile izmjene. Ova karakteristika omogućava nadogradnju dijela sustava ili

dodavanja novih sudionika u proces bez da to uzrokuje promjene na postojećem dijelu

sustava, čime sustav koji se razvija u ovom radu može biti proširen dodatnim

funkcionalnostima ako se za to ukaže potreba.

REST je stekao popularnost jer je proces implementacije jednostavniji nego primjerice kod

protokola SOAP (Simple Object Access Protocol) ili protokola WSDL (Web Services

Desrciption Language). Za komunikaciju prilikom ostvarenja REST aplikacije najčešće se

koristi protokol za prijenos hiperteksta HTTP (Hyper Text Transfer Protocol). REST se

temelji na identifikaciji resursa, koristeći univerzalni identifikator – URI (Uniform

Resource Identifier). Spomenimo da je URI niz znakova koji se koristi za identificiranje

resursa, a najčešće se koristi na WEB-u.

Zahtjevi koje je potrebno ispuniti kako bi neki sustav bio kvalificiran kao REST

kompatibilan su:

klijent-poslužitelj – homogeno sučelje (uniform interface) odvaja klijente od

poslužitelja. Raspodjela odgovornosti, koja je bitna za komunikaciju između dva

sudionika u procesu, znači da se klijent ne brine o primjerice o procesu trajnog

spremanja podataka na poslužitelju, već je to isključivo odgovornost poslužitelja.

Također, nije odgovornost poslužitelja kako izgleda korisničko sučelje na klijentu

ili koje je trenutno stanje na klijentu već je to isključivo odgovornost klijenta. U

9

kontekstu mobilne aplikacije to bi znači da je odgovornost iste imati spremljene

informacije o primjerice vlastitom identifikatoru.

Bez očuvanja stanja (stateless) – komunikacija između klijenta i poslužitelja odvija

se u potpunosti bez pohrane trenutnog stanja klijenta na poslužitelju. Cilj je

prilikom svakog zahtjeva klijenta dostaviti sve potrebne informacije o svom stanju

kako bi poslužitelj mogao uspješno izvršiti zahtjev, a odgovornost je klijenta da

pohrani stanje trenutne sjednice. Ovaj zahtjev odnosi se primjerice na senzorske

uređaje koji prilikom svakog objavljivanja novih očitanja trebaju uključiti sve

nužne informacije o sebi.

Predmemorija (cache) – u sustavima kompatibilnima s REST-om, klijentima je

omogućeno kratkotrajno spremanje obrađenih zahtjeva. Kako bi to bilo moguće,

odgovori koji su dobiveni potrebno je označiti kao one koje je moguće kratkotrajno

spremiti ili ne (cacheable). Posljedica kvalitetno izbalansiranog sustava koji koristi

predmemoriju je mogućnost potpune eliminacije određenih zahtjeva prema

poslužitelju, čime se dodatno poboljšava skalabilnost i efikasnost sustava.

Slojevit sustav – klijent ne može razaznati je li spojen direktno na poslužitelj sa

kojeg želi dohvatiti podatke ili je prilikom dohvata zahtjev preusmjeren na nekoliko

poslužitelja u lancu obrade zahtjeva.

Homogeno sučelje je još jedan od temeljnih zahtjeva arhitekture REST koji

pojednostavljuje i razdvaja arhitekturu te omogućava da se dijelovi sustava razvijaju

neovisno jedan o drugome. Zahtjevi koje je potrebno ispuniti kako bi sučelje bilo

homogeno su:

Identifikacija resursa neovisno o njihovoj stvarnoj reprezentaciji

Izmjena resursa koristeći dotične reprezentacije

Hipermedij kao sredstvo predstavljanja stanja aplikacije

10

1.6. Komunikacija objavi-pretplati

Prilikom dizajniranja sustava, u što spada i komunikacija između sudionika, trebalo

je uzeti u obzir kako će sustav biti korišten i kojim će intenzitetom informacije biti

prosljeđivane između sudionika. Ispostavlja se da je model komunikacije objavi-pretplati

gotovo idealna paradigma za stvarnovremenski dohvat podataka za koje nije moguće

predvidjeti kada će biti dostupni. Upravo je takva priroda senzorskih očitanja u sustavu

koji se razvija te se u skladu s tim komunikacija prilagođava toj paradigmi.

Model komunikacije objavi-pretplati zasniva se na asinkronoj komunikaciji između

objavljivača (publishers) i pretplatnika (subscribers). Pretplatnici definiraju svoje interese

za informacijama u obliku pretplata, gdje imaju mogućnost specificirati koje vrste

informacija žele i u kojem slučaju dobivati. Objavljivači s druge strane, imaju mogućnost

definirati strukturu i sadržaj poruka koje žele objaviti u sustavu, kao atributne vrijednosti u

obliku ključ -> vrijednost. U daljnjem tekstu pobliže se objašnjavaju načini na

koje je moguće definirati pretplate i koje je dodatne uvjete moguće postaviti za svaku

pretplatu. Sustav objavi pretplati izlaže tri akcije kojima je moguće sudjelovati u sustav.

Dvije se odnose na pretplatnike, a jedna na objavljivače. Pretplatnik kao sudionik u sustavu

ima mogućnost definiranje pretplate i postavljanje iste u sustav. Iako se akcija sastoji od

dva koraka, promatramo ju kao cjelinu. Druga akcija koju može izvršiti pretplatnik je

odjava pretplate iz sustava. Kao posljedicu, pretplatnik nakon tog trenutka više neće

primati objave koje bi eventualno odgovarale pretplati koju je definirao.

Za definiranje pretplata koriste se četiri različita modela, a to su kako slijedi:

Pretplate temeljena na kanalima (channel based)

Pretplate temeljena na temama (topic based)

Pretplate temeljena na tipu (type based)

Pretplate temeljena na sadržaju (content based)

Dva najčešća načina definiranja pretplata su pretplate bazirane na temama i sadržaju

[3]. Kod prve vrste pretplata, sustav definira skup tema po kojima su objave kategorizirane.

Objavljivači u skladu s time imaju mogućnost stvoriti objavu te joj pridijeliti pripadnost

određenoj temi dodjeljivanjem tekstualne oznake ili identifikatora koji se odnosi na

dotičnu temu. Drugi najčešće korišten tip su pretplate bazirane na sadržaju i smatraju se

najopćenitijim vrstama pretplate. Osim što pretplatnik ima mogućnost definirati područje

11

interesa u obliku teme, dodatno može detaljno odrediti koje ga točno vrijednosti sadržaja

zanimaju. Primjerice, korisnik može definirati da ga zanimaju objave na temu

„koncentracija CO2 u atmosferi“, a dodatno ima mogućnost u pretplati temeljenoj na

sadržaju definirati i koje ga vrijednosti dotičnog parametra zanimaju. Takve pretplate

sadrže predikate kojima se uz pomoć imena atributa i operatora usporedbe (=, <, >, <=, >=)

definira područje interesa. Iz navedenog razloga, smatra se da su pretplate bazirane na

temama specijalan slučaj pretplata baziranih na sadržaju. Treći sudionik, uz objavljivače i

pretplatnike je sam sustav za obradu (middleware).

Arhitektura objavi-preplati sustava može biti izvedena centralizirano ili raspodijeljeno [4].

Bez obzira na to koja se izvedba koristi, bitno je za napomenuti da je proces zaprimanja,

filtriranja i dostavljanja objava pretplatnicima u potpunosti transparentan i za objavljivače i

za pretplatnike. Ni u kojem trenutnu objavljivači ne komuniciraju direktno s

pretplatnicima, niti pretplatnici posjeduju točnu informaciju o tome tko je objavio

pretplatu. Međutim za potrebe ovog rada potrebno je u sadržaj objave uključiti

identifikator objavljivača, iako se na ovaj način gubi anonimnost klijenta koji je proizveo

očitanje. Tako pretplatnik može provesti daljnje akcije koristeći spomenuti identifikator.

Mehanizam prosljeđivanja objava različit je za centraliziran i raspodijeljen sustav, pri

čemu efikasna implementacija raspodijeljenog sustava ovisi o izboru algoritma za

prosljeđivanje objava. U daljnjem radu koristi se centralizirana arhitektura sustava objavi

pretplati, ali se zainteresirani čitatelj može detaljnije informirati o implementaciji

raspodijeljenog sustava u [4].

1.7. Mobilna aplikacija

Pametni telefoni (smartphones) danas su postali široko dostupni te svakim danom

imaju sve više mogućnosti. Postalo je uobičajeno da uređaji u sebi imaju ugrađeno

nekoliko senzora kojima mogu mjeriti odabrani parametar u okolini, a samo dodavanje

novih senzora na uređaj danas ne predstavlja problem. Korisnici ih često imaju uz sebe pa

mogu služiti kao generatori senzorskih očitanja, s naglaskom na njihovu pokretljivost. Iz

istog razloga, opravdano je razvijati mobilne aplikacije kojima bi korisnik imao mogućnost

dobivanja informacija o senzorskim očitanjima koja ga interesiraju.

Mobilna aplikacija je računalni program koji je namijenjen pokretanju na pametnim

telefonima, tabletima (tablet computers) i ostalim mobilnim uređajima. Mobilne aplikacije

12

se u većini slučajeva razvijaju u programskim alatima koji su namijenjeni točno za

određenu platformu. Postoje međutim i programska okruženja koja omogućavaju razvoj

mobilne aplikacije u samo jednom programskom jeziku, a koja se potom može

pojedinačno razviti (deploy) za platformu po želji. U 2015. godini prema [4] su

najzastupljenije mobilne platforme, poredane po popularnosti su: Android (78%), iOS

(18%), Windows Phone (2.7%) i BlackBerry OS (0.3%).

Današnji mobilni uređaji posjeduju mogućnosti koje prije nisu bile izvedive ili uobičajene.

Ipak, brz pristup Internetu i mogućnost geolokacijskog pozicioniranja mobilnog uređaja u

prostoru je funkcionalnost koja je svakodnevna pojava.

13

2. OPIS PROBLEMA I ZAHTJEVA

2.1. Opis problema

Cilj ovog diplomskog rada je bio razviti sustav objavi-pretplati u kojem pretplate

mogu biti definirane kao geoprostorni objekti (linije, točke, poligoni) koje dodatno

specificiraju atributna svojstva za sužavanje područja interesa.

U ovom sustavu, korisnik ima mogućnost definirati nove vrste mjerenja, mjerne jedinice za

različite tipove mjerenja i formule za konverziju iz jedne mjerne jedinice u neku prethodno

već definiranu. Postojanje konverzija između mjernih jedinica pridonosi fleksibilnosti

sustava. Primjerice, omogućuje da senzorska očitanja u jednoj mjernoj jedinici dostupnoj

za taj tip mjerenja, budu proslijeđene onim pretplatama čija je mjerna jedinica drugačija od

mjerne jedinice objave. Naravno, samo ako postoji preklapanje u vrijednostima atributnih

komponenti objave i pretplate nakon konverzije u istu mjernu jedinicu.

2.2. Dodavanje konverzije

U sustavu je bilo potrebno osigurati dodavanje tipova mjerenja, mjernih jedinica i

formula za konverziju između mjernih jedinica. Prvo je bilo potrebno utvrditi koji su sve

podatci potrebni za potpuno definiranje konverzije. Zbog praktičnih razloga, resurs

konverzije je definiran kao niz ključ -> vrijednost atributa, pri čemu u nastavku

teksta navodimo ključeve unutar resursa. Svaka konverzija pripada određenoj vrsti

mjerenja, npr. temperaturi, koncentraciji plina u zraku, buci i slično. Prilikom definiranja

konverzije potrebno definirati tip mjerenja kojemu konverzija pripada. Stoga prvi ključ u

resursu u kojem definiramo konverziju je vrstaOcitanja. Nakon što je definirana

vrsta očitanja kojoj konverzija pripada, potrebno je odrediti izvorišnu mjernu jedinicu.

Drugi ključ u resursu koji definira konverziju je izMjerneJedinice. Nakon definirane

izvorišne mjerne jedinice, definira se i odredišna mjerna jedinica za određenu konverziju.

Dodajemo i treći ključ, uMjernuJedinicu. Kako bi resurs s kojim definiramo

konverziju bio potpun još nam nedostaje matematička formula koja opisuje odnos

odredišne mjerne jedinice i izvorišne. Treba imati na umu ograničenja programske

implementacije ovog dijela sustava, stoga je format formule takav da sadrži jednu

14

varijablu, koja mora biti vrijednost izvorišne mjerne jedinice i standardni matematički izraz

kojim se opisuje ovisnost odredišne mjerne jedinice o izvorišnoj. Stoga formula

predstavlja četvrti ključ resursa za definiranje konverzije.

Konačno, izgled resursa za definiranje konverzije je sljedeći:

Za ogledni primjer su stavljene vrijednosti „X“, „Y“, „Z“ i „formula za izračun“, ali se

podrazumijeva da će u stvarnoj primjeni umjesto tih biti neke smislene vrijednosti za

realne vrste mjerenja i mjerne jedinice.

Uz definirani format poruke, uvodi se i ograničenje u ponašanju prilikom dodavanja

konverzije. Ako se konverzija dodaje prvi put, ne postoji nikakvo posebno ograničenje za

dotični slučaj. Konverzija se sprema u sustav, pri čemu vrstaOcitanja,

izMjerneJedinice i uMjernuJedinicu jedinstveno određuju član formula.

Ovaj odnos između elemenata konverzije dolazi do izražaja u sljedećem slučaju. Ukoliko

se na sustavu doda nova konverzija i već postoji za dotičnu kombinaciju triju parametara,

utoliko se stara konverzija uklanja iz sustava te ju nova zamjenjuje.

Pseudokod opisanog postupka dodavanja konverzije:

„vrstaOcitanja“

„izMjerneJedinice“

„uMjernuJedinicu“

„formula“

Dobivene podatke pripremi za obradu na poslužitelju;

U spremištu konverzija provjeri postoji li konverzija definirana sa

vrijednostima identičnim onima dobivenima u prihavećenom zahtjevu na

poslužitelju, prilikom čega se formula ne uspoređuje;

Ako (postoji konverzija) {

Izbriši pronađenu konverziju;

}

U spremište konverzija dodaj novu konverziju zaprimljenu u zahtjevu;

15

2.3. Vrste mjerenja i mjerne jedinice

Može se primijetiti kako do sada nije bio specificiran način kako se dodaju nove

vrste mjerenja u sustav kao i mjerne jedinice. Međutim, prilikom razrade problema

primjećeno je kako ne postoji potreba za takvom akcijom. Vrste mjerenja i mjerne jedinice

implicitno se dodaju prilikom prethodno opisanog koraka, odnosno dodavanja konverzija.

Točnije, nakon što se konverzija doda u sustav, informacije o vrsti mjerenja i mjernim

jedinicama izvuku se iz resursa konverzije te se potom pohranjuju u sustav u repozitorij

vrsta mjerenja i mjernih jedinica.

2.4. Dodavanje pretplate

Nakon što je dovršen proces dodavanja konverzija, sljedeći korak koji je bilo

potrebno definirati je dodavanje pretplata od strane pretplatnika koji može biti bilo koji

subjekt koji ima interes za rezultate dostupnih senzorskih mjerenja. Uz standardne

atributne komponente pretplate koje se definiraju, za potrebe ovog sustava nužno je bilo

definirati i prostornu komponentu koja će biti element pretplate. Uloga prostornog

elementa pretplate je ograničiti interes pretplatnika na točno određeno geografsko područje

interesa, što ne bi bilo moguće koristeći standardne pretplate opisane u poglavlju 1.6. Jedan

od zahtjeva prilikom zadavanja zadatka je korištenje GeoJSON specifikacije za definiranje

prostornih oblika pa se koriste svi oblici definirani specifikacijom.

Kao i prilikom definiranje resursa za konverziju, elementi pretplate navodit će se u obliku

ključ -> vrijednost. Primarni element koji svakako treba biti uključen u resurs

preplate je identifikator pretplatnika. Pretplata kao takva ne bi imala smisla bez ovog

identifikatora jer u slučaju objave koja preklapa dotičnu pretplatu ne bi bilo moguće na

jedinstven način utvrditi kojem korisniku treba proslijediti objavu. Prvi ključ koji se

uključuje u pretplatu je id. Sljedeći ključ koji je potrebno definirati je vrsta mjerenja za

koju je korisnik zainteresiran, stoga drugi ključ koji se dodaje u pretplatu je

vrstaOcitanja. Pretplata treba sadržavati i mjernu jedinicu za koju je definiran

interval vrijednosti od interesa, koji je definiran u nastavku. Na temelju mjerne jedinice, u

procesu pretraživanja pretplata koje preklapaju senzorsku objavu može se odrediti je li

potrebno izvršiti konverziju vrijednosti objave ili mjerna jedinice objave odgovara mjernoj

jedinici pretplate. Treći ključ koji se dodaje u resurs pretplate je jedinicaOcitanja.

16

Zadnje dvije atributne komponente koje je potrebno definirati su donja i gornja granica

vrijednosti parametra za koji se objavljuje pretplata. S ova dva parametra se zapravo

definira predikat koristeći relacije „<=“ i „>=“. Preklapanje će se ostvariti ako vrijednost

objave bude veća ili jednaka od donje granice i manja ili jednaka od gornje granice. Četvrti

i peti ključ koji dodajemo u pretplatu su intervalDonji i intervalGornji.

Posljednji ključ pretplate koji treba uključiti je geometrija koja definira prostor na

kojemu postoji interes za senzorskim mjerenjima. Posljednji ključ koji se dodaje u resurs

pretplate je geometrija.

Kao rezultat dodavanja pretplate u sustava potrebno je pretplatniku vratiti povratnu

informaciju o uspješnosti postupka. Ovaj dio će biti detaljnije opisan u poglavlju 3.

2.5. Objava senzorskih očitanja

Sljedeći mehanizam koji je bilo potrebno specificirati je objava mjerenja od strane

objavljivača, što su u ovom slučaju senzori i senzorska mjerenja koja oni generiraju. Kao i

u slučaju pretplate, trebalo je definirati potrebne podatke koja svaka senzorska objava mora

sadržavati kako bi bilo moguće pronaći pretplate koje imaju definiran interes za pojedino

senzorsko očitanje.

Kako bi se senzor koji objavljuje podatke moglo identificirati na jedinstven način,

potrebno je uključiti identifikator senzora u objavu. Prvi član u resursu objave stoga je

ključ identifikatorSenzora. Objava od strane senzora dogodila se u određenom

vremenskom trenutku, stoga je razumno dodati u resurs objave vrijeme kada se dogodila.

Dodaje se drugi ključ kao resurs objave, vrijemeOcitanja. Lako je moguće određeni

fenomen mjeriti na više načina, odnosno različitim modelima senzora. U resurs objave

uključuje se i tipSenzora, odnosno oznaka koja pretplatniku pruža dodatnu informaciju

o tome koje su karakteristike senzora koji je stvorio objavu. Dakako, karakteristike nisu

uključene u navedeni ključ, međutim koristeći vrijednost ključa tipSenzora, pretplatnik

može saznati tražene informacije o senzoru. Primjerice minimalni interval očitanja,

preciznost i slično. Svaki senzor mjeri određenu pojavu, što je zapravo vrsta očitanja. Za

proces filtriranja pretplata, objava treba definirati i što je točno izmjereno, koja fizikalna ili

neka druga veličina. Sljedeći ključ koji je dodan u resurs objave je vrstaOcitanja.

Zbog zahtjeva sustava, koji omogućava definiranje pretplata u više različitih mjernih

jedinica, obavezno je bilo uključiti jedinicu očitanja senzora, što je sljedeći ključ u pretplati

17

jedinicaOcitanja. Senzorska objava također je trebala uključiti i vrijednost

mjerenog parametra. Kako se radi o numeričkoj vrijednosti, koristi se realni tip double, a

zapisuje se pod ključem vrijednost. Na kraju, objava je vezana uz neko geografsko

područje. Pretpostavka je da određeni senzori mogu mjeriti određeni parametar za šire

geografsko područje, dok su primjerice mjerenja drugih senzora manjeg geografskog

opsega. Zadnji element koji je uključen resurs je geometrija, odnosno geometrijska

komponenta koja opisuje područje na kojem se provelo određeno senzorsko mjerenje. Kao

i u slučaju definiranja pretplate, geometrija mora biti oblik definiran u specifikaciji

GeoJSON.

Konačno, resurs objave sadržava sljedeće ključeve:

Ako se želi postići preklapanje objave i definirane pretplate, treba zadovoljiti sljedeće

uvjete:

atributne vrijednosti objave trebaju preklapati definirane atributne predikate u

pretplati.

geolokacijska komponenta objave treba prostorno preklapati (intersect)

geolokacijsku komponentu pretplate

Za dodavanje novih oblika pretplate kod kojih su objave tekstualne datoteke, sustav se

može nadograditi. To je jednostavniji oblik pretplate od onih koje se opisuju u daljnjem

radu, jer je za preklapanje pretplate s objavom nužno da se preklapaju geolokacijske

komponente

„identifikatorSenzora“

„vrijemeOocitanja“

„tipSenzora“

„vrstaOcitanja“

„jedinicaOcitanja“

„vrijednost“

„geometrija“

18

2.6. Algoritam pretrage pretplata za pristigle objave

Nakon što su zadovoljeni svi uvjeti opisani u poglavljima 4.2, 4.3, 4.4, 4.5, sustav

može obavljati svoju funkciju. Potrebno je na kraju detaljno opisati kako izgleda proces

traženja pretplata koje odgovaraju pristigloj objavi. Proces je složeniji zbog činjenice da je

potrebno provjeriti i atributna i prostorna preklapanja pretplate s objavom. Postavlja se

pitanje kojim redoslijedom pristupiti filtriranju i koji su argumenti govore u prilog, a koji

protiv predloženog rješenja. U hipotetskom scenariju, pretpostavlja se da je promatrani

parametar primjerice temperatura. Za područje grada Zagreba prema [6] prosječne

minimalne zimske temperature su -3 stupnja Celzijeva, a prosječne ljetne temperature

iznose 27 stupnja Celzijevih. Temperaturni raspon između prosječne minimalne zimske i

prosječne maksimalne ljetne temperature iznosi 30 stupnjeva Celzijevih. U relativnom

uskom temperaturnom intervalu moguće je definirati potencijalno veliki broj pretplata. S

druge strane, područje grada Zagreba prema [7] iznosi 641 km2, te je prostor na kojem je

moguće definirati određenu pretplatu primjerice za vrijednost temperature nudi veću

granulaciju naspram prostora za definiranje temperature. Ovim kratkim promišljanjem

dolazi se do zaključka da je učinkovitije prvo filtrirati pretplate po geografskoj lokaciji,

tražeći preklapanja s područjem objave. U drugom koraku, sve dobivene pretplate koje su

dobivene kao rezultat prethodnog koraka treba usporediti po vrijednosti atributa sf

dobivenim atributima objave.

Postavlja se pitanje kako efikasno pretraživati veliki skup pretplata koristeći prostorne

predikate. Rješenje problema je prostorno indeksiranje, koje koristi određene

aproksimacije s ciljem brzog pretraživanja pretplata koje se preklapaju s područjem

određene objave. Sam proces odvija se u dva koraka. U prvom koraku se ne uzima točna

geometrija već aproksimacija određene geometrije, najčešće u obliku minimalnog

graničnog kvadrata (minimal bounding box) [8]. Koristeći minimalni granični kvadrat i

prostorne predikate, pronalazi se super-skup geometrija koje preklapaju geometriju s

kojom ih uspoređujemo. Koristi se termin super-skup, jer zbog korištenja aproksimacija

kao rezultati prvog koraka pojavljuju se i one geometrije koje ustvari ne preklapaju

geometriju s kojom se izvodio prostorni predikat. Tek se u drugom koraku, koji se zove

pročišćavanje (refinement) [8] uspoređuju geometrije sa prostornim predikatom odabrane

geometrije. Najčešće korištene strukture podataka za prostorno indeksiranje su rešetkasto

indeksiranje (grid indexing), Quad-stablo (quad tree) i R-stablo (R-tree). U trećem,

19

završnom koraku potrebno je provjeriti preklapanja atributnih komponenti pretplate i

objave.

Da bi se atributne komponente međusobno preklapale, potrebno je zadovoljiti sljedeće

uvjete:

vrsta očitanja objave treba odgovarati vrsti očitanja pretplate

vrijednost očitanja treba biti između donje i gornje granice promatranog atributa u

pretplati

Kada je algoritam gotov za izvršavanjem, dobiveni skup pretplata su one pretplate kod

kojih postoji i prostorno i atributno preklapanje s dobivenom objavom.

Pseudokod algoritma je sljedeći:

Iz pristigle objave dohvati geometrijsku komponentu;

Iz prostornog indeksa svih pretplata dohvati one koje se preliminarno preklapaju sa geometrijom objave;

Iz skupa dobivenih pretplata izbaci one pretplate kod kojih ne postoji egzaktno preklapanje sa geometrijom objave;

Za svaku objavu iz skupa filtriranih pretplata {

Ako (jedinica očitanja objave ne odgovara jedinici očitanja pretplate){

Preračunaj vrijednost očitanja u mjernu jedinicu pretplate;

}

Ako (vrijednost očitanja nije u intervalu pretplate) {

Ukloni pretplatu iz skupa mogućih pretpltata

}

}

Za svaku pretplatu u skupu mogućih pretplata {

Proslijedi očitanje korisnku koji je definirao pretplatu.

}

20

2.7. Prosljeđivanje objave pretplatnicima

Svim pretplatama koje su sadržane u skupu koji je rezultat algoritma, opisanog u

poglavlju 4.5, treba proslijediti odgovarajuću pretplatu. Prema [4], neučinkovito je rješenje

ako klijent, odnosno pretplatnik u kontekstu ovog rada, periodički upućuje zahtjev na

poslužitelj s ciljem provjere je li u međuvremenu pristigla objava koja preklapa područje

interesa pretplate. Takav način komunikacije zove se model pull. Efikasnije rješenje je

model komunikacije push u kojem poslužitelj prosljeđuje podatke klijentu kada su uvjeti za

to zadovoljeni, odnosno kada se dogodi preklapanje pretplate i objave. Zapravo se radi o

modelu objavi-pretplati koji je prepoznat kao najbolja paradigma za prijenos informacija sa

stvarnovremenskim svojstvima.

21

3. IMPLEMENTACIJA

U ovom poglavlju objašnjavaju se detalji implementacije programskog rješenja u

skladu sa zahtjevima predstavljenima u poglavlju 2. Jedan od zahtjeva za programsku

implementaciju rješenja bio je korištenje programskog jezika Java. U skladu s tim, koristio

se programski okvir Java EE (Enterprise Edition) za razvoj aplikacijskog poslužitelja.

Kompletna arhitektura može se opisati kao dvoredni klijent-poslužitelj.

3.1. Java EE

Java Enterprise Edition je programski alat kompanije Oracle za razvoj poslovnih

aplikacija, proširenje Java SE (Standard Edition) platforme. Java EE platforma proširena je

dodatnim aplikacijskim modulima (API, Application Programming Interface) i okolinom

za izvršavanje poslovnih aplikacija. Primjeri aplikacija koje je moguće razviti su: web

servisi, mrežne aplikacije i drugi veliki, višeslojni i skalabilni sustavi. Cilj platforme je

razvoj programske podrške zasnovan na modularnim komponentama koje se izvršavaju na

aplikacijskom poslužitelju. Razvoj je olakšan korištenjem anotacija (annotations) za

konfiguraciju programa, naspram standardnog korištenja konfiguracijskih XML datoteka.

Postoji nekoliko Java EE certificiranih poslužitelja koji mogu izvršavati aplikacije pisane

za tu platformu, a to su: GlassFish, JBoss, Apache Geronimo, Apache TomEE i drugi. Za

potrebe razvoja programskog rješenja u ovome radu koristi se GlassFish poslužitelj, verzije

4.1. Razvijena aplikacija je zapakirana kao datoteka WAR (Web Application Archive), koja

će biti postavljena (deployed) na poslužitelju GlassFish. WAR je u suštini jedan oblik JAR-

a, Java arhive (Java ARchive), čija je namjena distribuiranje skupine Java Servleta, Java

Server Pages, klasa napisanih u Javi, XML datoteka i ostalih resursa koji zajedno formiraju

cjelinu za web-aplikaciju.

22

3.2. HTTP i REST sučelje

Za komunikaciju između korisnika, odnosno klijenta te poslužitelja koristila se

arhitektura REST, zbog svojih dobrih svojstava opisanih u poglavlju 1.5. Protokol HTTP

(HyperText Transfer Protocol) je korišten kao transportni protokol za prijenos zahtjeva

klijenta prema poslužitelju i prijenos odgovora za obrađeni zahtjev od poslužitelja prema

klijentu. Razlozi za korištenje dotičnog protoka su široka rasprostranjenost i razvijena

programska podrška za razvoj aplikacija. Međutim, protokol HTTP nije bio korišten kada

se klijentima prosljeđuju objave koje preklapaju pretplate koje su definirali. Za tu vrstu

komunikacije koristila se kasnije opisana razmjena poruka na principu push.

Sučelje REST za sustav implementirano je korištenjem Java EE platforme pa je u ovom

poglavlju fokus na opisu korištenih URL-ova (Uniform Resource Locator) i standardnih

HTTP metoda koje su se koristile za dotične URL-ove.

Java EE koristi unaprijed definiran skup anotacija kako bi se izgradilo aplikacijsko sučelje.

Neke od korištenijih anotacija su:

@Path Predstavlja URI predložak do lokacije na kojoj se

nalazi resurs (klasa ili metoda). Predstavlja relativnu

putanju na poslužitelju na kojem je aplikacija

aktivna.

@PathParam Koristi se za ubacivanje vrijednosti URI parametra

definiranog u @Path anotaciji.

@GET Predstavlja „GET“ metodu iz protokola HTTP,

odnosno da određena metoda unutar klase koristi

„GET“ metodu za obradu zahtjeva. Dotična metoda

se koristi za dohvat informacija o resursu definiranog

putem URI-ja.

23

Temeljna URL ekstenzija aplikacije je /gprsp/rest/api, pri čemu je izostavljen

URL poslužitelja na kojemu je aplikacija poslužena. Ako se aplikaciji želi pristupiti s

računala na kojemu je i poslužena, što će u nastavku biti slučaj, potpuni URL aplikacije

glasi:

http://localhost/gprsp/rest/api

„localhost“ je adresa mrežnog sučelja računala na kojemu se korisnik nalazi.

3.2.1. Dodavanje konverzije

Kao prvi korak bilo je potrebno na poslužitelju omogućiti dodavanje konverzije za određen

tip mjerenja i mjerne jedinice od interesa. Akcija kao rezultat ima dodavanje novog resursa

na poslužitelj ili izmjenu postojećeg, te se u skladu s načelima arhitekture REST, koristi

odgovarajuća metoda protokola HTTP, POST.

@POST Predstavlja „POST“ metodu protokola HTTP,

odnosno da određena metoda klase koristi „POST“

metodu za obradu zahtjeva. Dotična metoda koristi se

za informiranje odredišnog poslužitelja o kreiranju

novog resursa za URI na koji se resurs šalje.

@DELETE Predstavlja „DELETE“ metodu protokola HTTP.

Metoda se koristi kako bi se od odredišnog

poslužitelja zatražilo da izbriše resurs koji je

identificiran URI-jem zahtjeva.

@Consumes Specificira MIME ekstenziju (Multipurpose Internet

Mail Extensions) kojim se opisuje resurs zaprimljen

od klijenta.

@Produces Specificira MIME ekstenziju odgovora koji se vraća

klijentu koji je uputio zahtjev. Postoji nekoliko

definiranih vrijednosti, ali može se spomenuti

„application/json“ vrijednost ovog parametra koja se

često koristi u ovom radu.

24

URL na koji se prosljeđuje resurs je :

http://localhost:8080/gprsp/rest/api/addconversion

Resurs se na poslužitelj prenosi u tijelu zahtjeva u obliku JSON objekta. Format dotičnog

JSON objekta je sljedeći, opisan kroz primjer dodavanja konverzije iz Celzijevih u

Kelvine, za mjerenje temperature:

Rezultat mjerenja u slučaju da je resurs valjan, što podrazumijeva ispravno definiranu

formulu, može biti jedna od dvije poruke:

Nova konverzija dodana

Konverzija izmijenjena

Prva poruka prikazana je kada se za definiranu trojku vrstaOcitanja,

izMjerneJedinice i uMjernuJedinicu prvi puta dodaje konverzija. U slučaju

izmjene resursa definiranog postojećom trojkom, prikazuje se druga poruka. U slučaju

nepredviđene greške u odgovoru će biti uključena poruka iznimke koja se dogodila u

programu. Obrada mogućih grešaka izostavljena je u programskoj implementaciji jer je

izvan opsega rada. Pretpostavka je da će korisnik sustava poštivati definirane zahtjeve i

ograničenja. Dodatno, sustav ne omogućava interno kombiniranje postojećih konverzija.

Neka je pretpostavka da na sustavu postoji neka jedinica očitanja, s definiranim

konverzijama između mjernih jedinica, simbolički predstavljenih sa „A“, „B“ i „C“. Neka

prva konverzija definira pretvorbu „A“ „B“, a druga konverzija pretvorbu „B“ „C“.

Korisnik, ako to želi, mora eksplicitno dodati konverziju „A“ „C“, jer sustav nema

mogućnosti načelom tranzitivnosti zaključiti da je moguće kombinacijom konverzija „A“

„B“ i „B“ „C“ postići konverziju „A“ „C“. Kao i u slučaju greške u zahtjevu

resursa, radi se o problemu koji je izvan opsega ovog rada.

{

„vrstaOcitanja“: „temperatura“,

„izMjerneJedinice“:„C“,

„uMjernuJedinicu“:„K“,

„formula“:„C + 273.15“

}

25

Korištenjem anotacija Jave EE, resurs na poslužitelju koji omogućava dodavanje

konverzije izgleda ovako:

@POST anotacija definira metodu protokola HTTP koja se koristi.

@Path, odnosno vrijednost u zagradi određuje relativnu rutu na poslužitelju na kojoj se

upućuje zahtjev.

@Consumes određuje vrstu resursa koji se šalje u tijelu zahtjeva.

@Produces određuje vrstu resursa koja će biti vraćena u odgovoru koji se prosljeđuje

klijentu. Kako se za razmjenu informacija koristi JSON format, naznačen je

„MediaType.APPLICATION_JSON“ za povratni tip.

3.2.2. Dodavanje pretplate

Drugi zahtjev opisan u poglavlju 2.4 koji je trebalo izvršiti, je dodavanje pretplate

na poslužitelj. Kao i prilikom dodavanja konverzije, radi se o akciji koja mijenja stanje na

poslužitelju, odnosno dodaje novi resurs. I u ovom slučaju se koristi metoda POST

protokola HTTP. Resurs koji se šalje na poslužitelj je JSON kompatibilan, kao i odgovor

koji poslužitelj šalje po obrađenom zahtjevu.

URL na koji se dodaje nova pretplata je:

http://localhost:8080/gprsp/rest/api/subscribe

U poglavlju 2.4 opisani su svi potrebni podatci koji moraju biti navedeni u resursu

pretplate kako bi bio kompletan. Jedan od zahtjeva zadatka je korištenje specifikacije

GeoJSON za definiranje prostornih geometrija. Ako se promotri specifikacija oblika

(feature) u GeoJSON dokumentaciji, može se primjetiti kako se uz geometriju unutar

@POST

@Path(„/addconversion“)

@Consumes(MediaType.APPLICATION_JSON)

@Produces(MediaType.APPLICATION_JSON)

public String addConversion(String request) {

...

}

26

jednog oblika treba nalaziti i član properties. Taj je element asocijativno polje, u kojem su

podatci pohranjeni u obliku ključ vrijednost. Umjesto da se razrađuje u

potpunosti nova struktura podataka za definiranje pretplate, praktičnije je koristiti

spomenuti feature, jer osim geometrije moguće je definirati dodane parametre. Iz

praktičnih razloga, ponajviše olakšavanja implementacije programskog rješenja, feature

koji predstavlja pretplatu biti će element još općenitijeg objekta, kolekcije oblika (feature

collection). Konkretno radi se o mogućnosti korištenja postojećih parsera i konvertera iz

tekstualnog JSON formata. U resursu pretplate, identifikator pretplatnika biti će korišten

kao ključ za slanje asinkronih push poruka prema pretplatniku ako na poslužitelj bude

zaprimljena objava koja preklapa pretplatu.

Jedna kompletna pretplata ima sljedeću strukturu:

{

„type“:“FeatureCollection“,

„features“:[

{ „type“:„Feature“,

„geometry“:{

„type“:„Point“,

„coordinates“:„[50.0, 50.0]},

„properties“:{

„identifikator_pretplatnika“:„123456789“,

„vrsta_ocitanja“:„temperatura“,

„jedinica_ocitanja“:„C“,

„interval_donji“:„10“,

„interval_gornji“:„15“

}

}]

}

27

Na poslužitelju, u Java EE tehnologiji, resurs na poslužitelju definiran je ovako:

3.2.3. Objava senzorskih očitanja

Treća akcija koja je trebala biti omogućena kako bi sustav implementirao osnovne

zahtijevane funkcionalnosti je objavljivanje senzorskog očitanja. Detalji zahtjeva opisani

su u poglavlju 2.5. Objava senzorskog mjerenja na poslužitelj zapravo je slanje novog

resursa na obradu, slično kao što je slučaj s dodavanjem konverzije ili dodavanjem

pretplate. Prema načelu REST-a, kao metoda za dodavanje odnosno objavu senzorskog

očitanja koriste se POST protokola HTTP.

Resurs senzorskog mjerenja, slično kao i pretplata, ima prostornu komponentu i atribute

koji ju dodatno definiraju. Iz razloga opisanih u poglavlju 3.2.2, koristi se ista struktura

podataka formata GeoJSON, FeatureCollection.

@POST

@Path(„/subscribe“)

@Consumes(MediaType.APPLICATION_JSON)

@Produces(MediaType.APPLICATION_JSON)

public String addSubscription(String request) {

...

}

28

Primjer resursa senzorskog mjerenja izgleda ovako:

U primjeru su identifikator senzora i tip senzora izostavljeni kako čitatelj ne bi bio zbunjen

navedenim vrijednostima, jer ne postoji ograničenje u formatu za ta dva podatka. Oni ovise

od proizvođača do proizvođača, te može biti riječ o proizvoljno dugom nizu

alfanumeričkih znakova. Format vremena je broj sekundi od 1.1.1970. do trenutka kada je

mjerenje provedeno. Taj način mjerenja zove se UNIX vrijeme (UNIX time), poznato kao i

vrijeme epohe (epoch time). Ime potječe od korištenja u velikom broju UNIX operacijskih

sustava. Kako bi senzorska objava mogla biti obrađena, nužno je da su vrstaOcitanja i

jedinicaOcitanja već definirani na poslužitelju kroz korak opisan u poglavlju 4.3. U

protivnom će u odgovoru na upućeni zahtjev biti ispisana odgovarajuća poruka o grešci.

URL za dodavanje nove objave u sustav je:

http://localhost:8080/gprsp/rest/api/publish

{

„type“:“FeatureCollection“,

„features“:[{

„type“:„Feature“,

„geometry“:{„type“:„Polygon“,

„coordinates“:„[[0.0, 0.0], [100.0, 0.0],

[[100.0, 100.0], [0.0, 0.0]]},

„properties“:{

„indentifikatorSenzora“:„[ID]“,

„vrijemeOcitanja“:„123456789“,

„tipSenzora“:„[TIP SENZORA]“,

„vrstaOcitanja“:„temperatura“,

„vrijednost“:„15“,

„jedinicaOcitanja“:„C“

}

}]}

29

Resusr na poslužitelju koji omogućava objavu senzorskih objava izgleda ovako:

Algoritam pretraživanja implementiran je u skladu sa opisom u poglavlju 2.6.

3.2.4. Brisanje pretplata

Razvojem sustava uočeno je da postoji potreba za dodatnim REST sučeljima na

poslužitelju kako bi se sustav mogao jednostavnije koristiti. Ovo i sljedećih nekoliko

poglavlja opisuju svako sučelje zasebno, motivaciju za stvaranjem, URL odnosno URI te

format odgovora.

Prilikom dodavanja nove pretplate i nakon što je novi resurs stvoren na poslužitelju, svaka

pretplata dobiva svoj jedinstveni identifikator. Identifikator je dodijeljen svakoj pretplati sa

svrhom da se nju može modificirati koristeći spomenuti identifikator. Jedina modifikacija

koja je implementirana u ovom trenutku je brisanje pretplate s poslužitelja. Prema

načelima REST-a, resurs kojim se manipulira treba biti predstavljen URI-jem. Kako se radi

o akciji brisanja resursa tj. pretplate, koristi se metoda DELETE protokola HTTP.

Primjer URI-ja za brisanje pretplate je:

http://localhost:8080/gprsp/rest/api/unsubscribe?Subscriptionid=1

Za primjer URI-ja pretpostavlja se da je vrijednost identifikatora za dotičnu pretplatu „1“.

Kao odgovor na zahtjev prilikom brisanja pretplate postoje dvije moguće poruke;

„Pretplata je izbrisana“ ili „Nema pretplate sa specificiranim subscriptionid“.

@POST

@Path(„/publish“)

@Consumes(MediaType.APPLICATION_JSON)

@Produces(MediaType.APPLICATION_JSON)

public String publish(String request) {

...

}

30

Resurs na poslužitelju izgleda ovako:

3.2.5. Lista konverzija

Prilikom razvoja mobilne aplikacije ukazala se potreba za definiranjem sučelja preko kojeg

će biti moguće dohvatiti sve konverzije koje trenutno postoje na poslužitelju. Ništa se ne

šalje na poslužitelj, nego se samo dohvaćaju podatci, koristi se metoda GET protokola

HTTP.

URL sa kojeg se dohvaća lista svih postojećih konverzija je:

http://localhost:8080/gprsp/rest/api/listconversions

Odgovor sa poslužitelja biti će lista konverzija:

{

elapsedTime: 0,

success: true,

error: null,

count: 1,

payload:

[{ „vrstaOcitanja“:„temperatura“,

„izMjerneJedince“:„K“,

„uMjernuJedinicu“:„C“,

„formula“:„K-273“

}]

}

@DELETE

@Path(„/unsubscribe“)

@Consumes(MediaType.APPLICATION_JSON)

@Produces(MediaType.APPLICATION_JSON)

public String unsubscribe(String request) {

...

}

31

Na poslužitelju je resurs definiran na sljedeći način:

3.2.6. Lista tipova senzora

Zbog istih motiva kao i u prethodnom podpoglavlju, ukazala se potreba za

dohvaćanjem svih vrsta senzora za koji su trenutačno definirani na poslužitelju. Korištena

je metoda GET protokola HTTP, jer se radi o dohvatu podataka bez slanja resursa na

poslužitelj.

URL sa kojeg se dohvaća lista svih postojećih senzora je:

http://localhost:8080/gprsp/rest/api/sensortypes

Odgovor s poslužitelja biti će lista senzora:

Jedan unos u listi tipova senzora ima dva člana, vrstuOcitanja koja identificira vrstu

senzorskog mjerenja, a drugi mjerneJedinice sadrži listu svih podržanih mjernih

jedinica za tu vrstu očitanja.

{

elapsedTime: 0,

success: true,

error: null,

count: 1,

payload:

[{

„vrstaOcitanja“:„temperatura“,

„mjerneJedinice“:[„C“, „K“]

}

]

@GET

@Path(„/listconversions“)

@Produces(MediaType.APPLICATION_JSON)

public String listconversions(String request) {

...

}

32

Izgled resursa na poslužitelju:

3.2.7. Resetiranje poslužitelja

Prilikom testiranja poslužitelja pokazalo se kao korisna mogućnost napraviti sučelje

putem kojeg bi se jednim pozivom izbrisale sve pretplate, konverzije i tipovi senzora. Za

brisanje konverzija i tipova senzora čak i ne postoje definirana sučelja, dok za brisanje

pretplata postoji. Ipak, u slučaju velikog broja pretplata bio bi zamoran zadatak jednu po

jednu pretplatu brisati sa poslužitelja. Zbog jednostavnosti, koristi se metoda GET

protokola HTTP, kako bi se metodu moglo izvršiti iz preglednika Weba.

URL na kojem se brišu svi podatci s poslužitelja je:

http://localhost:8080/gprsp/rest/api/reset

Resurs na poslužitelju izgleda ovako:

Za ovu metodu, za razliku od prethodnih se ne definira povratni tip podatka kao

MediaType.APPLICATION_JSON jer se korisniku ispisuje obična tekstualna poruka o

uspješnosti akcije.

@GET

@Path(„/reset“)

public String reset(String request) {

...

}

@GET

@Path(„/sensortypes“)

@Produces(MediaType.APPLICATION_JSON)

public String listSensorTypes(String request) {

...

}

33

3.3. Geotools i JTS

Treba spomenuti programske okvire koji su se koristili za obradu resursa

senzorskog očitanja odnosno pasiranje resursa senzorske objave kao i za upravljanje

geometrijama.

GeoTools je programski okvir otvorenog koda (open source) objavljen pod LGPL (Lesser

General Public Licence). Programski okvir omogućava standardizirane metode za

upravljanje geoprostornih podataka, primjerice geografskih informacijskih sustava.

Specifikacije koje razvija Open Geospatial Consortium (OGC) su također implementirane

u programskom okviru.

Neke od osnovnih funkcionalnosti programskog okvira su:

Definicija sučelja za najvažnije koncepte i strukture podataka

Programsko sučelje za dohvat podataka, transakcijsku obradu i zaključavanje dretvi

Tehnologije za parsiranje sadržaja iz formata XML (eXtensible Markup Language)

u GML (Geography Markup Language), koristeći sheme.

Otvoreni pomoćni programi za definiranje novih formata podataka

GeoTools ekstenzije

Geotools programski okvir se u ovom radu koristi zbog mogućnosti korištenja sa

GeoJSON formatom i knjižnicom JTS (Java Topology Suite). Precizno govoreći, GeoTools

programski okvir koristi se za pretvorbu geometrija zapisanih u GeoJSON formatu u

pripadajuću geometriju knjižnice JTS.

Programska knjižnica JTS je aplikacijsko sučelje (Application Programming Interface) za

dvodimenzionalne prostorne predikate i funkcije. U trenutku pisanja ovog rada, aktualna

verzija knjižnice je 1.8.

Glavne značajke knjižnice JTS su:

Implementacija prostornih struktura podataka definiranih u OGC Simple Feature

Specification for SQL.

Kompletna, konzistentna implementacija temeljnih dvodimenzionalnih algoritama

što uključuje binarne predikate za doticaj (touch) i preklapanje (overlap) kao i

prostorne metode analize za presjek (intersection) i odmak (buffer) [8].

34

Izričit model preciznosti, sa algoritmima koji sa oprezom rješavaju situacije kod

kojih dolazi do dimenzijskog kolapsa.

Robusna implementacija ključnih geometrijskih operacija

Unos ili ispis podataka u WTK (Well Known Text) formatu

U knjižnici JTS postoje sljedeći prostorni oblici:

Točka (point)

Skup točaka (multipoint)

Linija (linestring)

Prsten (linearring)

Skup linija (multilinestring)

Poligon (polygon)

Skup poligona (multipoligon)

Skup geometrija (geometry collection)

Kao što je vidljivo, podržani oblici odgovaraju onima koji su definirani u specifikaciji

GeoJSON, zbog čega je ova knjižnica posjeduje zadovoljavajuće funkcionalnosti za

potrebe rada.

Postoji više odnosa između dva oblika koja se uspoređuju, točnije dva oblika mogu biti u

sljedećim odnosima:

jednaki (equals)

disjunktni (disjoint)

presijecanje (intersect)

dodirivanje (touch)

preklapanje (overlap)

križanje (cross)

prvi sadržan unutar drugog (within)

drugi sadržan unutar prvog (contains)

Možda čitatelju neće biti jasno koja je točna razlika između intersection, touch, overlap,

cross, within i contains. Može se smatrati da je intersection najopćenitiji oblik odnosa

između dvije geometrije, koje imaju barem jednu zajedničku točku. Ostali odnosi poput

35

touch, overlap, cross, within i contains imaju dodatne zahtjeve na dimenzionalnost oblika

koji su u interakciji i dimenzionalnost oblika koje tvore njihove zajedničke točke. U ovom

radu intersect kao odnos između dvije geometrije će biti dovoljan, stoga se ostali prostorni

predikati dodatno ne opisuju. Zainteresirani čitatelj može na poveznici [9] pronaći detalje

na spomenutu temu.

Prostorni indeksi implementirani u programskoj knjižnici JTS su Quadtree i STRtree.

Quadtree je prostorna struktura koja služi za izvođenje efikasnih upita kvadrata, dok je

STRtree prostorna struktura koja podržava samo izvođenje upita nakon što je izgrađena, što

onemogućava naknadno dodavanje novih oblika. U programskoj implementaciji koristio se

Quadtree zbog mogućnosti dodavanja i brisanja elemenata u bilo kojem trenutku

korištenja.

3.4. Mehanizam obaviješćivanja korisnika

U trećem poglavlju do sada su opisani svi važniji elementi sustava. Ostaje još opisati

mehanizam informiranja korisnika ako na sustav pristigne senzorska objava koja odgovara

korisnikovoj pretplati. Sve do sad opisane interakcije bile su inicirane od strane klijenta

koji je slao zahtjev, a poslužitelj je slao odgovore. Međutim, klijent ne može znati kada će

poslužitelj zaprimiti objavu te je pitanje kako efikasno obavijestiti korisnika. Jedno već

spomenuto rješenje je spremati objave koje odgovaraju pretplati korisnika u red čekanja.

Klijent periodičnim slanjem zahtjeva na poslužitelj (poll) provjerava ima li u njegovom

redu čekanja objava koje preklapaju njegovu pretplatu. Ako red čekanja nije prazan,

korisnik dohvaća sve objave, čime se red čekanja pristiglih objava korisnika na poslužitelju

prazni. Nekoliko je problema s ovim pristupom. Potrebno je procijeniti koliki treba biti

vremenski interval provjere stanja na poslužitelju. Interval ne smije biti prekratak da

uzrokuje opterećenje poslužitelja u slučaju velikog broja korisnika, a s druge strane ne

smije biti niti toliko dug da sama objava postane beskorisna korisniku uslijed predugog

vremena isporuke. Pokazuje se da je bolje ipak prepustiti poslužitelju odgovornost

propagiranja informacija prema klijentu, odnosno pretplatniku korištenjem poruka na

principu push.

Postoji još jedna mogućnost prosljeđivanja poruka od poslužitelja prema klijentu.

Komunikacije je inicirana od strane klijenta bez da poslužitelj bude nepotrebno opterećen.

Metoda kojom se to postiže je dugoročno prozivanje (long polling) poslužitelja. Ideja je da

36

klijent održava otvorenu TCP (Transmission Control Protocol) vezu s poslužiteljem, bez

da se podatci nužno prenose između sudionika ako za to nema potrebe. Međutim, kad se za

to ukaže potreba, poslužitelj može kroz uspostavljenu vezu poslati informacije klijentu.

Opisani model komunikacije ima potrebnu sposobnost prijenosa informacija, bez da su

mrežni resursi iskorišteni na neefikasan način. Ovaj način prijenosa se često koristi za

izradu web aplikacije kod kojih se želi poboljšati korisničko iskustvo (user experience).

Pitanje je može li se i ovakav pristup koristiti ako je jedan od sudionika u komunikaciji

mobilni uređaj, koji ima bateriju ograničen izvor električne energije. Istraživanja su

pokazala [12] da je potrošnja energije manja ako se koriste push poruke, za razliku od

tehnike dugoročnog prozivanja poslužitelja. Zbog svega opisanih prednosti, odabran je

način komunikacije push između poslužitelja i klijenta.

Klijentska aplikacija razvijena je za mobilne uređaje s operacijskim sustavom

Android. Google, kompanija koja najvećim dijelom razvija platformu Android, ima

razvijen mehanizam slanja asinkronih push poruka od poslužitelja prema klijentu, GCM -

Google Cloud Messaging. GCM je usluga koji implementira sve dosad navedene

funkcionalnosti koje su zahtijevane za servis koji će služiti kao mehanizam isporuke

poruka od poslužitelja do klijenta.

3.4.1. Usluga Google Cloud Messaging

Korisno je spomenuti kao detalj implementacije osnovne zahtjeve za korištenja

usluge GCM. Sudionici u procesu su klijentski poslužitelj, klijentska aplikacija na

mobilnom uređaju i GCM poslužitelji za razmjenu poruka [11].

Interakcija između spomenutih sudionika je sljedeća:

Google GCM poslužitelj dohvaća poruke i prosljeđuje ih klijentskoj aplikaciji

Aplikacijski protokol implementira protokol HTTP ili XMPP (eXtensive Messaging

and Presence Protocol, za komunikaciju sa GCM poslužiteljem

Klijentska aplikacija ima omogućenu GCM funkcionalnost. Kako bi primanje

GCM poruka bilo moguće, aplikacija treba zatražiti registracijski token od GCM

poslužitelja. Dobiveni token se onda šalje na pripadajući aplikacijski poslužitelj.

Token se koristi kada poslužitelj želi poslati poruku točno određenom klijentu

37

Postoji nekoliko akreditiva (credentials) koji se koriste u procesu, a to su:

Sender-ID – jedinstveni niz brojeva koja se stvara prilikom konfiguriranja

projekta na Google razvojnoj konzoli (developers console). Koristi se u

registracijskom procesu klijentske aplikacije na GCM poslužitelj.

Sender Auth Token – ključ spremljen na aplikacijskom poslužitelju koji služi

autoriziran pristup Google servisima, od kojih je jedan i GCM. Ključ je sadržan u

zaglavlju HTTP POST zahtjev koji se šalje na GCM poslužitelj.

Application-ID – Klijentska aplikacija se registrira za prihvat poruka. Za

Android, svaka aplikacija predstavljena je imenom paketa definiranog u manifest

datoteci. Ovime se osigurava da su poruke dostavljene ispravnoj aplikaciji na

uređaju.

Registration token – identifikator dodijeljen od strane GCM poslužitelja

aplikaciji čime joj se omogućava dostavljanje poruka. Ovaj token treba biti tajan.

Poruke koje se šalju mogu biti poslane jednom ili više klijenata odjednom. Postoji i

ograničenje veličine poruka, koje ne smiju biti veće od 4kb. Korišteni format je JSON, a

vrijeme isteka poruke je četiri tjedna. To znači da će poruka biti spremljena na GCM

poslužitelju maksimalno četiri tjedna ako uređaj u međuvremenu nije dostupan za prihvat

poruke. GCM servis ima i mogućnost i komunikacije od klijentske aplikacije prema

aplikacijskom poslužitelju, Kako bi to bilo moguće, komunikacija mora biti

implementirana korištenjem protokola XMPP.

3.5. Mobilni uređaj kao senzor i aplikacija kao klijent

Kako bi se demonstrirale mogućnosti sustava za korištenjem u stvarnim uvjetima

razvijena je mobilna aplikacija koja omogućava osnovne funkcionalnosti koje su opisane

za klijenta. Kao što je već spomenuto, aplikacija je razvijena za uređaje s operacijskim

sustavom Android. Aplikacija se sastoji od sveukupno 5 ekrana zvanih aktivnosti

(activity), pri čemu svaki ekran služi za točno jedan slučaj upotrebe (use case). Slika 1

prikazuje slučajeve upotrebe.

38

Slika 1 - Slučajevi upotrebe aplikacije

3.5.1. Opis upotrebe aplikacije

Glavni navigacijski ekran sadrži četiri gumba (button), grafičke komponente

kojima se korisnik kreće u aplikaciji. Po tekstu koji je napisan unutar svakog gumba

korisniku je intuitivno jasno što može postići svakom pojedinom akcijom. Na ovom ekranu

prikazana je i karta usluge Google Maps, u čijem je fokusu šire područje grada Zagreba.

Namjena karte je omogućiti korisniku pregled terena kako bi mogao pronaći područje koje

ga interesira. Karta korisniku može biti prikazana u četiri različita prikaza, koja se mogu

uočiti na Slika 3. Na lijevoj slici karta je u satelitskom prikazu, a desna u normalnom. Iz

padajućeg izbornika, koji se aktivira kliktanjem gumba u gornjem desnom kutu, može se

odabrati odgovarajući prikaz karte.

39

Slika 2 - Početni ekran aplikacije Slika 2 – Padajući izbornik za odabir prikaza

Lijevi satelitski prikaz korisniji je kako bi se prikazao stvarni izgled terena, dok je desni

terenski bolji ako su potrebne informacije prometnim pravcima, imenima naselja i

granicama država. Hibridni prikaz zapravo je satelitski uz naznačene nazive gradova, dok

terenski prikaz naglasak stavlja na prikaz terena kao geografske strukture, gdje je lakše

uočiti brda i nizine.

Klikom na gumb „Prikaži senzore“, prikazat će se ekran na kojem će biti prikazani svi

trenutno dostupni tipovi senzora definirani na poslužitelju. Slika 4 prikazuje scenariji kada

postoje definirani senzori. Ako na poslužitelju nema nikakvih informacija, korisniku se

prikazuje odgovarajuća poruka, kao na slici 5.

40

Slika 4 – Prikaz postojećih senzora na poslužitelju Slika 5 – Poruka ako nema podataka na poslužitelju

Gumb „Osvježi“ u gornjem desnom kutu ekrana služi kako bi korisnik mogao provjeriti je

li došlo do promjene u definiranim vrstama senzora, bez da mora izlaziti iz trenutne

aktivnost i ponovo se u nju vraćati.

Kroz aplikaciju korisnik ima mogućnost pregledati i sve trenutno dostupne konverzije koje

su definirane na poslužitelju. Na spomenuti ekran dolazi se odabirom gumba „Prikaži

konverzije“. Slično kao i kod prikaza svih vrsta senzorskih očitanja, ako postoje unosi na

poslužitelju, prikazat će se sve informacije o dostupnim konverzijama, što prikazuje slika

6. Ako nema podataka, korisniku se ispisuje odgovarajuća poruka, prikazano na slici 7. U

gornjem desnom kutu gumb „Osvježi“ ima sličnu funkcionalnost kao i na ekranu za prikaz

svih vrsta mjerenja.

41

Slika 6 – Prikaz postoječih konverzija na

poslužitelju

Slika 7 – Poruka ako nema podataka na poslužitelju

Aplikacija ima mogućnost dodavanja konverzije ako na poslužitelju nisu definirane sve

konverziju za mjernu jedinicu u kojoj korisnik želi definirati pretplatu. Prilikom dolaska na

ekran gdje može izvršiti opisanu akciju, korisnik uočava četiri polja koja je potrebno

ispuniti. U svim poljima stoji kratak opis što bi trebalo unijeti u njih. Primjer ispravno

definirane konverzije prikazan je na Slici 9.

42

Slika 8 – Prazni ekran za dodavanje nove konverzije Slika 9 – Primjer ispravno unesene konverzije

Korisnik je obaviješten uspješnom ili neuspješnom dodavanju nove konverzije kroz kratku

skočnu poruku (toast), koja se privremeno pojavljuje u donjem dijelu ekrana, kao na slici 9

Posljednja funkcionalnost koju je moguće ostvariti kroz aplikaciju je dodavanje pretplate.

Kao što je već poznato, od atributnih parametara potrebno je definirati vrstu očitanja koja

se prati, mjernu jedinicu, te donji i gornji interval koji je od interesa za korisnika. Za

potrebe mobilne aplikacije, skup geometrijskih oblika reduciran je na poligon, iako je

predviđeno da na uređaju korisnik može definirati i ostale spomenute geometrijske oblike.

Kod učitavanja ekrana za dodavanje pretplata, s poslužitelja se dohvaća popis svih vrsta

očitanja kao i mjernih jedinica za svako očitanje. Korisnik odabire vrstu očitanja i mjernu

jedinicu kroz padajući izbornik (spinner). Donju i gornju vrijednost parametra koji korisnik

želi pratiti, može se unijeti kroz ćelije za unos teksta (edittext). Aplikacija provodi

validaciju jesu li odabrani svi potrebni parametri, te u slučaju da to nije učinjeno ispisuje

43

odgovarajuće upozorenje. Na Slici 11 prikazano je kako izgleda pretplata koja ima sve

potrebne unose. Poligon prikazan na slici označava obalno područje rijeke Save u gradu

Zagrebu. Konačno, korisnik pretplatu objavljuje na poslužitelju odabirom opcije „objavi“

iz padajućeg izbornika u gornjem desnom kutu.

Slika 10 – Odabir vrste očitanja iz padajućeg

izbrnika kod dodavanja pretplate

Slika 11 – Primjer pretplate sa unesenim svim

potrebnim podatcima

44

4. TESTIRANJE SUSTAVA I REZULTATI

Sustav je u potpunosti implementiran u skladu sa zahtjevima i funkcionalan te je bilo

potrebno provesti testiranje performansi sustava. Prije testiranja, trebalo je definirati koji

će se parametri testirati i na koji način. Broj pretplata u sustavu je očito varijabilan, te se

pokazalo razumno testiranja u sustavu provesti tako da se broj pretplata mijenja kod svake

iteracije testiranja. Dakako i broj objava je varijabilan, ali fokus testiranja je bio provjeriti

koliko je vremena potrebno da bi sustav pronašao sve pretplate koje odgovaraju pristigloj

objavi. Iz tog razloga, skup objava koji se koristio u svakoj iteraciji bio je fiksan, te se isti

skup koristio za sva testiranja kako bi se osigurala konzistentnost.

Ideja prilikom testiranja vrednovati sljedeće parametre:

Ukupno vrijeme obrade svih objava

Prosječno vrijeme procesiranja objave (bez obzira na ishod)

Prosječno vrijeme procesiranja objave kod koje postoji preklapanje s pretplatama

Prosječno vrijeme procesiranja objave kod koje nema preklapanja s pretplatama

Broj objava kod kojih je pronađeno preklapanje s pretplatama

Prosječno vrijeme pretraživanje pretplate koja odgovara pristigloj objavi

Za testiranje je bilo potrebno imati skup podataka s kojima će se provoditi testiranje. U

skladu s tim, pokazala se potreba za izradom generatora koji će nasumično kreirati

pretplate i objave jer nisu postojali nikakvi valjani podaci koji bi mogli biti korišteni za

testiranje sustava.

Cilj je testiranja bio da proces bude lako ponovljiv, brz, a da rezultati testiranja budu trajno

pohranjeni i pri tome korektno statistički obrađeni kako bi se mogli donijeti zaključci iz

dobivenih rezultata.

45

4.1. Program za testiranje

Za potrebe testiranja izrađena je dodatna aplikacija s tekstualnim korisničkim

sučeljem.

Ideja je s razvijenim programom omogućiti sljedeće:

Brzo i jednostavno generiranje pretplata i objava koji će se koristiti u testiranju

Jednostavno dodavanje velike količine pretplata i objava na poslužitelj

Automatiziran proces testiranja sustava, čiji je krajnji produkt trajni zapis

obrađenih rezultata u tekstualnu datoteku

Program je nazvan „DiplomskiWebInteraktor“, kako bi bilo jasno da je glavna uloga u

programa omogućiti jednostavnu interakciju s poslužiteljem. Razvijen je u programskom

jeziku Java, a koristi dodatne vanjske knjižnice kako bi se pojednostavio proces razvoja.

Program implementira sve tri funkcionalnosti navedene u ovom potpoglavlju, a zavisno od

načina pokretanja programa će odabrana funkcionalnost biti generirana.

4.1.1. Generiranje pretplata i objava

Prva funkcionalnost programa je generiranje pretplata i senzorskih objava. Za

geometrije koje predstavljaju pretplate i objave korištene su točke, linije i poligoni. Dok je

nasumično stvaranje točaka i linija relativno trivijalan posao, pravi je izazov bio kako

nasumično stvoriti pravilne poligone. Prvo je trebalo odlučiti koliki će biti prostor na

kojem će se definirati objave i pretplate. Za potrebe testiranja odabran je kvadrat stranica

duljine 10000. U skladu s tim, odabrana su dva različita uzorka poligona, koji su potom

translatirani za nasumični vektor čije X i Y komponente mogu imati vrijednost od 0 do

10000. Dva ostala tipa geometrija, linija i točka, nasumično su generirani tako da stanu u

prostor definiranog kvadrata. Testni podatci napravljeni su samo za jednu vrstu očitanja, s

dvije mjerne jedinice, a to je temperatura s mjernim jedinicama Kelvin i Celzijus.

Vrijednosti očitanja u slučaju objave ili gornja i donja vrijednost u slučaju pretplate su

nasumično odabrani brojevi u intervalu od 0 do 450, prilikom čega je uzeto u obzir da kod

pretplate gornji interval bude veća vrijednost od donjeg.

46

Ako se želi generirati pretplate, program se pokreće na sljedeći način:

java –jar diplomskiwebintereactor.jar generate subscriptions

[broj_objava]

Na sličan način se generiraju i objave:

java –jar diplomskiwebintereactor.jar generate publications [broj_objava]

U oba slučaja, broj_objava treba biti zamijenjen s cjelobrojnom vrijednošću koja

odgovara broju objava ili pretplata koje se želi generirati.

Rezultat oba načina pokretanja biti će datoteke s podatcima, „Subscriptions.txt“ ili

„Publications.txt“, ovisno o tome što se želi dobiti.

4.1.2. Konzolni način rada

Konzolni način rada programa sugerira kako korisnik ima mogućnost u istoj sesiji

programa unijeti više različitih naredbi.

Za konzolni način, program se pokreće na sljedeći način:

java –jar diplomskiwebintereactor.jar console

Naredbe dostupne u ovom načinu rada su:

listcommands – prikazuje sve naredbe koje se mogu izvršiti

addsubscriptions – dodaje na poslužitelj sve pretplate koje se nalaze u

datoteci „Subscriptions.txt“ u radnom direktoriju iz kojeg je pokrenut program

addconversions – dodaje na poslužitelj sve konverzije iz datoteke

„Conversions.txt“, koja se treba nalaziti u radnom direktoriju.

unsubscribeall – ukloni sve pretplate koje su dodane u ovoj sesiji

unsubscribe [ID] – ukloni pretplatu čiji s definiranim [ID]

end – dovršava trenutnu sesiju

reset – postavlja poslužitelj na početno stanje

47

4.1.3. Testni način rada

Slično kao i prilikom generiranja pretplata i objava, dovoljno je samo pokrenuti

program kako bi se provelo testiranje. Da bi testiranje bilo provedivo, u radnom direktoriju

programa treba postojati datoteka „Publications.txt“. Objave iz spomenute datoteke koriste

se za testiranje performansi sustava.

Za potrebe testiranja, napravljen je prilagođeni URL na poslužitelju koji za svaku objavu

vraća broj pronađenih pretplata i vrijeme obrade za pojedinu objavu.

Primjer odgovora poslužitelja za jednu objavu prilikom testiranja:

Najvažniji podatci odgovora su elapsedTime koje označava vrijeme obrade i count koji

označava koliko pretplata preklapa pristiglu objavu.

Pseudokod algoritma testiranja:

Program se pokreće na sljedeći način:

java –jar diplomskiwebintereactor.jar test

{

"elapsedTime": 20,

"success": true,

"error": null,

"count": 209,

"payload": []

}

Za sve objave u datoteci {

Učitaj objavu iz datoteke;

Pošalji objavu na poslužitelj;

Dohvati rezultate obrade;

Pohrani „elapsedTime“ i „count“ iz rezultata obrade;

}

Obradi akumulirane „elapsedTime“ i „count“ podatke;

Zapiši rezultate testiranja u datoteku

48

Kada se pokrene testiranje, korisnik u konzoli može vidjeti neobrađene rezultate

testiranja za svaku pojedinu objavu, što je prikazano na slici 12.

Slika 12 – Ispis u konzoli prilikom testiranja sustava

Po završetku testiranja, rezultati testiranja koji su statistički obrađeni zapisani su u

datoteku. Kako bi statistička obrada podataka Za podatke koji sadrže prosjeke

akumuliranih vrijednosti računa se i standardna devijacija.

Primjer sadržaja datoteke:

Subscriptions count : 5000

Publications count : 400

Total publishing time : 2796,800 ms

Average time per publication : 6,992 +- 7,956 ms

Total hit publications execution time: 2244,400 ms

Avg hit publication execution time: 13,602 +- 8,752 ms

Total miss publications execution time: 552,400 ms

Avg miss publication execution time: 2,351 +- 1,335 ms

Publications with matches count : 165

Average subscription match time : 0,939 +- 1,301 ms

49

Značanja pojedinih redaka u izvješću su:

Subscription count broj pretplata na poslužitelju u trenutku

testiranja

Publications count broj očitanja s kojima je provedeno

testiranje

Total publishing time ukupno potrošeno vrijeme na slanje svih

očitanja

Average time per publication prosječno vrijeme obrade jednog

senzorskog očitanja

Total hit publications execution

time

ukupno vrijeme obrade svih očitanja kod

kojih je pronađena barem jedna

preklapajuća pretplata

Avg hit publication execution

time

prosječno vrijeme obrade očitanja kod

kojih ima preklapanja s pretplatama

Total miss publication execution

time

ukupno vrijeme obrade svih očitanja kod

kojih nema preklapanja s pretplatama

Avg miss publication execution

time

prosječno vrijeme obrade očitanja kod

kojih nema preklapanja s pretplatama

Publication with matches broj objava kod kojih je postignuto

preklapanje sa barem jednom pretplatom

Average subscription match time prosječno vrijeme traženja jedne objave

50

4.2. Rezultati testiranja

Slika 13 – Prikaz ovisnosti vremena objavljivanja svih očitanja zavisno o broju pretplata

Slika 14 – Prikaz ovisnosti prosječnog vremena objavljivanja jedne objave zavisno o broju pretplata

51

Slika 15 – Standardna devijacija za vrijeme objavljivanja jednog očitanja

Slika 16 – Prikaz ovisnosti ukupnog vremena izvođenja objava s obzirom na porast broja pretplata

52

Slika 17 – Prikaz ovisnosti prosječnog izvođenja objave kod koje postoji preklapanje sa barem jednom

pretplatom

Slika 18 – Standardna devijacija vremena izvođenja jedne objave kod koje postoji preklapanje sa barem

jednom pretplatom

53

Slika 19 – Prikaz ovisnosti ukupnog vremena izvođenja objava kod kojih ne postoji ni jedno preklapanje

sa pretplatama

Slika 19 – Prikaz ovisnosti prosječnog izvođenja objave o broju pretplata, kod koje ne postoji

preklapanje ni sa jednom pretplatom

54

Slika 20 – Standardna devijacija za vrijeme izvođenja jedne objave kod koje ne postoji preklapanje ni sa

jednom pretplatom

Slika 20 – Standardna devijacija za vrijeme izvođenja jedne objave kod koje ne postoji preklapanje ni sa

jednom pretplatom

55

Slika 21 – Ovisnost vremena pronalaska točno jedne pretplate za pristiglo očitanje s obzirom na ukupan

broj pretplata

Slika 22 – Standardna devijacija vremena pronalaska točno jedne pretplate za pristiglo očitanje

56

4.3. Diskusija rezultata

Proučavanjem dobivenih rezultata svakako se može zaključiti da se vrijeme obrade

svakog senzorskog očitanja povećava s brojem pretplata u sustavu. To se odražava i na

ostale rezultate mjerenja poput ukupnog i prosječnog vremena objave očitanja kod kojih

postoji preklapanje s pretplatama. Zanimljivo je s primijetiti dvije stvari; koeficijent

povećanja vremena obrade pretplata kod kojih nema preklapanja je manjeg intenziteta

nego vremena obrade pretplata s preklapanjem. Za pretpostaviti je da je to zbog prostornog

indeksiranja geometrija koje čine pretplatu, čime je sustav efikasniji prilikom izvođenja

prostornih predikata. Također, povećanje prosječnog vremena da bi se pronašla jedna

pretplata koja preklapa senzorsko očitanje raste s manjim koeficijentom nego prosječno

vrijeme obrade senzorskog očitanja kod kojeg postoji preklapanje. Značajna je i činjenica

da je prosječno vrijeme obrade očitanja kod kojeg postoji preklapanje s pretplatom uz

deseterostruko povećanje broja pretplata, raslo s faktorom oko 6. S druge strane, povećanje

prosječnog vremena traženja jedne pretplate je raslo s faktorom 2.5, uz jednako povećanje

broja pretplata. Broj objava kod kojih postoji preklapanje očekivano raste s povećanjem

broja pretplata. Ipak, za taj parametar nije bitno s kojim faktorom raste, jer najvećim

dijelom ovisi o razdiobi generiranih pretplata i objava.

Za kraj se može spomenuti da je sustav skalabilan, jer je povećanje broja pretplata u

sustavu uzrokovalo linearno povećanje vremena obrade očitanja, a ne polinomno.

57

ZAKLJUČAK

Široka pristupačnost mobilnih tehnologija i senzora danas donosi nove načine na koje

znanstvenici mogu pristupati senzorskim očitanjima sa šireg geografskog područja. Osim

same vrste senzorskog očitanja, odnosno pojave koju odabrani senzor mjeri, iznimnu

važnost predstavlja geolokacija senzorskog očitanja. Iz tog je razloga bitno savladati

problem projekcije karata i prikaza kompleksnih geometrija, kao i uspoređivanje istih kroz

prostorne predikate kako bi se utvrdio njihov međusobni odnos. Danas je proces

prikupljanja podataka takav da korisnici definiraju svoje interese za podatcima. Kada

podatci postanu dostupni u obliku očitanja se prosljeđuju do korisnika ako postoji

preklapanje između interesa, odnosno u kontekstu ovog rada pretplate. Gotovo idealna

paradigma koja omogućava stvarnovremensku dostavu podataka korisnicima je objavi-

pretplati. Ipak, prije nego dođe do dostavljanja podataka korisniku, nužno je na efikasan

način riješiti problem pronalaska onih pretplata koje geometrijski i atributno preklapaju

pristiglo senzorsko očitanje. U ovom radu efikasno geometrijsko preklapanje se postiže

korištenjem prostornih indeksa koji su dostupni kroz programsku knjižnicu Java Topology

Suite. Ostvareni sustav objavi-pretplati ima i mogućnost proširenja funkcionalnosti,

odnosno dodavanja novih vrsta senzorskih očitanja kroz sučelje REST na poslužitelju.

Osim poslužitelja, razvijena je i mobilna aplikacija kao klijent koji sudjeluje u sustavu kao

pretplatnik na senzorska očitanja. Konačno, izgrađeni sustav je testiran tako da se

proučavao utjecaj broja pretplata u sustavu na razne parametre objave pristiglih senzorskih

očitanja. Rezultati pokazuju kako sustav na zadovoljavajuće brz način pronalazi pretplate

koje preklapaju pristigla senzorska očitanja. Također, pokazuje se linearno povećanje

vremena obrade pristiglih zahtjeva, odnosno da je sustav skalabilan.

_________________________

58

LITERATURA

[1] HAUPT F; KARASTOYANOVA, D; LEYMANN, F; SCROTH B; Web Services (ICWS), IEEE International Conference on 2014, stranice 129 – 136, London: John Wiley, 2006.

[2] An Album of Map Projections, http://pubs.usgs.gov/pp/1453/report.pdf, 10.6.2015

[3] ASSILZADEH H.; ZHONG, Z.; KASSAB A.S.; GAO J.; LEVY J.K.; Development of even-driven and scalable oil spill monitoring and managment system

[4] PODNAR ŽARKO, I.; PRIPUŽIĆ K.; LOVREK, I; KUŠEK, M; Raspodijeljeni sustavi, radna inačica udžbenika, Zagreb, 2014

[5] Smartphone OS market share Q1 2015, http://www.idc.com/prodserv/smartphone-os-market-share.jsp, 15.5.2015

[6] Zagreb Monthly Climate Average, http://www.worldweatheronline.com/Zagreb-weather-averages/Grad-Zagreb/HR.aspx, 1.5.2015

[7] O Zagrebu, http://www.zagreb.hr/default.aspx?id=1081, 18.5.2015

[8] KASSAB, A; LIANG, S; GAO, Y; Real time notification and improved situational awereness in fire emergencies using geospatial-based publish/subscribe, Science direct, Svezak 12, 2010, 431 – 438

[9] JTS Topology Suite, http://www.vividsolutions.com/jts/JTSHome.htm, 10.5.2015

[10] Understanding spatial relations, http://edndoc.esri.com/arcsde/9.0/general_topics/understand_spatial_relations.htm, 25.5.2015

[11] Cloud messaging, https://developers.google.com/cloud-messaging/, 25.5.2015

[12] N. Sharma. “Push Technology–Long Polling,” International Journal of Computer Science and Management Research, Svezak 2, 2013, pp.2581-2584, ISSN 2278-733

59

SAŽETAK

Ovaj rad obrađuje problem prikupljanja senzorskih očitanja i njihova prosljeđivanja

zainteresiranim korisnicima. Sustav izgrađen u ovom radu ima sposobnost proširenja s

novim vrstama senzorskih očitanja, za koja se potom mogu primati objave. U radu je

razvijen kompletni sustav, što uključuje arhitekturu poslužitelja, algoritme, strukture

podataka i mobilnu aplikaciju kao klijenta. Za definiranje prostornih geometrija korišten je

format GeoJSON, a za izvođenje predikata između dvije geometrije koristi se programska

knjižnica Java Topology Suite. Izgrađeni sustav testiran je sa skupom pretplata i objava

koji su generirani odgovarajućim programom, razvijenim isključivo za potrebe ovog rada.

Rezultati testiranja pokazuju kako je sustav skalabilan, fleksibilan i zadovoljavajuće brz u

prosljeđivanju pristiglih senzorskih očitanja korisnicima čije pretplate preklapa objava.

60

SUMMARY

This thesis focuses on sensor reading acquiring and propagation of readings to

participants in system who are showing interest in such data. System has been built in

flexible manner, so new sensor readings types can be registered at runtime, and then

published as they come. The system built in this thesis is completely functional, including

server arhitecture, algorithms, data structures and mobile application that serves as client.

GeoJSON format is used to describe spatial components, and spatial predicates are

evaluated using Java Topology Suite library. The system has been tested with set of

subscriptions and sensor readings, which are generated using custom program, developed

only to ensure test data. Result are showing that system is scalable, flexible and

satisfactorily fast when it comes to forwarding sensor readings to those clients that have

matching subscriptions for published sensor reading.