Predlog arhitekture distribuirane mobilne aplikacije za procenu rizika

Keywords: Android, JSON, NoSQL Android, JSON, NoSQL

U savremenom pristupu obradi podataka postoji težnja da se događaji obrađuju na mestu njihovog nastanka. Jedna od situacija koja zahteva takav pristup je procena rizika prilikom ostvarenja nekog hazarda. Ona podrazumeva prikupljanje i obradu podataka na samom mestu ostvarenja. Napredak tehnologije i trenutno stanje u računarstvu i komunikacijama su omogućili razvijanje takve aplikacije. U radu su analizirane moguće arhitekture zasnovane na Android mobilnoj platformi, Json formatu za razmenu podataka i NoSql rešenjima za skladištenje prikupljenih podataka. 

UVOD

Svakodnevne operativne aktivnosti u bavljenju rizikcima od hazardnih događaja sa katastrofalnim posledicama, suočavaju se sa problemon podrške u odlučivanju na terenu. Odlučivanje se zasniva na nizu parametara (hazardi, ranjivost, izloženost, izdržljivost, ...) koji se izračunavaju upotrebom indikatora. Parametri su u slučaju odlučivanja ili poznati ili zavise od indikatora koje treba lokalno prikupiti. 
U prethodnom periodu proces prikupljanja podataka i podrška odlučivanju o proceni rizika od hazardnih događaja sa katastrofalnim posledicama zahtevao je odlazak na lokaciju događaja. Na licu mesta bi se evidentirali podaci i opis njihovog prikupljanja, a zatim bi se podaci unosili u bazu podataka za procenu rizika. Takvim načinom obrade otvarale su se mogućnost za nepreciznosti i greške zbog različitih razloga: nepreciznih podataka, neodgovarajuće interpretacije ili nestandardizovanog pretstavljanja prikupljenih podataka. Osim toga postojalo je i vremensko kašnjenje od trenutka obrade na mestu događaja do trenutka kopmpletne obrade u sistemu procene rizika. 
U tom smislu može se reći da se od samog početka primene automatizovane obrade podataka težilo da se događaji obrađuju na mestu njihovog nastajanja. Međutim, problemi obezbeđivanja komunikacija, gabariti i procesna moć računarske opreme su uglavnom nalagale da se vrše tzv. pozadinske obrade podataka koji su prikupljani s terena. Danas su, međutim, u uslovima brzog napredaovanja u oblasti komunikacija, interneta i mo-bilnih uređaja svih vrsta, stvorene mogućnosti razvoja mobilnih aplikacija za najrazličitije primene. Jednostavno se kao standard nameće primena so verskih rešenja koja koriste mobilne uređaje s internet vezama. Postavlja se pitanje kako koncipirati arhitekturu aplikacije za mobilne uređaje. U radu je analizirana moguća arhitektura distribuirane mobilne aplikacije za prikupljanje podataka za procenu rizika. 

ARHITEKTURA Osnovni Aspekti

Generalno, kad su u pitanju aplikacije koje koriste mobilne uređaje za prikupljanje podataka, moguća su dva pristupa. Razvoj samostalne aplikacije ili korišćenje standardnog web pretraživača na strani mobilnog uređaja. U nekim slučajevima potrebno je obezbediti rad ne samo u on-line režimu već, vodeći računa o tome da mobilni uređaj nije u mogućnosti da neprestano obezbedi mrežnu konekciju, potrebno je obezbediti i mogućnost rada u oline režimu. Kada postoje takvi funkcionalni zahtevi, jedino rešenje je samostalna mobilna aplikacija jer se u slučaju korišćenja web pretraživača teško može obezbediti potpuna o -line funkcionalnost. Pri tome treba voditi računa da je razvoj samostalne mobilne aplikacije skuplje rešenje, u smislu potrebnih napora, veština i vremena za njen razvoj. Zbog toga se razvoj samostalne aplikacije predlaže samo u slučaju eksplicitnih zahteva za obezbeđivanjem, uglavnom ograničene, funkcionalnosti i uslovima kada mobilni uređaj ostaje bez veze sa ostatkom sistema. 
U pogledu arhitekture, mobilne aplikacije imaju mnoge zajedničke karakteristike kao i klijent-server ili web aplikacije sa višeslojnom arhitekturom. Međutim, postoje i segmenti u kojima se arhitektura i projektovanje mobilnih aplikacija razlikuju od klasičnih klijent-server ili višeslojnih web aplikacija. Zbog toga je tim aspektima arhitekture mobilnih aplikacija potrebno posvetiti pažnju na samomom početku procesa razvoja aplikacije, da bi se izbegle posledice loše de nisane arhitekture. 
Uopšteno govoreći, aplikacije na mobilnim platformama potrebno je integrisati u informacionu strukturu celog sistema, ali zbog ograničenih resursa mobilnih uređaja interakcija s bazom podataka postaje jedan od važnih problema. Zbog toga (ograničenih resursa: procesor, memorija, baterija, veličina ekrana) je potrebno posvetiti pažnju formatima za e kasnu razmenu, parsiranje i interpretaciju podataka, i odabrati formate koji su e kasni u pogledu potrošnje resursa mobilnog uređaja i komunikacije s web servisima i bazom podataka. 
Važan segment pri projektovanju mobilnih aplikacija je obezbeđivanje njihove o -line funkcionalnosti. Iako se o -line funkcionalnost smatra redukovanom, ipak se otvaraju mogućnost pristupa svim komponetama mobilnog uređaja, kao što su kamera ili GPS, a za smeštanje veće količine podataka se može koristi fajl sistem samog uređaja, takođe se javljaju i poroblemi o kojima treba voditi računa. Mora se obezbediti sinhronizacija urađaja s bazom podataka kada se ponovo uspostavi veza s ostatkom sistema. Pri tome se moraju obraditi moguće koniktne situacije da nebi došlo do gubljenja podataka ili situacije kada bi podaci postali nepouzdani. 

Moguća rešenja

Trenutno aktualne arhitekture koje mogu zadovoljiti spomenute zahteve u adekvatnoj meri su: ◆ Microso , Windows Distributed Network Architecture (Windows DNA)/.NET, ◆ Object Management Group, Common Object Request Broker Architecture (CORBA), ◆ Sun, Java 2 Enterprise Edition (JavaEE) Architecture. Tradicionalni nedostatak Microso zasnovanog rešenja je nemogućnost izvršavanja na drugim platformama, pre svega danas veoma aktuelnoj Android platformi. Takođe evidentan i teško premostiv problem se mala ponuda prenosnih uređaja koji imaju podršku za ovu platformu. 
CORBA bazirano rešenje je prekomplikovano za potrebnu dinamiku adaptivnog razvoja aplikacije za podršku u odlučivanu oblasti koja je zavisna od primene savremenih, aktuelnih i često prototipskih komponenti i senzorskih sistema. 
Kao jedina prihvatljivo rešenje se nameće JAVAEE. Sun-ova speci kacija i standard donosi dinamičnu i široko podržano rešenje koje obuhvata tehnologije kao što su: EnterpriseJavaBeans (EJB), Java Servlets API and Java Server Pagers (JSP), i mnoge druge. JAVAEE je izvršiva na različitim platformama i dominantna je na danas ak-tuelnoj i ekonomski dostupnoj Android zasnovanoj platformi. 
Ako JavaEE takođe posmatramo iz aspekta razvoja mobilne aplikacije čija arhitektura pretstavlja sistem elemenata visokog nivoa apstrakcije i potrebne interakcije između elemenata, i potrebnih ograničenja, sa potrebom da se zadovolji tipična mobilna višeslojna arhitektura prikazana na Slici 1., jedno veoma kvalitetno rešenje sa potrebnim tehnologijama za svaku pojedinačnu komponentu. Poslednji aspekt koji pominjemo je taj da je transfer podataka značajan aspekt arhitekture mobilne aplikacije, pogotovo u svetlu koraka koje podatak treba da obavi. Pri tome mora biti zadovoljena potreba za bezbednošću i dostupnosti podataka i jednostavnosti implementacije rešenja. 

API


Server


Mobilni klijent


FORMAT PORUKA

Kada smo izabrali JAVAEE kao ciljanu platformi, sledeći korak nam je izbor formata za razmenu podataka. Kada u Java aplikaciji imamo potrebu za razmenom podataka imamo dve aktuelne mogućnosti, XML i JSON format. Oba formata imaju svoju prostorno zasnovanu verziju GML i GeoJSON, stoga se može reći da su funkcionalno u potpunosti sposobne da zadovolje potrebe želeje mobilne aplikacije. 
Format dokumenta JSON, pogodan je za jednostavno rukaovanje podacima, takođe je pogodan i kao format za razmenu podataka u uslovima ograničenih resursa mobilnih uređaja. Prilikom rukovanja JSON-om nema konverzije podataka, i jednostavniji je u odnosu na XML format. Takođe JSON pogodniji i zbog manje potrošnje resursa pri obradi na strani mobilnog uređaja [4] [8]. 

MOBILNA PLATFORMA

Kao što je ranije pomenuto JavaEE je dominantna na danas aktuelnoj i ekonomski dostupnoj Android zasnovanoj platformi [5]. Savremeni mobilni operativni sistem zasnovan na Linux kernelu dozvoljava, a rekli bi i motiviše razvoj mobilnih aplikacija kodiranih u Java programskom jeziku. Ovako kodirane aplikacije koriste Google-enabled Java biblioteke za pristup mobilnom uređaju. Za razvoj aplikacija Google je takođe obezbedio Android SDK, dok je za sam proces kodiranja na raspolaganju više integrisanih okruženja, između kojih se ističe Eclipse IDE. 
Android platforma, kako javno ističe Google, ima četiri osnovne osobine: 
◆ otvorenog je koda, ◆ aplikacije su jednake, ◆ razvoj aplikacija je jednostavan ◆ nema ograničenja primene, i kako se može videti na sl. 4. so verski stek koji uključuje tri osnovna sloja operativni sistem, srednji sloj i aplikacioni sloj. 

Sl. 4. Arhitektura Androida [6]

Primarna funkcija Android aplikacije u sistemu za procenu rizika je prikupljanje podataka. Zbog toga je potrebno obazbediti korisnicima da podatke uskladište bez obzira na status mrežne konekcije. 
Android aplikacija preko Java interfesa komunicira sa serverom na kome se nalazi CouchDB baza podataka. Za prenos podataka (JSON objekata) od klijenta ka serveru koristi se HTTP protokol. Svaki zahtev koji se šalje serveru treba da sadrži, pored podataka koji će biti sačuvani, parametre odgovarajućeg CouchDB servera (IP i port servera centralne baze podataka). 

RUKOVANJE PODACIMA

Prilikom izbora arhitekture servera baze podataka i sistema za upravljanje bazom, do skoro nije bilo nikakvih dilema, relacioni sistemi su decenijama bili jedini mogući izbor. Relacione baze podataka su najbolje rešenje za rukovanje struktuiranim podacima, kada je šema podataka ksna i unapred de nisana. Međutim, kada su u pitanji geo prostorni podaci susrećemo sve veći priliv nestruktuiranih i slabo strktuiranih podataka za koje relacione baze podataka pokazuju određene slabosti. U takvim situacijama neke od NoSQL baza podataka mogu obezbediti veću raspoloživost, skalabilnost, jednostavnije rukovanje podacima i bolje performanse. 
NoSQL baze podataka su došle kao odgovor na potrebu čuvanja i rukovanja velikim, uglavnom nestruktuiranim, količinama podataka kao i potrebe za horizontalnim skaliranjem u takvim slučajevima. S tim konceptom prvi su, zbog sopstvenih potreba, krenuli Google s konceptom Google's BigTable [9] i Amazon sa svojim konceptom Amazon' s Dynamo [10]. Od tog perioda do danas razvijena su mnoga NoSQL rešenja čiji je zadatak da zadovolje zahteve i potrebe različitih organizacija u cilji skladištenja podataka. Skoro svaki sistem baza podataka koji ne podleže principima relacionih baza podataka može se svrstati u NoSQL sisteme. Danas se NoSQL baze podataka dele u sledeće grupe [11]: 
◆ Ključ-Vrednost baze podataka, ◆ Kolonski orijentisana baze podataka, ◆ Dokument orijentisane baze podataka ◆ Graf orijentisane baze podtataka Zajedničke karakteristike NoSQL baza podataka su: visoka skalabilnost i pouzdanost, jednostavan model podataka, nedostatak transakcionog mehanizma za rukovanje podacima i mehanizma za rukovanje ograničenjima i integritetom. 
Prednosti NoSQL baza podataka u odnosu na relacione baze su: rukovanje različitim tipovima podataka kap što su grafovi, objekti, slabo struktuirani i nestruktuirani podaci. Osim toga, NoSQL baze podataka su pogodnije pri obradi većih količina podataka i podržavaju jednostavniju skalabilnost što ih posebno kvali kuje za upotrebu u distribuiranim okruženju. 
Prednosti koje donose i sve veća primena NoSQL baza podataka u različitim oblastima [12] dovela je do ideje njihove primene i u geo sistemima. U tom smislu je i ovaj rad pokušaj da se neke od prednosti koje donose NoSQL baza podataka integrišu u informacionu strukturu integralnog sistema za procenu rizika. 
Postavlja se pitanje koju vrstu NoSQL baza podataka izabrati za podršku serverskoj strani i kako rukovati podacima na strani mobilnog klijenta sistema za procenu rizika. 

Server baze podataka

Obzirom na činjenicu da NoSQL sistemi baza podataka podacima rukuju bez šeme baze podataka to im omogućava slobodnu izmenu strukture slogova baze podataka i jednostavno dodavanje ili uklanjanje obeležja bez potrebe izmene šeme baze podataka. 
Kada su u pitanju mobilne aplikacije NoSQL baze podataka su interesantne zbog jednostavne izmene strukture poruka kojima mobilni uređaj komunicira s ostatkom sistema i samih zapisa baze podataka. 
Osim pomenutih razloga, kod geoinformacionih sistema postoje oblasti primene u kojima se mogu iskoristiti i neke druge prednosti NoSQL baza podataka koje dolaze do izražaja kada se javi potreba za rukovanjem velikom količinom podataka. Jedna od tih situacija kada u nekom geoinformacionom sistemu dolazi do intezivnog priliva velikog obima podataka je komunikacija geo servera s klijentima koje predstavljaju senzori raspoređeni na terenu i koji u de nisanim intervalima vremena dostavljaju izmerene podatke. U tim slučajevima, ukoliko je izabrana neka od arhitektura servera baze podataka koju podržavaju NoSQL baze, mogu se relativno jednostavno iskoristiti sve pogodnosti koje nude NoSQL sistemi baza podataka kao što su: horizontalna skalabilnost i distribucija. 
Analizirajući svaku od navedenih grupa NoSQL baza podataka, kao predlog servera baze podataka sistema za procenu rizika nameće se izbor neke od dokument orijentisanih baza podataka. U većini dokument orijentisanih baza podataka dokument koji se smešta u bazu je u JSON formatu. Struktura dokumenta je proizvoljna i može sadržati druge dokumente. U opštem slučaju dokumenti ne moraju da imaju istu strukturu. Ovakav pristup olakšava razvoj aplikacija gde unapred nije poznato sa kakvim će se podacima raditi i gde je potrebno čuvati više različitih tipova podataka unutar jednog dokumenta. U tom smislu je ova grupa NoSQL baza pogodna ne samo za jednostavno rukovanje podacima već i za pojednostavljenu razmenu podataka u komunikaciji između modula i komponenti sistema. 
Danas su najčešće korišćene CouchDB i MongoDB dokument orijentisane NoSQL baze podataka. 
CouchDB je open source dokument orijentisana NoSQL baza podataka. Za smeštanje dokumenata u bazu koristi JSON format. Pristup dokumentima vrši se putem HTTP protokola. Za realizaciju upita i transformacije dokumenata koristi se JavaScript. CouchDB pokazuje solidne performanse pri radu sa modernim web i mobilnim aplikacijama. Podaci se e kasno distribuiraju koristeći inkrementalnu replikacuju. 
Činjenica da se podaci skladište u JSON formatu, kvali kuje CouchDB kao mogući izbor za server baze podataka sistema za procenu rizika sa Android mobilnim klijentom. U tom slučaju bi se obezbedio identičan format razmene poruka u sistemu i format dokumenata u bazi podataka, čime bi se izbegla potreba konverzije i mapiranja podataka iz jednog formata u drugi. MongoDB je takođe dokument orijentisana NoSQL baza podataka, ali se kod nje dokumenti čuvaju u binarnom JSON formatu (Binary JSON -BSON). BSON format je e kasniji za razmenu jer je kompaktniji i poruke su kraće ali u slučaju izbora MongoDB-a za server baze podataka morala bi se vršiti konverzija komunikacionih poruka. 
Dokumenti koji će se razmenjivati u sistemu će biti složeni JSON dokumenti za skladištenje podataka vezanih za lokacije, tzv. GeoJSON. Na sl. 5 prikazana je planirana struktura dokumenata. Svaki od dokumenata u bazi sadrži meta podatke (na slici 5 su označeni zelenim pravougaonicima) i podatke unete od strane korisnika (na slici 5 su označeni žutim pravougaonicima). Ukoliko korisnik želi da pošalje više fotogra ja vezanih za datu situaciju, svaka fotogra ja će biti snimljena u bazu kao zaseban dokument. Dokumenti vezani za lokaciju i dokumenti sa fotogra jama povezivaće se preko meta podataka kao što je prikazano na slici 5. 

Sl. 5. Struktura JSON dokumenata koje Android klijent šalje serveru


Rukovanje podacima na strani mobilnog klijenta

Razvoj samostalne aplikacije na strani mobilnog klijenta na Android platformi obezbeđuje prednosti korišćenja svih komponenti samog uređaja i podrške za o -line funkcionalnost. 
Kod mobilnog klijenta na Android platformi potrebno je rukovati relativno malom količinom podataka, zbog čega je moguće koristiti i memorijski prostor samog uređaja za privremeno čuvanje prikupljenih podataka do trenutka slanja ka serveru i njegove potvrde prijema. 
Kada se na strani mobilnog klijenta rukuje većom količinom podataka, zbog pouzdanosti i e kasnosti rukovanja podacima potrebno je koristiti NoSQL bazu za mobilne klijente. Na taj način je moguće izbeći konverziju formata podataka jer je obezbeđeno da format podataka na serverskoj strani, mobilnom klijentu i sama komunikacija budu u istom formatu. 
Kada je u pitanju mobilni klijent sistema za procenu rizika potrebno je već sada predvideti mogućnost da se u narednoj fazi razvoja, bez obzira na količinu podataka, i na strani mobilnog klijenta koristi NoSQL baza podataka u cilju sticanja iskustava u radu s njima jer se radi o potpuno novim so verskim rešenjima. 

ZAKLJUČAK

NoSQL baze u velikoj većini skladište JSON u izvornom formatu, što je pogodno da se implementira koncept mobilne aplikacije koja kao format podataka koristi JSON. Zato se dokument orijentisane NoSQL baze podataka predlažu za korišćenje u sistemu procene rizika. Couch-DB, kao skladište podataka orijentisano ka dokumentima predstavlja jedno od idealnih rešenja za čuvanje velikih količina podataka pa je upravo to rešenje izabrano u cilju implementacije centralne baze podataka koja skladišti podatke koji pristižu sa Android aplikacije za akviziciju podataka. 
U poslednje vreme se pojavljuju i NoSQL sistemi za mobilne uređaje tako da se u narednom preiodu funkcionalnost mobilnog klijenta može proširiti korišćenenjem takvog sistema i kada je u pitanju manja količina podataka, kao što je slučaj kod mobilnog klijenta sistema za procenu rizika. 

3 .

 3 Stoga tipičnu arhitektura mobilne višeslojne aplikacije sa sl. 1. specijalizujemo upotrebom JSON formata dokumenata. Na sl. 3. Prikazana je arhitektura mobilne višeslojne aplikacije u kojoj se koristi JSON. Arhitektura JAVAEE mobilne višeslojne aplikacije sa JSON razmenom podataka 




  [1] 1. Tipična arhitektura mobilne višeslojne aplikacijeJoš jedan, bitan aspekt u korist JavaEE je potreba za interakcijom mobilne aplikacije sa nasleđenim sistemima poput onih koje imaju RHMZ-a, RGZ, VGI, osiguravajuća društva i dr.[1][2] [3] sl. 2. 


				GUI	
		Baza			
		podataka			
				Sloj logike	
				Reprezentacija	
				podataka	
				Servisi	
			Srednji sloj za		
	Nasleđeni sistem	Nestruktuirani podaci	prezentaciju nasleđenog	Struktuirani podaci	Mobilna aplikacija
			sistema		
	Sl. 2. Interakcija mobilne aplikacije sa nasleđenim sistemima
Predlog arhitekture distribuirane mobilne aplikacije za procenu rizika