SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA DIPLOMSKI RAD br. 926 GEOPROSTORNI REPOZITORIJ SENZORSKIH PODATAKA Antonio Piha Zagreb, lipanj 2015.
1
Zahvala Svima, koliko god Vas ima. 2
Sadržaj Zahvala... 2 Uvod... 4 1. Geoprostorni repozitoriji senzorskih podataka... 5 1.1 Prostorne baze podataka (Spatial databases)... 5 1.1.1 Prostorni tipovi podataka... 6 1.1.2 Prostorno indeksiranje i granične kutije... 7 1.1.3 Koordinatni referentni sustav... 8 1.2 Načini prikupljanja podataka... 9 1.2.1 GeoJSON... 10 1.3 Model objavi-pretplati... 11 1.3.1 Pretplate... 12 1.3.2 Objave... 14 1.3.3 Posrednik... 14 2. Implementacija... 16 2.1 REST sučelje... 18 2.1.1 Resursi sučelja... 20 2.2 Prostorna baza podataka... 22 2.2.1 PostGIS:... 23 2.3 Poslužitelj... 26 2.3.1 Geotools... 26 2.4 Pretplate i objave... 28 2.5 Aplikacija za operacijski sustav Android... 36 2.5.1 Osnovne logičke cjeline Android aplikacija... 36 2.5.2 Komunikacija između aplikacije i poslužitelja... 39 2.5.3 Korištenje aplikacije... 40 3. Analiza performansi sustava... 41 3.1 Mjerenje... 42 3.2 Plan mjerenja... 45 3.3 Rezultati... 48 Zaključak... 56 Literatura... 57 3
Uvod Informacija je cjelina međusobno povezanih podataka od kojih svaki posjeduje neko značenje. Kako je Internet dijeljenje informacije, a informacija se sastoji od podataka, tako su podaci postali ključni u tom procesu dijeljenja. Potrebno ih je pravilno pohraniti, a istovremeno brzo i precizno dijeliti na Internetu. Podaci dolaze iz raznih izvora i u raznim formatima, ali pravu vrijednost dobivaju tek kad ih se obradi u informaciju. Ključno pitanje koje se veže uz podatke je kako ih spremiti na adekvatan način. Kako podaci ne bi bili izgubljeni spremamo ih u spremišta, odnosno repozitorije podataka. Osim spremanja, postoje i mnoge prepreke u rukovanju podacima kao što su količina, raznovrsnost, obrada u stvarnom vremenu te prostorna lokacija na koju se veže taj podatak. Ovaj rad se bavi problemom prikupljanja, skladištenja i distribuiranja podataka koji predstavljaju senzorsko očitanje i koji se vežu na neku lokaciju u prostoru. Prikupljanje senzorskih očitanja je ostvareno korištenjem tehnologije REST, a skladištenje pomoću baze podataka PostgreSQL i dodatka za podršku geoprostornim objektima PostGIS. Dohvaćanje podataka je ostvareno na dva načina, a to su jednokratni upiti i kontinuirani upiti na principu komunikacijskog modela objavi-pretplati. Geoprostorni sustavi koji su ostvareni na principu komunikacijskog modela objavipretplati (GeoPubSub) rješavaju probleme geolokacijske rasprostranjenosti podataka i dohvaćanja novih podataka te su osnovni dio velikih projekata poput praćenja izlijevanja ulja u oceanu, globalnog nadzora vremenskih prilika, nadgledanja lokacija svih taxi vozila unutar prostora koji se prati i slično. Zbog nužnosti obrade podataka u stvarnom vremenu, kao jedan od osnovnih zahtjeva javlja se brzina obrade nadolazećih podataka, odnosno što manje kašnjenje pri njihovoj obradi u ovakvom sustavu. U radu su izmjerene performanse ostvarenog geoprostornog sustava. Prvo poglavlje definira osnovne pojmove geoprostornih repozitorija te daje osvrt na arhitekturu sustava i opisuje način rješavanja osnovnih implementacijskih problema. Drugo poglavlje se bavi komponentama sustava te detaljima njihove implementacije. Treće poglavlje daje uvid u postavljanje sustava i prikazuje rezultate mjerenja njegovih performansi. 4
1. Geoprostorni repozitoriji senzorskih podataka Senzor je uređaj koji pretvara energiju iz jednog oblika u drugi na način da osjeti i detektira karakteristike svoje okoline u obliku kvantitativnih promjena te pruži odgovarajuću mjeru očitane promjene [18]. Primjer senzora je živin termometar zato što pretvara toplinu u širenje volumena žive čija se promjena očituje na kalibriranoj staklenoj cijevi u kojoj se ona nalazi. Senzor je dakle fizički uređaj što znači da imaju svoju lokaciju na kojoj detektira promjene. Uz izmjerenu vrijednost, lokacija je također bitan podatak za bilo koju vrstu mjerenja zato što očitanje s nepoznate lokacije ne znači puno. Stoga je potrebno uz očitanje pohraniti i lokaciju senzora. Svaki senzor također može davati informacije u mnogo različitih formata, međutim pri razvoju ovog sustava se koristio standardizirani format za prikupljanje podataka GeoJSON. Podaci sa senzora su korisne informacije koje imaju raznoliku primjenu, a kako bi se sva mjerenja sačuvala za buduće analize, podatke je potrebno negdje pohraniti. Senzorske podatke možemo spremati, obraditi i dijeliti, a to je upravo zadaća repozitorija podataka koji je ostvaren u praktičnom djelu ovog rada. 1.1 Prostorne baze podataka (Spatial databases) Prostorna baza podataka je slična običnoj bazi podataka, s razlikom da tretira prostorni objekt kao i svaki drugi objekt, tj. sprema ga i manipulira njime kao i običnim objektom. Prostorni podaci su povezani s bazom podataka kroz tri elementa: 1. Prostorni tipovi podataka odnose se na prostorni oblik kojeg predstavljaju geometrijski oblici poput točke, linije ili poligona 2. Višedimenzionalno prostorno indeksiranje služi za efikasniju obradu prostornih operacija 3. Prostorne funkcije definirane u jeziku SQL-, služe za postavljanje upita nad prostornim svojstvima i odnosima 5
1.1.1 Prostorni tipovi podataka Klasična baza podataka prepoznaje riječi (tip String), brojeve (tip Number), datume (tip Date) itd. Prostorna baza podataka dodaje nove tipove koji se nazivaju prostorni tipovi podataka koji posjeduju geoprostorne značajke. Glavna zadaća im je apstrakcija i enkapsulacija prostornih objekata i elemenata od kojih su prostorni objekti sačinjeni, kao na primjer granica i dimenzija objekata. U većini slučajeva ih možemo shvatiti kao geometrijske oblike i modele. Postoji više vrsta tipova prostornih objekata. Najčešće korišteni su: Geometry općenita klasa iz koje možemo stvoriti neki prostorni objekt Point predstavlja točku u prostoru LineString linija sačinjena od više točaka koja ima različit početak i kraj Polygon predstavlja poligon koji je određen s više točaka i zatvara neku površinu, može imati praznine Slika 1. sadrži grafički prikaz najčešće korištenih geometrija, točke, linije i poligona. Slika 1. Primjer geoprostornih objekata 6
Također postoji i hijerarhijska među tim tipovima, tako npr. geometriju nasljeđuje točka i površina, a dalje površinu nasljeđuje poligon. Geometrije ćemo obrađivati pomoću posebnog formata za označavanje i prezentaciju geoprostornih objekata koji se naziva dobro poznati tekst (Well- Known-Text, WKT). On se koristi i za transformaciju i prijenos geometrija između geoprostornih sustava. WKT može prikazati 18 različitih vrsta geoprostornih objekata poput geometrije, točke, linije, poligona, površine, geometrijske kolekcije i sl. Definira se imenom vrste geoprostornog objekta i koordinatama tog objekta u prostoru. Koordinate mogu biti dvodimenzionalne, trodimenzionalne ili četverodimenzionalne. Osim toga, moguće je korištenjem oznake EMPTY opisati i prazni geoprostorni objekt koji ne sadrži koordinate. Tablica 1. WKT zapis geoprostornih oblika Geometrija WKT Točka POINT (30 10) Linija LINESTRING (30 10, 10 30, 40 40, 10 20) Poligon POLYGON (35 10, 45 45, 15 40, 10 20, 35 10) U ovom formatu apscisa može predstavljati zemljopisnu dužinu, a ordinata zemljopisnu širinu. 1.1.2 Prostorno indeksiranje i granične kutije U običnim bazama podataka postoje metode za pristupanje podataka koje su poznate pod nativom indeksi, a služe za brzo dohvaćanje podataka. Standardni tipovi kao brojevi, riječi i datumi se najčešće indeksiraju pomoću indeksa u obliku B- stabla. SRID je kratica od Spatial Reference IDentifier koji definira geoprostornu oznaku i parametre korištenog zemljopisnog koordinatnog sustava te njegove projekcije odnosno prostorne informacije objedinjuje kao jedan jedinstveni broj. Koristi se pri jednoznačnom razlučivanju objekata smještenih u projiciranim, neprojiciranim i lokalnim prostornim koordinatnim sustavima. 7
1.1.3 Koordinatni referentni sustav Geometrija je matematički oblik definiran skupom koordinata čija se projekcija dobiva izračunima nad tim koordinatama. Usporedimo geometriju s nekim brojem, npr. 100, taj broj sam za sebe nema značenje, bar ne značenje koje nam je od koristi, postavimo pitanje npr. 100 čega? Ono što samom broju nedostaje da bi imao značenje je mjerna jedinica čime oni skupa predstavljaju neki podatak, npr. 100 ljudi. Geometrija kao skup točaka ne nudi točno značenje tim individualnim točkama, a značenje im daje mjerna jedinica koja se naziva lokacija. Lokacija daje značenje geometriji, a struktura koja omogućava definiranje lokacije naziva se koordinatni referentni sustav. Slika 2. Kartezijev koordinatni sustav [19] Slika 3. Polarni koordinatni sustav [20] Koordinatni referentni sustav pruža razne podatke vezane za određivanje lokacije. Definira osi i mjerne jedinice koje koristi, npr. zemljopisnu dužinu u stupnjevima, a zemljopisnu širinu mjeri u stupnjevima uz ekvator kao ishodište. Također osi mogu biti u metrima za lakše računanje udaljenosti, površina i slično. Najpoznatiji koordinatni sustavi za prikaz točaka su Kartezijev i polarni koordinatni sustav koji su prikazani na slikama 2 i 3. Sferni koordinatni sustav opisuje svaku točku pomoću dva parametra, a to su udaljenost točke od ishodišta i kut za kojeg je točka odmaknuta od osi. U ostvarenom sustavu koristit ćemo Kartezijev koordinatni sustav kod kojeg apscisa predstavlja zemljopisnu dužinu, a ordinata predstavlja zemljopisnu širinu. Ishodište tog sustava je sjecište ekvatora i nultog meridijana, a 8
sustav će biti prikazan kao ravnina umjesto zakrivljenog prostora kao što je Zemlja u stvarnosti. 1.2 Načini prikupljanja podataka Geoprostorni informacijski sustavi (Geographic Information Systems, GIS) koriste različite formate datoteka za razmjenu podataka. Razvoj tih sustava kroz povijest je rezultirao velikim brojem različitih zapisa u kojima se geoprostorni podaci predstavljaju. Danas postoje standardni formati poput datoteka Shapefile i Geographic Data File. Shapefile je jednostavan format koji zapisuje objekte u obliku vektorskih podataka sačinjenog od točaka, linija i poligona, gdje svaki od njih može imati atribute za dodatni opis zapisanog objekata. Koordinate spremljene u tom formatu pretpostavljaju korištenje Kartezijevog koordinatnog sustava, a redoslijed koordinata dvodimenzionalnog prostora je apscisa pa ordinata. Bitno je spomenuti da se zapis ne sastoji od jedne već od tri različite datoteke. Iako se sama geometrija nalazi u jednoj datoteci naziva shapefile (s ekstenzijom.shp), za dijeljenje te geometrije su potrebne druge dvije datoteke koje sadržavaju njen prostorni indeks i atribute koji je dodatno opisuju. Postoje gotovi alati za učitavanje geoprostornih objekata iz tog formata u bazu podataka, npr. za GIS OSM (OpenStreetMap) je razvijen alat osm2pgsql kojim se podatke može direktno prebaciti iz Shapefile-a u bazu podataka PostgreSQL, ukoliko ona ima instaliran dodatak PostGIS. Sučelje REST (REpresentational State Transfer) je arhitekturni stil razmjene podataka za raspodijeljene umrežene sustave. Temelji se na konceptu identifikacije resursa pomoću univerzalnog identifikatora resursa (Universal Resource Identifier, URI). Svaki resurs može biti postavljen, dohvaćen ili modificiran kroz standardno sučelje koje implementira operacije Stvori-Pročitaj-Osvježi-Izbriši (Create-Read- Update-Delete, CRUD)) te se prenosi nekim standardnim protokolom, npr. HTTPom, a sama informacija predstavlja reprezentaciju tog resursa. Repozitorij razvijen u praktičnom dijelu ovog rada prikuplja podatke upravo kroz takvo sučelje. Podaci odnosno senzorska očitanja pristižu od raznih senzora koji se nalaze na različitim lokacijama u prostoru. 9
1.2.1 GeoJSON Format GeoJSON sintaksom odgovara formatu JSON te na njegovu logiku dodaje semantiku za razne geografske podatkovne strukture. On može predstavljati geometriju, oblik ili kolekciju oblika. Podržava sljedeće geometrijske tipove: Točka (Point) Linija (LineString) Poligon (Polygon) Više točaka (MultiPoint) Više linija (MultiLineString) Više poligona(multipolygon) Kolekcija geometrija (GeometryCollection). U tom formatu, oblici sadrže geometrijski oblik, dodatna svojstva i kolekciju oblika koji su sastavljeni u listu oblika. Kao i klasični format JSON, tako je i GeoJSON podatkovna struktura koja predstavlja objekt koji se sastoji od više parametara (parova ključ-vrijednost) koji su njegovi sastavni dijelovi. GeoJSON se uvijek sastoji samo od jednog objekta koji može biti geometrijski tip, oblik ili kolekcija oblika te poštuje sljedeća pravila: Ima bilo koji broj parova ključ-vrijednost odnosno parametara Jedan od parametara odnosno ključeva mora biti type koji definira tip koji objekt predstavlja Vrijednost pod ključem type mora biti jedna od sljedećih: Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, GeometryCollection, Feature, ili FeatureCollection Sadržava opcionalni parametar pod ključem crs kojim se definira koordinatni referentni sustav (Coordinate Reference System, CRS) Sadržava parametar bbox pod čijom se vrijednošću definira granična kutija objekta Bilo koji geometrijski oblik osim kolekcije geometrija GeometryCollection mora sadržavati parametar pod ključem coordinates kojim se definiraju 10
njegove koordinate odnosno pozicija objekta, a vrijednost je niz brojeva koji ima najmanje dva elementa Lokacija x,y,z se određuje na temelju koordinata objekta i na temelju koordinatnog referentnog sustava. Redom x,y,z predstavlja istok, sjever i visinu za projicirane koordinatne referentne sustave, dok u geografskim koordinatnim referentnim sustavima predstavljaju redom dužinu, širinu i visinu. Oblici u formatu GeoJSON su tipa Feature i poštuju sljedeća načela: Obavezan parametar s ključem geometry čija vrijednost predstavlja geometrijski objekt ili vrijednost null Obavezan parametar s ključem properties koji pod svojom vrijednošću sprema JSON objekt koji sadrži dodatna svojstva tog objekta 1.3 Model objavi-pretplati U sustavima, koji imaju zadaću dostavljanja sadržaja velikom broju korisnika u stvarnom vremenu na temelju nekog novonastalog podatka, se često koristi neki oblik komunikacijskog modela objavi-pretplati. Ovaj model definira dvije vrste entiteta koji sudjeluju u razmjeni podataka. S jedne strane imamo pretplatnike (subscribers) koji definiraju svoju pretplatu na temelju koje će primati podatke koji ih interesiraju, dok s druge strane imamo objavljivače (publishers) koji posjeduju neki podatak, objave ga u sustav te time stvore novu objavu koja će se dalje proslijediti potencijalnim pretplatnicima. Takav sustav također predstavlja određenu anonimnost u tome što subjekti međusobno ne komuniciraju izravno, već preko posrednika. Sustav koji je razvijen u ovom radu, također nudi mogućnost jednokratnih upita, koji su slični pretplati, ali dok je pretplata cijelo vrijeme aktivna, ovi upiti ne rtaju, već vrijede samo dok se ne izvrše. Model komunikacije objavi-pretplati se razlikuje od klasičnih upita po obliku komunikacije između korisnika sustava. Kod jednokratnih upita korisnik kojega zanimaju podaci će postaviti upit posredniku te se nadati da će eventualno dobiti zadovoljavajući odgovor. Takav korisnik nema informaciju o tome postoji li uopće odgovarajuće očitanje na posredniku koji odgovara njegovom upitu. U ovom modelu smjer komunikacije je usmjeren od klijenta prema posredniku. Kod modela 11
objavi-pretplati smjer komunikacije je obrnut, dakle posrednik će kontaktirati pretplatnika kada bude imao informaciju koja odgovara njegovoj pretplati. Komunikacija se neće ni ostvariti ukoliko ne bude podataka koji bi zadovoljili pretplatu tog pretplatnika. U suprotnom slučaju posrednik će proslijediti pretplatnikupodatak koji odgovara pretplati. Takvim modelom se također smanjuje opterećenje na posredniku i mrežno opterećenje jer se izbjegavaju periodični upiti na poslužitelj od kojih će neki vratiti traženi resurs dok će većina odgovora samo dati informaciju da poslužitelj trenutno ne posjeduje odgovarajući resurs za taj upit. 1.3.1 Pretplate Pretplatnik je definiran s jednom ili više pretplata. Pretplata se sastoji od raznih uvjeta ovisno o području interesa pretplatnika. Svakom pretplatom pretplatnik, kao krajnji korisnik sustava, unaprijed definira kakve podatke točno želi primati. Dakle proces pretplate se temelji na određivanju filtera te dojave te pretplate posredniku koji je zadužen za objave. Filter se može definirati i kao prazan, što bi značilo da će pretplatnik primiti svaku vrstu novog očitanja iako to baš i nema nekog smisla. Posrednik zato omogućuje pretplatnicima definiranje filtera na temelju određenih metapodataka koji su njemu poznati. Na temelju definiranog resursa objave možemo logičnim zaključivanjem definirati pretplatu kao resurs koji sadrži: Identifikator pretplatnika Geoprostornu lokaciju predstavlja poligon ili neku drugu geometriju koja definira lokaciju od interesa (objave će se prostorno filtrirati po njoj) Vrstu očitanja Mjernu jedinicu očitanja Donji interval vrijednosti očitanja sa senzora moraju biti veća ili jednaka ovoj vrijednosti da bi zadovoljili pretplati Gornji interval vrijednosti - očitanja sa senzora moraju biti manja ili jednaka ovoj vrijednosti da bi zadovoljili pretplati Ovakvim načinom filtriranja se lako može doći do problema da je očitanje zadano u jednoj mjernoj jedinici, a pretplata u drugoj. 12
Kod objave senzorskih podataka često se radi o nekoj jednostavnoj vrsti očitanja, npr. temperaturi koja se definira u Celzijusima, a pretplata može biti definirana u drugoj mjernoj jedinici npr. Kelvinima. Sustav će omogućiti pretplatniku definiranje pretvorbe iz jedne mjerne jedinice u drugu pomoću formule koja se definira prije aktiviranja pretplate. Korisnicima razvijenog sustava su na raspolaganju informacije o svim vrstama očitanja i mjernim jedinicama tako da oni mogu provjeriti kakvim sve vrstama mjernih jedinica repozitorij raspolaže i trebaju li definirati pretvorbenu formulu iz jedne mjerne jedinice u drugu. Sustav ignorira pretplate koje su efinirane s nekom nepostojećom vrstom mjerne jedinice. Jednokratni upiti se sastoja od sljedećih podataka: Geoprostorna lokacija predstavlja poligon ili neku drugu geometriju koja definira lokaciju od interesa (objave će se prostorno filtrirati po njoj) Vrsta očitanja Mjerna jedinica očitanja Donji interval vrijednosti očitanja sa senzora moraju biti veća ili jednaka ovoj vrijednosti da bi zadovoljili pretplati Gornji interval vrijednosti očitanja sa senzora moraju biti manja ili jednaka ovoj vrijednosti da bi zadovoljili pretplati Donji interval vremenskog očitanja očitanja koja su se dogodila nakon ovog definiranog datuma i vremena Gornji interval vremenskog očitanja očitanja koja su se dogodila prije ovog definiranog datuma i vremena U jednokratnom upitu je potrebno definirati vremensko razdoblje unutar kojeg nas zanimaju očitanja, jer ako tražimo očitanja koja su se dogodila upravo u vrijeme upita, postoji velika šansa da ih neće biti. Stoga je za dobivanje liste očitanja potrebno definirati vremenski interval. Model objavi-pretplati, kao i ostvareni sustav, nudi svojim korisnicima mogućnost odustajanja od pretplate. 13
1.3.2 Objave U ostvarenom sustavu objavljivači novih podataka su senzori pa je stoga objava definirana kao novonastalo očitanje. Svako očitanje se sastoji od nekoliko ključnih podataka vezanih za taj senzor: Geoprostorna lokacija predstavlja točku ili poligon ili neku drugu geometriju koja tom očitanju daje prostorno značenje Vrsta senzora Vrsta mjerenja koja je vezana za vrstu senzora Vrijeme u kojem se očitanje dogodilo Vrijednost očitanja Mjerna jedinica za tu vrijednost Objave u ostvarenom sustavu imaju dva zadatka. Prvi zadatak je objava kao slanje podataka sa senzora u ostvareni repozitorij podataka. Drugi zadatak je objava kao slanje podataka iz repozitorija do pretplatnika. Prvi zadatak je jednostavniji i ostvariv je spajanjem senzora na Internet te slanjem očitanja preko HTTP-a ostvarenom repozitoriju kojim se stvara novi resurs i pohranjuje se očitanje u bazu podataka. Taj dio se obavlja preko prethodno definiranog sučelja REST. Postoji lančana poveznica između prvog i drugog dijela, kada se uspješno izvrši prvi zadatak, odmah nakon repozitorij počne izvršavati drugi zadatak. Drugi zadatak je zapravo zadaća posrednika koji će distribuirati prikupljene podatke pretplatnicima. 1.3.3 Posrednik Posrednik je u arhitekturnom smislu kombinacija poslužitelja, baze podataka i distributera podataka. Posrednik na temelju objavljenog očitanja pronalazi sve pretplate čije kriterije objava zadovoljava. Bitno je objasniti redoslijed kojim se pronalaze odgovarajuće objave i pretplate. Kod jednokratnog upita se (posebne vrste pretplate koja se ne pohranjuje u bazu) na temelju njegovih kriterija pronalaze sve odgovarajuće objave koje ih zadovoljavaju. 14
Kod kontinuiranih upita (pretplata pohranjenih u bazu podataka), sena temelju podataka iz pristigle objave pronalaze sve odgovarajuće pretplate na način da se ispituje odgovaranje objave svakoj pretplati. Ukoliko objava zadovoljava kriterije neke pretplate tada se ona dodaje u listu pretplata čijim pretplatnivima će biti poslana pristigla objava. Kao što je već spomenuto, objave i pretplate definiraju vrstu mjerenja i mjernu jedinicu očitanja. Dakle možemo imati objavu čija je vrsta mjerenja postavljena tako da je jednaka nekoj pretplati ili da su one definirane u dvije različite mjerne jedinice. Npr. objava je definirana vrstom mjerenja temperatura i mjernom jedinicom C (Celziji, dok je neka pretplata definirana također vrstom mjerenja temperatura, ali u drugoj mjernoj jedinici K (Kelvini ). Taj problem se riješava definiranjem formule konverzije iz jedne mjerne jedinice u drugu. Nova formula je definirana sa sljedećim karakteristikama: Vrsta mjerenja formula vrijedi samo za tu vrstu mjerenja Iz mjerne jedinice definiramo iz koje mjerne jedinice će se vršiti pretvorba U mjernu jedinicu definiramo mjernu jedinicu u koju želimo pretvoriti vrijednost Formula pretvorba će se izračunavati na temelju ove formule U ovom primjeru, definirat ćemo pretvorbu za vrstu mjerenja temperatura, iz mjerne jedinice C, u mjernu jedinicu K, pomoću formule (1). K = C + 273.15 (1) Ostvareni sustav pretvara vrijednost iz dobivenog očitanja te na temelju te pretvorene vrijednosti uspoređuje objavu i pretplatu. Pritom ispituje granice intervala vrijednosti pretplate, a kako su one zadane u mjernoj jedinici pretplate, potrebno je vrijednost objave pretvoriti u mjernu jedinicu pretplate i tada provjeriti jeli ona u traženom intervalu. 15
2. Implementacija Poslužitelj GlassFish omogućava izradu i razvijanje te puštanje u rad aplikacija razvijenih za Javinu platformu Enterprise. Za razvoj ostvarenog sustava korišten je poslužitelj GlassFish 4.1 koji između ostalog nudi sljedeće funkcionalnosti: Laganu i proširivu jezgru temeljenu na poznatim standardima Kontejner za web aplikacije Jednostavno web sučelje za konfiguraciju, kroz koje smo podesili bazu podataka Posrednik između sučelja REST i baze podataka PostgreSQL je zapravo aplikacija napisana u Javi koja je pokrenuta na poslužitelju GlassFish u obliku arhive WAR (Web application Archive) koji se često koristi za distribuciju Javinih web aplikacija. Slika 4. prikazuje elemente ostvarenog repozitorija. Slika 4. Komponente repozitorija 16
Poslužitelj i baza podataka se nalaze u istoj mreži te su izravno povezani, a pokrenuti su kao instance na operacijskom sustavu Debian GNU/Linux 7.8 (wheezy). Instanca poslužitelja GlassFish ima javno dostupnu URL adresu na lokaciji: https://gprsp.no-ip.org:8080/, fizička lokacija je računalo unutar FER-ove mreže. Poslužitelj GlassFish dolazi s integriranim administracijskim web sučeljem koje se nalazi na istoj adresi, ali na portu 4848, za kojeg je potrebno imati administratorskog korisnika: Tablica 2. Podaci za administratorski pristup poslužitelju Korisničko ime admin Lozinka repozitorij Slika 5. Administracijsko sučelje poslužitelja i postavke veze na bazu podataka Kroz administracijsko sučelje podešena je veza na bazu podataka koju koristimo unutar same aplikacije pokrenute na poslužitelju, što je prikazano na Slici 5. Aplikaciju je potrebno postaviti također kroz administratorsko sučelje. Ostvarena aplikacija za razvoj zapakirana u Java WAR format datoteke koju je vrlo jednostavno postaviti kroz isto sučelje. 17
2.1 REST sučelje U Javi postoji JAX-RS koji je zapravo API na razini programskog jezika koji olakšava razvoj aplikacija u REST modelu, a koristi anotacije nad klasama i metodama te olakšava razvoj i spremanje konfiguracije i implementacije u jednu datoteku. Anotacijama se definiraju odgovornosti za pojedine klase i njihove metode. Njima se određuje koja je metoda zadužena za obradu pojedinog URI-a, koji tip resursa taj URI podržava, a također je moguće detaljnije podešavati resurs, npr. vremenski period trajanja resursa i kontrolu pohrane u privremenu memoriju (Expire i Cache Control). Anotacije koje definiraju vrstu zahtjeva koje metoda podržava odgovaraju istoimenim metodama protokola HTTP, npr. anotacija @DELETE odgovara metodi DELETE protokola HTTP, a detaljniji opis nalazi se u tablici 3. Anotacija Opis Tablica 3. Java REST anotacije za metode i klase @Path Predstavlja relativan URI koji je putanja do lokacije gdje su Java klase biti posluživane. Primjer: /rest. Također podržava ugradnju varijabli. Primjer s varijablom: /rest/{akcija} @GET Označava vrstu zahtjeva koju metoda podržava i odgovara istoimenoj HTTP metodi GET. @POST Označava podršku za procesiranje HTTP POST zahtjeva. @PathParam Definira tip parametra koji se izvuče iz zahtjeva i može se koristiti unutar resursa odnosno klase. Ime parametra je definirano @Path anotacijom te se izvlači iz URI-a zahtjeva. @Consumes Specificira MIME tip koji opisuje resurs poslan s klijenta. @Produces Specificira MIME tip resursa koji metoda generira i šalje na natrag klijentu. Primjer : application/json Svaki senzor postavlja resurs odnosno očitanje kroz sučelje REST upost za kreiranje resursa. Svaki zahtjev koji pristigne na sučelje prvo prolazi kroz glavnu klasu za obradu zahtjeva koja se naziva korijen klasa resursa (Root resource class). Ta je klasa u Javi zapravo običan POJO (Plain Old Java Object), ali da bi ta klasa bila korijen mora zadovoljavati ove uvjete: nad klasom postoji anotacija @Path 18
ima bar jednu metodu koju opisuje anotacija @Path ima bar jednu metodu koju opisuje oznaka za vrstu zahtjeva koju podržava, a oznake su @GET, @PUT, @POST, @DELETE Ono što razlikuje resurs na sučelju je parametar sadržan u zahtjevu. Tim parametrom dolazimo do traženog resursa, a postoji više vrsta samih parametara: Query parametri se nalaze u samom URI-u zahtjeva i to u query dijelu koji se definira tako da se na URI doda? nakon kojeg slijede parametri u obliku ključ=vrijednost koji su odvojeni znakom & što možemo interpretirati kao dodatne postavke upita. Izvlači se pomoću anotacije @QueryParam. Primjer: /rest?id=123, u ovom slučaju parametar je id s vrijednosti 123. URI dio također se nalaze u URI-u, ali ovaj put su zapakirani u URI i potrebno ih je izvući iz njega pomoću anotacije @PathParam. Primjer: /rest/123, u ovom slučaju je s anotacijom definirano da je traženi parametar id s vrijednošću iz URI-a koja je 123. Form izvlačenje parametara iz zahtjeva koji je MIME tipa application/x-www-form-urlencoded Cookie izvlačenje parametara iz kolačića definiranih u HTTP zaglavljima Ostvareni sustav nema definirane zahtjeve za prijavom korisnika, registracijom i slično, stoga nam načini Cookie i Form ne odgovaraju. Parametri Query i URI su vrlo slični s razlikom da prvi ne moraju biti svi definirani i ne moraju poštivati redoslijed kojim ih definiramo dok drugimoraju točno zadovoljiti redoslijed te svaki parametar mora biti definiran ako želimo definirati sljedećeg. Npr. kod URI parametara, ako je URI definiran kao /rest/{param1}/{param2} tada moramo konstruirati URI tako da prvo postavimo param1 i koji mora biti postavljen ako želimo definirati param2. Definirani su resursi koji logički odgovaraju zahtjevima implementacije, a također su sukladno tome omogućene samo pojedine metode vrsta zahtjeva koje pojedini resurs može obraditi na određenom URI-u. Baza za sučelje je klasa Application iz paketa GlassFish Jersey koja služi kao klasa ispred svih drugih pomoću koje se učitaju druge klase sučelja. 19
Svaka objava i pretplata koju aplikacija šalje mora biti u formatu GeoJSON i to u obliku objekta FeatureCollection koji se sastoji od liste objekata Feature. Primjer GeoJSON formata prikazan je na slici 6.Izabran je taj format zbog mogućnosti dodavanja više pretplata i objava u jednom zahtjevu. Svaki objekt tipa Feature se sastoji od geometrije i dodatnih svojstava. 2.1.1 Resursi sučelja Slika 6. GeoJSON struktura zapisa podataka Svaki resurs ima svoj URI, a URI odgovara URL-ovima koji su javno dostupni. Implementirani su unutar klase Rest: @Path("/api") public class Rest Svaki URI je jedna metoda te klase, a one su opisane u nastavku. 20
Za dohvaćanje, u JSON obliku, popisa svih vrsta senzora i odgovarajućih mjernih jedinica koje pripadaju toj vrsti senzora, a postoje u repozitoriju se koristi sljedeća metoda @GET @Path("/sensortypes") @Produces(MediaType.APPLICATION_JSON) public String sensortypes() Za jednokratne upite se koristi sljedeća metoda: @POST @Path("/singlequery") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public String singlequery(string geojson) Pretplaćivanje na repozitorij se ostvaruje sljedećom metodom: @POST @Path("/subscribe") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public String subscribe(string geojson) Dohvaćanje svih pretplata za pretplatnika čiji se ID prosljeđuje u samom URI-u se obavlja sljedećom metodom: @GET @Path("/subscriptions/{identifikator_pretplatnika}") @Produces(MediaType.APPLICATION_JSON) public String subscriptions(@pathparam("identifikator_pretplatnika") String subscriptionid) Brisanje svih pretplata pretplatnika pod ID-jem koji se prosljeđuje kao parametar URL-a se ostvaruje sljedećom metodom: @DELETE @Path("/unsubscribe/{identifikator_pretplatnika}") @Produces(MediaType.APPLICATION_JSON) public String unsubscribe(@pathparam("identifikator_pretplatnika") String subscriptionid) Nova senzorska očitanja se objavljuje sljedećom metodom 21
@POST @Path("/publish") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public String publish(string geojson) Nova formula pretvorbe iz jedne mjerne jedinice u drugu se stvara sljedećom metodom: @POST @Path("/conversion") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public String conversion(string json) Postojeće formule pretvorbe se dohvaćaju sljedećom metodom: @GET @Path("/conversions") @Produces(MediaType.APPLICATION_JSON) public String conversions() 2.2 Prostorna baza podataka Baza podataka korištena u ovom sustavu je PostgreSQL. Ona pripada grupi ORDBMS odnosno objektno relacijski sustav upravljanja podacima te implementira većinu bitnih SQL standarda poput ACID-a, transakcija i otporna je na probleme zaključavanja, a sve u svrhu sigurnog spremanja i preciznog posluživanja podataka. Konfiguracijski podaci za spajanje na bazu podešeni su kroz poslužitelj, a korištene su klase knjižnice GeoTools iz razloga što se svi objekti moraju pretvoriti u pogodne za spremanje u bazu, a to je podržano ovom kjižnicom. public class Database { private final static String DB_TYPE = "postgis"; private final static String DB_NAME = "GeospatialPostgis"; private DataStore datastore; protected void connectspatial(string typename) throws Exception { Map<String, Object> map = new HashMap<String, Object>(); map.put( "dbtype", DB_TYPE); map.put( "jndireferencename", DB_NAME); DataStore datastore = DataStoreFinder.getDataStore(map); 22
Objekt datastore instanciran iz klase DataStore sadrži instancu baze podataka. 2.2.1 PostGIS: PostGIS je ekstenzija za bazu podataka PostgreSQL koja je pretvara iz klasične u prostornu. Podržava sve funkcije i objekte definirane u specifikaciji OpenGIS ( Simple Features for SQL ) te je otvorenog koda. Postoji još sličnih ekstenzija kao što su Oracle Spatial, DB2 Spatial i SQL Server Spatial, ali za druge baze podataka, dok je PostGIS zapravo PostgreSQL Spatial odnosno odgovara samo bazi PostgreSQL. Kao i sve druge ekstenzije tog tipa on proširuje bazu na sljedeći način: dodaje pojam geometrijskog tipa podataka geometry među klasične tipove kao što su varchar, integer, date i slično. Dodaje funkcije koje primaju geometrijski tip podataka geometry i vraćaju korisne informacije vezane uz taj objekt, primjeri funkcija: ST_Distance(geometry, geometry), ST_Area(geometry) i ST_Intersects(geometry, geometry) Koristi se u klasičnim SQL upitima kao i druge funkcije koje su podržane u SQL-u. Implementira razne funkcije koje omogućuju stvaranje i rukovanje geoprostornim podacima. Neke od PostGIS funkcija nalaze se u tablici 4. Tablica 4. Opis PostGIS funkcija Funkcija ST_MakePoint ( Širina, Dužina ) ST_GeomFromText( WellKnownText, Srid ) Opis Kreira i vraća novu točku. Prima koordinate čiji je redoslijed bitan, širina pa dužina. Kreira i vraća novu geometriju koju stvara iz parametra koji je WKT string i srid-a. 23
ST_AsText( Geometry ) ST_AsGeoJSON( Geometry ) ST_Distance( Geometry, Geometry ) ST_Intersects( Geometry, Geometry ) Vraća geometriju danu kao parametar u tekst formatu koji je čovjeku lako čitljiv. Vraća geometriju danu kao parametar u GeoJSON obliku. Vraća udaljenost između dvije geometrije predane kao parametri, u jedinici određenoj referentnim koordinatnim sustavom. Vratit će istinu (true) ako dvije geometrije predane kao parametri imaju presjek odnosno presijecaju se, inače je laž (false). Za ispravan rad aplikacije, odnosno spremanje i dohvaćanje podataka, je bilo nužno u bazi stvoriti nekoliko tablica. Tablice nisu normalizirane jer je to izvan okvira ovog zadatka. Tablice smo stvorili pomoću alata PgAdminIII koji omogućava upravljanje bazom podataka odnosno stvaranje, modifikaciju i brisanje tablica. Ime baze podataka PostgreSQL je GeospatialRepositorySensorData, a sve tablice također imaju simboličko ime koje opisuju čemu služe. Tablica senzorska_ocitanja koristi se za pohranu prikupljenih senzorskih očitanja odnosno objava sa senzora. Svaka objava koja sadrži sve informacije o jednom senzorskom očitanju je pohranjena u tablicu baze koja je prikazana u tablici 5. Tablica 5. Struktura zapisa u bazi podataka u koju se spremaju objave public.senzorska_ocitanja Id bigserial primary key Lokacija geometry Vrijeme_ocitanja timestamp Identifikator_senzora varchar(50) Tip_senzora varchar(50) Vrsta_ocitanja varchar(50) 24
Vrijednost float Jedinica_ocitanja varchar(50) Kontinuirani upiti su perzistentni te se oni spremaju u bazu podataka. U ostvarenom sustavu to je postignuto pohranom pretplata koje pristignu od korisnika u tablicu pretplate, a sve što je vezano za relaciju pretplatnik-pretplata se može saznati iz te tablice čija je struktura prikazana u tablici 6. Tablica 6. Struktura zapisa u bazi podataka u koju se spremaju pretplate public.pretplate Id bigserial primary key Geometrija_pretplate geometry Identifikator_pretplatnika timestamp Identifikator_senzora varchar(50) Vrsta_ocitanja varchar(50) Jedinica_ocitanja varchar(50) Interval_donji float Interval_gornji float Prilikom definicije ostvarenog sučelja REST odredili smo resurs kojim će se moći dohvatiti informacije o svim vrstama očitanja i mjernih jedinica koje se vežu uz njih. Efektivno ova tablica sadrži popis tih podataka na temelju objava koje postoje u bazi, a kako bi što više ubrzali potragu za tim podacima, pospremit ćemo ih u ovu tablicu koja služi kao priručno spremište. Kada stigne objava, prvo se provjerava postoji li već zapis o vrsti očitanja i mjernoj jedinici u ovoj tablici. Ako ne postoji stvara se novi zapis s tim podacima. Tako smo ubrzali dohvaćanje tih podataka u odnosu da smo pretraživali po svim objavama te tako dohvaćali te podatke. Tablica 7. Struktura zapisa u bazi podataka za pohranu podataka o senzorima public.podaci_o_senzorima Id bigserial primary key Vrsta_ocitanja varchar(50) Jedinica_ocitanja varchar(50) 25
Tablica konverzije sadrži formule za pretvorbe vrijednosti iz jednih mjernih jedinica u druge, a formule su vezane uz vrstu očitanja. Također prije zapisivanja se provjerava postojanje formule za vrstu očitanja, kako ne bi došlo do kolizije u odlučivanju, što znači da za neku vrstu mjerenja može postojati samo jedna formula pretvorbe iz jedne mjerne jedinice u drugu. Tablica 8. Struktura zapisa u bazi podataka u koju se spremaju pretvorbene formule public.konverzije Id bigserial primary key Vrsta_ocitanja varchar(50) Iz_mjerne_jedinice varchar(50) U_mjernu_jedinicu varchar(50) Formula varchar(500) 2.3 Poslužitelj Korišteni su Javini RESTful web servisi za ostvarenje sučelja koje implementira paket Jersey koji dolazi s izabranim poslužiteljem GlassFish. Paket Jersey je implementacija JAX-RSa koji podržava anotacije koje olakšavaju izgradnju samog REST sučelja zato što svu definiciju otvorenih URL-ova možemo pospremiti unutar jedne klase odnosno datoteke. 2.3.1 Geotools GeoTools je besplatni alat otvorenog koda napisan u Javi koji omogućava korištenje vektorskih i rasterskih prostornih podataka. Sastoji se od velikog broja modula koji omogućavaju pristup GIS podacima u datotekama raznih formata i prostornim bazama podataka. Ključna stavka je oblik (feature). Oblik se poistovjećuje s Javinim objektom, a po definiciji može biti neki objekt iz stvarnog svijeta (npr. Himalaja). Kao i objekti u Javi tako i oblici sadrže informacije o stvarnom predmetu kojeg predstavljaju, a organizirani su u atribute (baš kao što su u Javi polja objekta). U Javi razred (klasa) grupira objekte koji imaju iste ili slične karakteristike, a tako FeatureType grupira oblike. Ova knjižnica koristi terminologiju koja je pomalo različita od Javine što se vidi u tablici 9. 26
Tablica 9. Istovjetnost značenja klasa u GeoTools knjižnici i Javi Java Object Class Field Method GeoSpatial Feature FeatureType Attribute Operation GeoTools nudi sučelja za Feature, FeatureType i Attribute. Oblik vrlo često ima jednostavne atribute koji su tipa String, Integer i Date, a ne reference na druge oblike te stoga postoji i klasa dijete oblika koja se zove SimpleFeature. Na razini Java koda oblik je sličan klasi java.util.map zato što služi za spremanje informacije pa tako se vrijednosti atributa mogu pretraživati po ključu, dok je lista ključeva sadržana u klasi FeatureType. Oblik se od objekta razlikuje svojstvom određenosti koji se zove lokacija dakle sadrži informaciju o svojoj lokaciji kako bi ga mogli prikazati na karti. Lokaciju objekta predstavlja geometrija (Geometry) koja je spremljena u atribut oblika. Geometrija može biti npr. točka, linija ili poligon, te je određena jednom ili više točaka i površina. GeoTools interno za prikazivanje i obradu geometrijskih oblika koristi knjižnicu JTS (Java Topology Suite) koja nudi efikasnu implementacijuggeometrija. Geometrije mogu biti prikazane i instancirane iz raznih formata zapisa kao što je WKT. Prostorni podaci se obrađuju kroz sučelje DataStore API koje može predstavljati datoteku, uslugu ili bazu podataka koja ih sadrži. Za dohvaćanje se koriste GeoTools-ovo sučelje FeatureSource, a za spremanje FeatureStore. Usporedba klasa knjižnice GeoTools i JDBC drivera nalazi se u tablici 10. Tablica 10. Istovjetnost značenja klasa u GeoTools knjižnici i upravljaču bazom podataka JDBC driver-u GeoTools FeatureSource FeatureStore FeatureCollection JDBC View Table PreparedStatement 27
GeoTools FeatureIterator JDBC ResultSet SimpleFeatureSource featuresource = database.getsimplefeaturesource(); if (featuresource instanceof SimpleFeatureStore) { SimpleFeatureStore featurestore = (SimpleFeatureStore) featuresource; // Za zapisivanje - WRITE ACCESS SimpleFeatureCollection collection = new ListFeatureCollection(dataBase.getShapeType(), features); featurestore.settransaction(transaction); try{ featurestore.addfeatures(collection); transaction.commit(); } catch(exception e) { transaction.rollback(); throw e; } finally { transaction.close(); database.dispose(); } } 2.4 Pretplate i objave Kada nova objava pristigne u sustav potrebno je pronaći pretplate kojima će ta objava biti poslana. Pretplatnike se redom traži po logičkim cjelinama, dakle prvo se funkcijom ST_Intersects uspoređuje geometrija pretplate i objave da se utvrdi postoji li među njima presijecanje. Ova je PostGIS-ova funkcija koja se poziva kroz knjižnicu Geotools. Zajedno s geometrijom provjerava se i vrsta mjerenja u objavi i ona koja je definirana pretplatom. Zatim se provjeravaju ostali parametri pretplata i objave. Ako ne postoji formula pretvorbe automatski objava ne zadovoljava pretplatu, što je i logično jer pretplatnik nije unaprijed definirao pretvorbenu formulu pa možemo zaključiti da ga te objave ne zanimaju. Pretplate i objave, uspoređujemo u dvije grupe, a prva grupa usporedbi sastoji se od usporedbe geometrije i vrste mjerenja preko upita na bazi. Ovo je napravljeno zbog dinamičkih pretvorbi mjernih jedinica jer kada prva grupa usporedbe vrati potencijalne pretplatnike, tada se za svakog pretplatnika mora dohvatiti formulu pretvorbe iz baze podataka te se u memoriji poslužitelja mora odraditi prilagodba objave na pretplatu na osnovu čeka se konačno može odraditi drugu grupu 28
usporedbi koja se sastoji od provjere postojanja formule i provjere pripadanja vrijednosti objave intervalu vrijednosti pretplate. Algoritam traženja pretplatnika za jednu objavu se sastoji od sljedećih koraka, uz napomenu da se algoritam zaustavlja ukoliko bilo koji korak nije zadovoljen: 1. Provjera presijecanja geometrija, funkcija ST_Intersects, primjer presijecanja prikazuje slika 7. 2. Provjera vrsta mjerenja objave i pretplate 3. Ako se mjerne jedinice objave i pretplate razlikuju, postoji li formula pretvorbe iz jedne u drugu 4. Ako postoji formula pretvorbe, pretvara se vrijednost iz objave u novu mjernu jedinicu 5. Usporedba vrijednosti iz objave s granicama intervala definiranih u pretplati 6. Objava odgovara pretplati, pronađen je pretplatnik Slika 7. Presijecanje dva poligona 29
Izvorni kod za traženje pretplatnika prvom grupom usporedbi (geometrije i vrste mjerenja), koji vraća sve potencijalne pretplatnike iz baze podataka: public List<SubscriptionResource> getsubscribersbysensorreading(sensorreadingresource sensorreadingresource) throws Exception { WKTWriter wktwriter = new WKTWriter(); StringBuilder filterbuilder = new StringBuilder(); filterbuilder.append("intersects ("); filterbuilder.append(geometrija_pretplate); filterbuilder.append(","); filterbuilder.append(wktwriter.write(convertgeojsontype(sensorreadingreso urce.getlokacija()))); filterbuilder.append(")"); filterbuilder.append(" AND "); filterbuilder.append(vrsta_ocitanja); filterbuilder.append(" = '" + sensorreadingresource.getvrstaocitanja() + "'"); String filterquery = filterbuilder.tostring(); Filter filter = CQL.toFilter(filterQuery); SimpleFeatureCollection features = database.getsimplefeaturesource().getfeatures(filter); List<SubscriptionResource> subscribers = new ArrayList<SubscriptionResource>(); SimpleFeatureIterator simplefeatureiterator = features.features(); try { while( simplefeatureiterator.hasnext() ){ SimpleFeature feature = simplefeatureiterator.next(); SubscriptionResource subscriptionresource = tosubsciptionresource(feature); subscribers.add(subscriptionresource); } } finally { simplefeatureiterator.close(); } } return subscribers; Izvorni kod za traženje pravih pretplatnika za tu objavu među potencijalnim pretplatnicima, drugom grupom usporedbi (postojanje konverzije ako se razlikuju mjerne jedinice i provjera intervala vrijednosti): List<SubscriptionResource> subscribers; for(sensorreadingresource sensorreadingforpublish : forpublish) { 30
subscribers = subscriptionrepository.getsubscribersbysensorreading(sensorreadingforpubl ish); for(subscriptionresource subscriptionresource : subscribers) { SensorReadingResource sensorreading = prepareforsubscriber(sensorreadingforpublish, subscriptionresource); if(null == sensorreading) { //NEMA KONVERZIJE continue; } //PROVJERA INTERVALA if(! (subscriptionresource.getintervaldonji() <= sensorreading.getvrijednost() && sensorreading.getvrijednost() <= subscriptionresource.getintervalgornji())) { // NIJE U INTERVALU continue; } //PRETPLATNIK ODGOVARA OBJAVI String subscriberid = subscriptionresource.getidentifikatorpretplatnika(); //SLANJE PRETPLATNIKU String sensorreadinggeojson = mapper.writevalueasstring(sensorreading); GCMServer.sendMessageToClient(subscriberID, sensorreadinggeojson); Korisnike se identificira preko pretplata tako da se jedan korisnik može pretplatiti na neograničen broj pretplata, a također može definirati više njih istovremeno. Pretplata je zaseban entitet u sustavu. Kada korisnik definira više preplata odjednom, svaka pretplata će se pohraniti kao da ih je definirao jednu po jednu, dakle one neće biti povezane. Logika iza tog principa je da se spriječe pretplate koje ne bi zadovoljavale uvjete za nijednu objavu. Kada uzmemo u obzir navedeno i da je pretplata u GeoJSON obliku, tada možemo prikazati primjer jedne pretplate: { "type": "FeatureCollection", "features": [ { "type": "Feature", "geometry": { "type": "Polygon", "coordinates": [ [ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0] ] ] }, "properties": { "identifikator_pretplatnika": "jgu24hg23wij29g24", "vrsta_ocitanja": "temperatura", 31
} ] } "jedinica_ocitanja": "C", "interval_donji": 20, "interval_gornji": 30 } Identifikator pretplatnika predstavlja jedinstveni identifikator usluge GCM (Google Cloud Messaging for Android) pomoću kojeg Googleov poslužitelj šalje objave aplikaciji. Svakom pretplatniku će objava biti poslana odmah nakon što se utvrdi da njegova pretplata odgovara pristigloj objavi. Jednokratni upiti, iako vrlo slični pretplatama, razlikuju se po mogućnosti definiranja vremenskog intervala u kojem korisnika zanimaju objave koje se nalaze spremljene u bazi. Jednokratni upit se koristi kada se želi dohvatiti povijest spremljenih objava te je jednokratnim upitom nemoguće dohvatiti objave iz budućnosti zato što se on ne pospremi u bazu podataka. Odgovor poslužitelja na jednokratni upit šalje se preko REST sučelja, dakle kada stigne zahtjev jednokratnog upita, u odgovoru s poslužitelja će se nalaziti sve objave koje odgovaraju tom upitu. Primjer jednokratnog upita: { "type": "FeatureCollection", "features": [ { "type": "Feature", "geometry": { "type": "Polygon", "coordinates": [ [ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0] ] ] }, "properties": { "vrsta_ocitanja": "temperatura", "jedinica_ocitanja": "C", "interval_vrijednosti_donji": 20, "interval_vrijednosti_gornji": 30, "interval_vremena_donji": "2013-01-21T12:30:21", "interval_vremena_gornji": "2016-01-21T12:30:21" } } ] } Proces pronalaska odgovarajućih podataka kod jednokratnih upita je drugačiji nego što je to kod objave. Kada se dogodi objava tada se prema njoj traže pretplate, a 32
kod jednokratnih upita je postupak obrnut, odnosno jednokratnim upitom se traže odgovarajuće objave kako je i prikazano na slici 8. Slika 8. Smjer traženja odgovarajućih pretplata i objava Kako bi lakše opisali što je objava, zamislimo jedan digitalni termometar s mogućnošću spajanja na Internet koji se nalazi negdje u Zagrebu i mjeri temperaturu u Celzijusima. Taj termometar je zapravo senzor koji je spojen na Internet preko najbliže bežične pristupne točke, a podešen je tako da svaku očitanu promjenu koja se razlikuje od prethodne za neki manji Δt pošalje na REST sučelje. Senzor je tvornički napravljen da strukturira podatke u formatu GeoJSON koji sadrži svoju trenutnu lokaciju (geometriju) te dodatne parametre kao što je očitanja vrijednost, vrijeme, svoj identifikator, vrstu veličine koju mjeri i mjernu jedinicu za očitanu vrijednost. Taj skup povezanih strukturiranih podataka kada pristigne putem mreže na ostvareni repozitorij postaje jedna objava. Iz svega do sada navedeno ovdje se nalazi primjer jedne objave: { "type": "FeatureCollection", "features": [ { "type": "Feature", "geometry": { "type": "Polygon", "coordinates": [ [ [100.5, 0.1], [100.8, 0.1], [100.8, 0.2], [100.5, 0.2], [100.5, 0.1] ] ] }, "properties": { "vrijeme_ocitanja": "2015-04-29T20:24:25", "identifikator_senzora": "senzor123456", "tip_senzora": "termometar", "vrsta_ocitanja": "temperatura", "vrijednost": 27, 33
} ] } } "jedinica_ocitanja": "C" Upotrijebili smo tip FeatureCollection jer podržava slanje liste takvih očitanja, odnosno mogućnost privremenog spremanja na senzoru te slanja više objava odjednom. Omogućuje senzoru rad kada je izvan mreže, odnosno nije spojen na Internet, te kada se spoji da pošalje sve što je do tada izmjerio, u jednom slanju podataka na sučelje REST. Za pretvaranje iz jedne mjerne jedinice u drugu pomoću formule korištena je knjižnica exp4j koja omogućava evaluaciju matematičkih izraza i funkcija u stvarnoj domeni. Primjer definiranja jedne konverzije slanjem u JSON formatu na REST URI: { } "vrstaocitanja" : "temperatura", "izmjernejedinice": "C", "umjernujedinicu": "K", "formula" :"C - 273.15" Kada poslužitelj uspješno odredi pretplatnika tada mu je potrebno poslati objavu na koju je pretplaćen. Iskoristili smo uslugu GCM za tu potrebu, a implementirana klasa izgleda ovako: public class GCMServer { private static final String APIKey = "API-KLJUC"; private static Sender sender = new Sender(APIKey); public static void sendmessagetoclient(string registrationid, String jsonbody) throws Exception { Message message = new Message.Builder().addData("data", jsonbody).build(); } sender.send(message, registrationid, 0); } Klasa je poprilično jednostavna jer su dovoljne samo klase Sender i Message iz paketa com.google.android.gcm.server i potrebno je pozvati metodu send te kao 34
parametre predati poruku koju šaljemo i identifikacijski ključ klijenta kojem šaljemo, a dodatni treći parametar je broj ponovnih pokušaja u slučaju neuspjeha. Slijedni dijagrami prikazan na slici 9 i 10 prikazuju aktiviranje jedne pretplate i objavljianje jedne objave u usutavu. Slika9. UML sekvencijski dijagram za pretplatu nakon koje slijedi objava Slika 10. UML sekvencijski dijagram za jednokratni upit 35
2.5 Aplikacija za operacijski sustav Android Operacijski sustav Android je otvorenog koda i napravljen je za mobilne uređaje te je danas najrašireniji operacijski sustav za mobilne. Dolazi u raznim verzijama, a osnovni tip jezgre je Linux jezgra. Posljednja stabilna verzija je 5.1.x kodnog imena Lollipop. Iako su sama jezgra, API i knjižnice ra razvoj napisane u C programskom jeziku, aplikacije su zapravo napisane u Javi i pokrenute unutar modificiranog Javinog virtualnog stroja imenom Dalvik-ov virtualni stroj. Kod novijih verzija Android uređaja sa operacijskim sustavom vezije 5.0 koristi se napredniji virutalni stroj ART (Android Runtime). Aplikacije za Android su pisane u Javi pa je tako izvedena i zadana aplikacija. Aplikacije za Android se pokreću unutar svog vlastitog okruženja (sandbox) koje je izolirano od ostatka sustava tako da nemaju pristup dijelovima operacijskog sustava bez dodatnih odobrenja, koje je eksplicitno pridodao korisnik prilikom instalacije aplikacije. Također Android je sustav koji podržava višekorisničko okruženje pa se tako svaka aplikacija ponaša kao jedan korisnik s vlastitim identifikacijskim brojem koji je nepoznat aplikaciji, a na temelju tog ID broja sustav pridjeljuje i prati dozvole odobrene toj aplikaciji. Jedna od mogućnosti Android uređaja je praćenje trenutne lokacije, a mnogo uređaja ima ugrađene senzore za mjerenje raznih vrsta mjerenja. Kada spojimo te dvije opcije, uz korisnikovo dopuštenje, možemo mobilni uređaj pretvoriti u mobilni senzor koji objavljuje podatke u ostvareni repozitorij. Za potrebe pokazne aplikacije nećemo implementirali provjeru mogućnosti pretvorbe u senzor, ali možemo tražiti korisnikovo dopuštenje za prepoznavanje lokacije kako bi mu olakšali pretplaćivanje na repozitorij za njegovo interesno područje. 2.5.1 Osnovne logičke cjeline Android aplikacija Logičke cjeline se mogu shvatiti kao komponente aplikacije, a postoji par vrsta osnovnih od koje se sastoji svaka aplikacija. Svaka komponenta određuje svoj životni ciklus unutar aplikacije. Aktivnost je jedna od tih osnovnih komponenti. Kao što samo ime kaže, pomoću nje se komunicira s korisnikom, odnosno prikazuje se sučelje i obrađuje interakcija korisnika i sučelja. Aplikacija može imati više aktivnosti koje su najčešće različite po svojim mogućnostima i zadaćama. Interakcija se svodi 36
na promjenu aktivnosti odnosno stvaranje nove aktivnosti pri čemu se svaka posprema na FIFO stog. Implementirana je s nekoliko metoda koje možemo interpretirati kao događaje koji se dogode prije neke važnije promjene u ciklusu: oncreate stvaranje nove aktivnosti onstart - prije nego što se sučelje osvježi i prikaže pozvat će se ova metoda onresume pozvana je metoda kada je aktivnost stvarno postala vidljiva onpause prilikom zaustavljanja aktivnosti onstop nakon što je aktivnost zaustavljena Aktivnosti, kao i procesi, podliježu prioritetima, upravitelju prozora i odlasku u pozadinsko stanje. Prilikom pauziranja aktivnosti ona će zadrži svoje stanje u radnoj memoriji tako da je upravitelj prozorima može uvijek prebaciti u aktibno stanje. Kada pozivom metode onstop aktivnost prijeđe u pozadinu, tada više nije vezana za upravitelja prozora i postoji mogućnost da će biti izbrisana, iako čuva sve informacije. Slika 11. prikazuje životni ciklus aktivnosti u operacijskom sustavu. 37
Slika 11. Životni ciklus i stanja aktivnosti u Android-u Fragmenti služe prikazivanju unutar same aktivnosti odnosno oni su jednostavniji dijelovi aktivnosti čijim sadržajem aktivnost upravlja te tim promjenama aktivno mijenja sadržaj prikazan na ekranu. Usluge služe za izvršavanje operacija na zasebnim dretvama u pozadini aplikacije. Dakle one se poistovjećuju sa pozadinskim uslugama kojima se aplikacija služi za obavljanje poslova koji su paralelni s poslovima obrade korisničkog sučelja. Samim time one nemaju ulogu u prikazu korisničkog sučelja već su zadužene za poslove poput snimanja i čitanja s diska ili spajanja te dohvaćanja podataka iz mreže. Bitno je naglasiti da nam usluge služe i za obavljanje radnji kada aplikacija nije u fokusu odnosno kada nije glavna na korisničkom sučelju. Postoje u dvije vrste, kao pokrenuta usluga i kao povezana 38
usluga. Pokrenuta usluga je instancirana iz neke druge komponente te se ona izvodi u pozadini dok god nije prekinuta. Pokreće se metodom startservice. Povezana usluga kreira se stvaranjem veze s nekom drugom komponentom pri pozivu metode bindservice, a ona tada omogućava komunikaciju te dvije komponente. Izvršava se dok postoji komponenta s kojom je povezana, jednom ili više njih, ali barem jednom. Pružatelji sadržaja zaduženi su za podatke koji se dijele među aplikacijama, a to su podaci iz baze podataka, datotečnog sustava ili mreže. U Androidu postoji par unaprijed definiranih kao što su npr. pristup kontaktima ili glazbi. 2.5.2 Komunikacija između aplikacije i poslužitelja Ostvarena pokazna aplikacija i poslužitelj komuniciraju na dva načina. Kada aplikacija inicira zahtjeve na poslužitelj tada se komunikacija odvija preko HTTP-a na sučelje REST klasičnim slanjem zahtjeva na poslužitelj, a poslužitelj odgovara istim putem natrag. Ovakva komunikacija je moguća jer poslužitelj ima javnu IP adresu koju aplikacija poznaje. Međutim kada poslužitelj inicira zahtjeve na aplikaciju tada on ne zna gdje se aplikacija nalazi jer ona nema javnu IP adresu na koju bi poslužitelj poslao svoj zahtjev. Ovaj problem riješen je korištenjem Googleove usluge GCM. GCM omogućava dvosmjernu komunikaciju između Android aplikacije i poslužitelja koju su spojeni preko Interneta. Sastoji se od poslužiteljskog dijela i klijentskog dijela, a potrebno je implementirati zasebno na svakoj strani komunikacijskog kanala. Poslužitelj se registrira na Google-ovoj usluzi GCM te dobiva unikatni identifikator. Zatim se aplikacija može registrirati na poslužitelja tako da poznaje njegov GCM identifikator. Prilikom registracije aplikacija će od poslužitelja dobiti svoj jedinstveni ID, koji će poslužiti poslužitelju da točno zna kojem uređaju se šalje poruka. Cijela komunikacija se odvija preko Google-ovih poslužitelja, odnosno posrednika, a veličina poruke ograničena je na 4kb. Aplikacija omogućava korisniku definiranje pretplate na karti Google Maps, a svaki korisnik prije nego što se pretplati na repozitorij može odraditi par stvari: dohvatiti listu svih vrsta mjerenja i pripadajućih mjernih jedinica dohvatiti listu svih postojećih formula pretvorbi, odnosno provjera postoji li formula pretvorbe za mjernu jedinicu u kojoj on želi definirati pretplatu 39
u slučaju da pretvorba ne postoji, odabirom "Add conversion" tipke na ekranu može dodavati nove formule pretvorbe, a to želi napraviti da bi bio siguran da će primati pretplate u drugim mjernim jedinicama. 2.5.3 Korištenje aplikacije "Add subscription" tipkom na ekranu dodaje se nova pretplata. Kod postavljanja postavki pretplate korisnik definira vrstu mjerenja, mjernu jedinicu, gornji i donji interval vrijednosti i vrstu geometrijskog oblika kako je prethodno definirana pretplata. Slika 12. prikazuje izgled korisničkog sučelja aplikacije. Slika 12. Izgled Android aplikacije Slika 13. Primitak notifikacije o objavi U aplikaciji je moguće izabrati između nekoliko ponuđenih različitih geometrija, a to su točka, linija i poligon. Ograničen je izbor zato što aplikacija služi u demonstrativne svrhe i da se izbjegne komplikacija implementacije sučelja. Nakon što korisnik odabere tip geometrije, klikom na prikazanu kartu definira geometriju u stvarnom prostoru tako da odabire točke. Zatim potvrdom na gumb "OK" aplikacija će pretplatu poslati na poslužiteljevo sučelje REST. Očekivani rezultat je naknadni primitak objava koje odgovaraju definiranoj pretplati u obliku notifikacije koja pristiže putem GCM usluge, kao što se vidi na slici 13. 40
3. Analiza performansi sustava Objave su ključni dio ostvarenog repozitorija te one nose informacije koje omogućavaju uspješan rad repozitorija. Postoji velika kvantitativna razlika između objava i pretplata. Naime pretplata će u repozitoriju uvijek biti puno manje nego što će biti zabilježenih objava i dolazimo do zanimljive primjedbe o strukturi modela objavi-pretplati u ostvarenom sustavu, a to je da će gotovo uvijek biti puno više objavljivača, u ovom slučaju senzora, nego što će biti pretplatnika. Kako vrijeme odmiče repozitorij će sve više težiti u opisano stanje. Za kontinuirane upite to nije problem jer se za svaku pristiglu objavu uspoređuje relativno manji skup pretplatnika. Možemo reći da će to uvijek biti puno manji skup od skupa objava. Potencijalni problem se javlja kod jednokratnih upita s velikim vremenskim intervalom od interesa. Postavlja se pitanje, kako će se sustav ponašati kada stigne jednokratni upit s geometrijom koja pokriva veliko područje s dodatnim parametrom vremenskog intervala od jedne godine, a pretpostavka je da će veliki broj objava zadovoljiti taj upit. U skladu s tim postoje dvije vrste mjerenja koje je potrebno napraviti. Prva vrsta mjerenja su performanse jednokratnih upita, a druga su performanse kontinuiranih upita odnosno pretplata jer se te dvije vrste razlikuju u tome kako korisnik prima odgovor. Obje imaju sličnosti u tome što možemo mjeriti postotak pogodaka odnosno koliko je objava ili pretplata zadovoljilo tražene kriterije. Pretpostavka je opet što je veći broj pogođenih to će biti dulje vrijeme obrade bilo jednokratnog upita ili objave. Kod jednokratnih upita odgovor se vraća na IP adresu s koje je i došao te je to proces klasičnog HTTP upita i odgovora. Kada stigne upit započnemo mjerenje, a kada repozitorij pronađe sve odgovarajuće objave za taj upit i prije nego što odgovori korisniku natrag, zaustavlja se mjerenje. Dakle upit je sinkron jer će korisnik za to vrijeme čekati od poslužitelja na odgovor. Kod kontinuiranih pretplata mjerit ćemo koliko je potrebno sustavu da za određeni broj objava, unutar nekog vremenskog intervala, pronađe sve odgovarajuće pretplate za pojedinu objavu. Mjerenje se započinje kada pristigne objava u sustav, a zaustavlja kada su pronađene sve pretplate čije kriterije objava zadovoljava. Upit je asinkron jer korisnik ne mora čekati na odgovor s poslužitelja jer će mu podaci 41
biti dostavljeni preko usluge GCM kada poslužitelj bude ima0 podatke za njega. Zato ova vrsta mjerenja pokazuje isključivo koliko je potrebno vremena poslužitelju da obradi objavu. Pomoću usluge Google Maps lako se može saznati geografsku lokaciju Grada Zagreba što je prikazano na slici 14.. Repozitorij koristi koordinate koje su zadane u decimalnom prikazu pa će nam podaci s ove usluge biti od koristi jer daju informaciju lokacije u decimalnom prikazu, a za Zagreb su to [45.804687, 15.981131] redom zemljopisna širina pa dužina odnosno gledano za ostvareni sustav kada definiramo geometriju u formatu WKT, prvo je prikazana y koordinata pa x koordinata, dakle ta točka u formatu WKT bi izgledala ovako: POINT (15.981131, 45.804687) Slika 14. Koordinate Grada Zagreba u aplikaciji Google Maps [21] 3.1 Mjerenje Alat koji nam je poslužio za mjerenje je Apache JMeter koji je napisan u Javi i otvorenog je koda, a dizajniran je za testiranje funkcionalnosti i performansi sustava pod opterećenjem. Simulira preopterećenost poslužitelja i rad pod velikim brojem zahtjeva stvaranjem više dretvi koje istovremeno šalju zahtjeve na poslužitelj te tako analizira rad sustava kakav bi on stvarno bio da je korišten u praksi. Ovaj alat je dobar i po tome što može slati modificirane zahtjeve HTTP na sučelja REST, a mi 42
ćemo ga iskoristiti upravo za to. Za potrebe mjerenja rezultata napravljen je i generator pretplata i objava. Mjerni podaci će biti generirani u formatu csv jer Apache JMeter ima mogućnost slanja različitih zahtjeva učitavanjem parametara iz datoteka strukturiranih kao csv, a zatim se definira uzorak na temelju kojeg JMeter iščitava podatke iz datoteka i popunjava varijable u uzorku da dobije konačni izgled zahtjeva. Generator stvara objave i pretplate s geometrijom čije koordinatne točke variraju oko točke centra Grada Zagreba. Koordinate točaka geometrija stvaraju se dodavanjem i oduzimanjem slučajno generiranih brojeva između 0 i 1 na x i y koordinate točke (15.981131, 45.804687). Također se stvaraju tri vrste mjerenja: temperatura, buka i CO2 od kojih svaka ima svoje mjerne jedinice, definirane formule pretvorbe i početne točke iz kojih se pomoću slučajno generiranih brojeva dobivaju vrijednosti objava i intervali pretplata. Npr. početna točka za vrstu mjerenja temperatura uz mjernu jedinicu K (Kelvin) je 300 stupnjeva, a za mjernu jedinicu C (Celzij) je 25 stupnjeva te postoje formule pretvorbe u bazi podataka. Ovako izgleda uzorak objave za JMeter tj. zahtjev HTTP POST koji će biti poslan na REST sučelje i predstavljat će objavu: { type : FeatureCollection, features : [ { type : Feature, geometry : { type : ${tipgeometrije}, coordinates : ${koordinate} }, properties : { vrijeme_ocitanja : ${vrijemeocitanja}, identifikator_senzora : ${identifikatorsenzora}, tip_senzora : ${tipsenzora}, vrsta_ocitanja : ${vrstaocitanja}, vrijednost : ${vrijednost}, jedinica_ocitanja : ${jedinicaocitanja} } } ] } JMeter predstavlja i korisnike koji se pretplaćuju na repozitorij, a isto tako predstavlja i senzore koji objavljuju u repozitorij. Kako bi testiranje stresa bilo što vjernije i kako bi se izbjeglo čekanje u mreži podešen je JMeter na istom računalu gdje je pokrenut i poslužitelj i baza podataka pa će efektivno oni biti u lokalnoj mreži gdje možemo 43
zanemariti kašnjenje. Slika 15. prikazuje podešenu JMeter aplikaciju za testiranje repozitorija. Generator kreira par vrsta objava i pretplata koje se razlikuju po vrsti geometrije i dodatnim parametrima. Vrste geometrije koje kreira su točka (Point), linija (LineString) i poligon (Polygon), a vrste mjerenja su temperatura, buka i CO2 u zraku. On stvara broj objava i pretplata koji su zadani pri njegovu pokretanju. Metoda za generiranje jedne točke koja se zatim poziva kod stvaranja koordinata za sve zadane vrste geometrija: public String generatepoint() { double ZagrebX = 15.981131; double ZagrebY = 45.804687; double xcoord = ZagrebX + randdouble(); double ycoord = ZagrebY + randdouble(); String tocka = [ + Double.toString(xCoord) +, + Double.toString(yCoord) + ] ; } return tocka; Jedna linija u datoteci će predstavljati jednu pretplatu ili jednu objavu, a linija koja predstavlja objavu izgleda ovako: Point;[15.913196758984187,45.891931741227936];2014-01- 04T10:10:10;1197448;termometar;temperatura;273.56651252378333;K U bazi su prethodno unesene sve moguće pretvorbene formule mjernih jedinica za dane vrste mjerenja, a ovdje je primjer jedne pretvorbe mjernih jedinica koju POST metodom pošaljemo na REST sučelje: { } vrstaocitanja : temperatura, izmjernejedinice : C, umjernujedinicu : K, formula : C + 273 44
Slika 15. GUI sučelje JMeter aplikacije za testiranje repozitorija 3.2 Plan mjerenja Mjerenje performansi kod jednokratnih upita zahtjeva postojeće objave u bazi podataka. Zato smo započeli s mjerenjem karakteristika pretplata i objava jer je baza na početku bila prazna, a mjerenjem smo postepeno dodavali pretplate i objave u sustav. Objave i pretplate sastoje se od slučajno generiranih podataka dobivenih pomoću spomenutog generatora. Brzinu pretplaćivanja na repozitorij mjerili smoi za veliki broj pretplata u kratkom intervalu. Kada je sustav u početku svoga rada imao manji broj pretplatnika, tada su pretplate stizale malom brzinom u pa smo pretpostavili da bi poslužitelj trebao nove pretplate odraditi iznimno brzo. Za mjerenje performansi sustava u slučaju objave morali smo imati postojeće pretplatnike pa smo to mjerenje provodili nakon što je u bazu unešen određeni broj pretplatnika. Kod svake objave mjerili smo vrijeme potrebno da repozitorij pronađe sve odgovarajuće pretplatnike kao i broj koliko je pretplata zadovoljila ta objava. 45
Kasnije smo usporedil kako je utjecala brzina objave na broj pretplata koji je objava zadovoljila. Također dodatno smo promatratli utjecaj vrste geometrije iz objave na performanse repozitorija. Iz svega navedeno, za svaku objavu zapisivali smo vrstu geometrije objave, broj odgovarajućih pretplata i potrebno vrijeme za izvršavanje. Parametri prvog mjerenja su broj pretplata u sustavu i broj objava koji će pristizati u sustav sa senzora. Broj objava je bio pet puta veći od broja pretplata, kako je prikazano u tablici 11., jer smo tako povećavali šansu za večim brojem pogodaka odnosno omjera objava i odgovarajućih pretplata. Tablica 11. Broj pretplata i objava za prvo testiranje Pretplate 50 100 500 1000 5000 Objave 250 500 2500 5000 25000 Drugim mjerenjem provjerili smo kako se ponaša sustav uz konstantan broj pretplata i rastući broj objava, a brojevi objava i pretplata su prikazani tablicom 12.. Pretpostavili smo da će prosječno trajanje jedne objave biti konstantno jer će uvijek pretraživati po istom skupu pretplatnika. Tablica 12. Drugo mjerenje - konstantan broj pretplata, a rastući broj objava Pretplate 1000 1000 1000 1000 1000 Objave 500 1000 1500 2000 2500 U trećoj fazi mjerenja ispitali smo kako broj pretplata u sustavu ovisi o trajanju jedne objave. Uz poznavanje algoritma za jednu objavu, pretpostavili smo da će uz linearan porast pretplata biti i linearno povećanje u trajanju jedne objave kod konstantnog broja objava. Broj pretplata za to mjerenje prikazan je tablicom 13. Tablica 13. Treće mjerenje - Konstantan broj objava uz rastući broj pretplatnika Objave 100 100 100 100 100 Pretplate 500 1000 1500 2000 2500 46
Performanse jednokratnih upita ispitivali smo promjenom intervala vrijednosti i vremenskog intervala. Ostali parametri nisu se mijenjali, već smo mjerenje provodili samo za objave čija je vrsta mjerenja temperatura, a jedinica očitanja stupanj Celzijev. Ti parametri su bili kontinuirani jer ne utječu toliko na performanse. Ono što najviše utječe je broj objava koji će zadovoljiti taj upit, a povećanje broja odgovarajućih objava po upitu ostvarili smo najviše povećanjem vremenskog intervala. Mjerili smo za vrstu mjerenja temperatura, kod koje objave pohranjene u bazi nemaju vrijednosti izvan intervala 0 50 stupnjeva Celzijevih pa je kod upita bio postavljen konstantan interval na tu vrijednost, kako je prikazano u tablici 14. Tablica 14. Postavke za jednokratne upite Interval vrijednosti / C 0-50 0-50 0-50 0-50 0-50 Interval vremenskog razdoblja / Vrijeme sat dan mjesec godina 5 godina Geoprostorni objekt upita bio je poligon koji pokriva područje u koje pripada većina generiranih pretplata, a zapisan u GeoJSON formatu izgleda ovako: { "type": "Polygon", "coordinates":[ [[15.7609,45.7337],[15.7574,45.8855],[16.1914,45.8773],[16.1948,45.7376], [15.7609,45.7337]] ] } Slikovni prikaz geometrijskog objekta korištenog u jednokratnim upitima nalazi se na slici16. 47
Slika 16. Poligon za testiranje jednokratnih upita koji sadrži sve objave [22] 3.3 Rezultati Većina grafičkih prikaza u rezultatima pokazat će tri vrijednosti: maksimalno, minimalno i prosječno trajanje obrade objave na poslužitelju. Prosjek je najzanimljiviji podatak za analizu rezultata, međutim za analizu i optimizaciju sustava potrebno je poznavati koliko je objava maksimalno mogla čekati na obradu odnosno koliko je maksimalno mogla trajati. Minimalno trajanje prikazano je radi konzistentnosti grafova, a iz svakog minimalnog trajanja objave se može zaključiti da su to objave koje su, za vrijeme mjerenja, prve pristigle u sustav te su najmanje čekale na obradu i bile najbrže obrađene jer sustav još nije bio pod opterećenjem. U daljnjoj analizi mjerenja fokusirat ćemo se na prosječno trajanje mjerenja jer ono daje stvarno sliku kako sustav radi pod opterećenjem, a također jer su sve pretplate i objave generirane nasumičnim geometrijskim oblicima što može značiti da će neke objave zadovoljavati jako veliki broj pretplata, dok će neke objave zadovoljavati jako malo ili nijednu pretplatu. Takav oblik mjerenja je najbliži mjerenju ponašanja nekog stvarnog sustava. Rezultat mjerenja za trajanje pretplaćivanja u sustav prikazan je na slici 17. 48