Web Graph - pmf.ni.ac.rsunarske... · vaˇzno dobiti odgovore na ova pitanja u ˇsto kra´cem vremenskom roku. Inteligentne aplikacije i sistemi se baziraju na povezanosti izmed¯u

Univerzitet u Ni

ˇ

su

Prirodno-Matemati

ˇ

cki fakultet

Web Graph

Distribuirani sistem za pretragu grafova

Master rad

Kandidat: Mentor:

Dalibor Aleksov dr Marko Milosevic

Nis, Jul 2017

Sadrzaj

1 Uvod 2

1.1 Motivacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Istorijat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 O radu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Teorija grafova 5

2.1 Osnovni pojmovi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Graph6 (.g6) format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Prevodioci i interpretatori 12

3.1 Uvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Leksicka analiza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Sintaksna analiza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Distribuirani sistemi 15

4.1 Osnovni pojmovi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2 Sinhronizacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 Komunikacija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 WebGraph 21

5.1 Iz perspektive korisnika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2 newGRAPH biblioteka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.3 Gramatika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.4 Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.5 Interpreter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.6 Arhitektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.7 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.8 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.9 Logovanje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.10 Konfiguracija . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6 Zakljucak 45

1

Glava 1

Uvod

1.1 Motivacija

Teorija informacija nam govori da su podaci registrovane cinjenice, oznake ili zapazanja u okviru

nekog procesa koje prikupljamo i registrujemo da bismo ih sacuvali i po potrebi koristili. Ako

podatak iskoristimo radi preduzimanja nekih akcija i donosenja odluka, onda se on smatra

informacijom. Rec informacija potice od latinske reci in formare i izvorno je znacila stavljanje

u odredenu formu, odnosno, davanje oblika necemu.

Do nedavno je informacija kao pojam bila od velikog znacaja za svet i evoluciju. Medutim,

danasnji svet nije vise usmeren ka samim informacijama vec ka vezama izmedu njih. Takozvani

Big Data kao pojam sam za sebe, uglavnom i nije od neke velike koristi. Danas ljude vise

zanima na koji su to nacin podaci tj. informacije koje poseduju povezane. Takode je veoma

vazno dobiti odgovore na ova pitanja u sto kracem vremenskom roku.

Inteligentne aplikacije i sistemi se baziraju na povezanosti izmedu podataka. Takozvani

machine learning u smislu neprestanih pokusaja simulacije ljudskog mozga i nacina na koji

donosimo odluke na osnovu iskustava koje sticemo tokom zivota, u mnogome je ucinio problem

zanimljivijim. Sa druge strane, socijalne mreze (eng. Social Networks), koje povezuju ljude i

opisuju njihovu strukuturu i nacine medusobne interakcije, su vrlo brzo postale deo akademskih

interesovanja.

Grafovi (eng. Graphs/Networks), kao matematicki model, su najefikasniji i intuitivan nacin

za rad sa podacima i medusobnim relacijama izmedu nih.

2

GLAVA 1. UVOD 3

1.2 Istorijat

Pri izucavanju grafova obicno postoji potreba da se otkrije/potvrdi/opovrgne neka osobina

grafa. Naravno, otkrivanje novih osobina generalnih grafova je prava retkost, pa se uglavnom

proucavaju osobine pojedinih familija grafova. Cesto je pocetna tacka istrazivanja ispitivanje

uocene osobine na odredenim fiksiranim grupama grafova. To mogu biti razne standardne

(povezani grafovi, stabla, kubni grafovi sa odredenim brojem cvorova i mnoge druge), ali i

nestandardne grupe grafova. Ukoliko ta pocetna istrazivanja daju zeljene rezultate, nastavlja

se dalje istrazivanje na celim familijama grafova. Zato se javila prirodna potreba za sistemom

koji bi ovo pocetno istrazivanje znacajno ubrzao. Osnovni cilj je bio kreiranje sistema koji bi

omogucio zadavanje osobine koja se ispituje i grupe grafova na kojima se ona ispituje, a proces

filtriranja te grupe u odnosu na osobinu bi bio automatski.

Tako je nastao WebGraph sistem.

Originalna implementacija ovog sistema zapravo je newGRAPH biblioteka, koja je u celosti

napisana u programskom jeziku Java. Kreatori inicijalne verzije newGRAPH -a suD. Stevanovic

i V. Brankov, a nastala je 2003. godine. Ona se u praksi pokazala veoma korisnom, pa se

vrlo brzo javila potreba da se njene mogucnosti prosire. Ovo je bila dovoljna motivacija da

napravim web aplikaciju ciji bi zadatak bio da olaksa nacin na koji se newGRAPH biblioteka

koristi. Nastao je i WebGraph jezik, koji je u osnovi veoma prirodan i blizak pojmovima iz

teorije grafova, te se kao takav brzo uci.

Dakle, bilo je i vise nego jasno da je smer kojim je WebGraph sistem krenuo ispravan. Nar-

avno, kako je vreme prolazilo, sistem je postao slozeniji. Javila se potreba da WebGraph bude u

stanju da podrzi veliki broj konkurentnih klijenata. Sa druge strane kompleksna izracunavanja

nad grafovima su vremenski zahtevna pa je logicno, sve vise i vise, bilo problema u smislu per-

formansi, sto je imalo direktan uticaj na krajnje korisnike sistema. Jedno od resenja u datom

trenutku bilo je vertikalno skaliranje komponenti. Ali, naravno, dodavanje RAM memorije ili

brzeg disk-a i sl. nije urodilo plodom jer to nije trajno resenje.

Tako sam dosao na ideju da postojeci sistem distribuiram. Na taj nacin jeWebGraph postao

distribuirani sistem za pretragu grafova, a ovaj rad upravo govori o izazovima sa kojima sam

se na tom putu susreo.

GLAVA 1. UVOD 4

1.3 O radu

U radu se najvise govori o samoj arhitekturi WebGraph aplikacije. Pokusao sam da kroz

konkretan problem koji sam resavao obuhvatim razlicite oblasti teorije grafova, prevodioca i

interpretatora, distribuiranih sistema, web programiranja i sl. Podeljen je u cetiri glave.

U prvoj glavi su opisani osnovni pojmovi teorije grafova koji su neophodni. Govori se

o grafu kao strukturi kao i o raznim klasama grafova kao sto je stablo, bipartitni grafovi,

Ojlerovi i Hamiltonovi grafovi. Takode se navode i neke osnovne osobine. Opisan je i specifican

Graph6(.g6) format koji se uveliko koristi za predstavljanje grafova.

U drugoj glavi su opisani elementi teorije prevodioca i interpretatora kao i osnovni principi

i tehnike realizacije. Govori se o leksickoj i sintaksnoj analizi kao fazama kompilacije. Razma-

traju se dva poznata pristupa sintaksne analize (Top-down i Bottom-up). Takode se govori o

konkretnim alatima za kompajliranje.

Treca glava je posvecena distribuiranim sistemima, izazovima koje oni nose, kao i raznim

tehnikama dizajna i implementacije. Opisani su razni uslovi pod kojima se neki sistem smatra

distribuiranim. Takode se navodi poznata CAP (Consistency, Availability, Partition tolerance)

teorema koja nam govori da nije moguce dizajnirati distribuirani sistem koji zadovoljava sva tri

uslova istovremeno. Razmatraju se i razni principi komunikacije kao i nekoliko sinhronizacijskih

resenja.

Cetvrta glava se odnosi iskljucivo na WebGraph arhitekturu i implementaciju citavog sis-

tema. Opisana je WebGraph gramatika, parser i interpreter koji u osnovi koristi newGRAPH

biblioteku. Predstavljene su neke od tehnika koje se uveliko primenjuju na WEB -u kao i u

radu sa relacionim bazama podataka. Takode je opisan jedan od principa komunikacije putem

poruka (eng. Message queue). Konacno, govori se o samoj aplikaciji kao i o buducim koracima

usavrsavanja sistema.

Glava 2

Teorija grafova

Na pocetku se daju neke osnovne definicije iz teorije grafova koje ce biti od znacaja za bolje

razumevanje problema koji se resava. Ove i ostale definicije mogu se naci u bilo kom udzbeniku

iz teorije grafova. Moja preporuka je:

R. Diestel, Graph Theory, 2017 Springer (http://www.springer.com/gp/book/9783662536216).

2.1 Osnovni pojmovi

Definicija 2.1.1. Graf G (eng. graph) je uredeni par (V,E), gde je E ✓�V2

�(skup svih

dvoelementnih podskupova skupa V ). Elementi skupa V se zovu cvorovi (eng. vertex), a elementi

skupa E grane (eng. edge) grafa G. Ako je e = {u, v} 2 E, tada su u i v krajevi grane e, a

kaze se i da su cvorovi u i v susedni, odnosno da je cvor u sused cvora v i obrnuto. Grana

e = {u, v} se skraceno pise e = uv. Za dati graf G, skup cvorova se oznacava sa V (G), a skup

grana sa E(G)

Definicija 2.1.2. Graf G = (V,E) moze se vizuelno predstaviti tako sto se svaki cvor v 2 V

predstavi kao tacka u ravni, a svaka grana e = uv 2 E kao Zordanova kriva cije krajnje tacke

predstavljaju cvorove u i v.

Definicija 2.1.3. Put sa n cvorova je graf Pn, n 2 N , sa skupom cvorova {1, 2, ..., n} i skupom

grana {{i, i+ 1} : i = 1, 2, ..., n� 1}

5

http://www.springer.com/gp/book/9783662536216

GLAVA 2. TEORIJA GRAFOVA 6

Definicija 2.1.4. Ciklus sa n cvorova je graf Cn, n 2 N , sa skupom cvorova {1, 2, ..., n} i

skupom grana {{i, i+ 1} : i = 1, 2, ..., n� 1} [ {n, 1}.

Definicija 2.1.5. Kompletan graf sa n cvorova je graf Kn, n 2 N , sa skupom cvorova {1, 2, ..., n}i skupom grana

�{1,2,...,n}2

�

Definicija 2.1.6. Kompletan m-partitni graf je graf Kn1,n2,...,nm, m 2 N , sa skupom cvorova

V1 [ V2 [ ... [ Vm i skupom grana {uv : u 2 Vi, v 2 Vj, i 6= j}, gde su V1, V2, ..., Vm disjunktni

skupovi takvi da je |Vi| = ni, i = 1, 2...,m

Definicija 2.1.7. Pod otvorenom okolinom cvora u grafa G = (V,E), podrazumeva se skup

NG(u) = {v 2 V : {u, v} 2 E} suseda cvora u. Pod zatvorenom okolinom cvora u podrazumeva

se skup NG[u] = NG(u) [ {u}

Definicija 2.1.8. Stepen cvora u je broj dG(u) = |NG(u)| suseda cvora u. ZbirP

u2V dG(u)

stepena svih cvorova grafa G jednak je dvostrukom broju grana grafa G (pa je stoga i broj

cvorova neparnog stepena paran broj).

Definicija 2.1.9. Najmanji stepen grafa G je �(G) = minu2V dG(u), a najveci stepen grafa G

je �(G) = maxu2V dG(u).

Definicija 2.1.10. Graf G je r-regularan, r 2 N , ako je �(G) = �(G) = r.

Definicija 2.1.11. Graf G je regularan ako postoji r 2 N tako da je G r-regularan graf.

Definicija 2.1.12. Matrica susedstva A = AG grafa G = (V < E) je kvadratna matrica cije

su vrste i kolone indeksirane skupom covora V i vazi da je

Auv =

(1, uv 2 E

0, uv 62 E

Primer 2.1.1.


A =

2

6666664

1 1 0 0 1 01 0 1 0 1 00 1 0 1 0 00 0 1 0 1 11 1 0 1 0 00 0 0 1 0 0

3

7777775

Definicija 2.1.13. Matrica incidentnosti M = MG grafa G = (G, V ) je matrica cije su vrste

indeksirane skupom cvorova V , a kolone su indeksirane skupom grana E i vazi da je

Mve =

(1, v 2 e

0, v 62 e

Definicija 2.1.14. Graf G0= (V

0, E

0) je podgraf grafa G = (V,E) ako vazi V

0 ✓ V i E0 ✓

E \�V2

�. Graf G je nadgraf grafa G

0ako je G

0podgraf grafa G.

Definicija 2.1.15. Podskup C ✓ V cvorova grafa G = (V,E) je klika ako su svaka dva cvora

x, y 2 C, x 6= y, susedna u G.

Definicija 2.1.16. Setnja W duzine k u grafu G = (V,E) je niz v0, e1, v1, e2, v2, ..., ek, vk cvorova

i grana tako da je ei = vi�1vi za i = 1, 2, ..., k. Cvorovi v0 i vk su krajnji cvorovi (krajevi) setnje

W, a kaze se i da je W setnja izmedu cvorova v0 i vk. Setnja je zatvorena ako je v0 = vk.

Definicija 2.1.17. Staza je setnja u kojoj se nijedna grana ne ponavlja. Put je setnja u kojoj

se nijedan cvor ne ponavlja. Ciklus (ili kontura) je zatvorena staza u kojoj se nijedan cvor ne

ponavlja, izuzev prvog i poslednjeg.

Definicija 2.1.18. Cvorovi u i v grafa G su povezani ako u G postoji put ciji su krajnji cvorovi

u i v. Graf G je povezan ako su svaka dva njegova cvora povezana. Graf G je nepovezan ako

G nije povezan. Komponente grafa G su njegovi maksimalni povezani podgrafovi.

Definicija 2.1.19. Cvor v 2 V (G) grafa G zove se presecajuci cvor (ili artikulacioni cvor) ako

G � v ima vise komponenti povezanosti od G. Grana e 2 E(G) grafa G zove se presecajuca

grana (ili most) ako G� e ima vise komponenti povezanosti od G.

Definicija 2.1.20. Ako su cvorovi u i v grafa G povezani, tada je rastojanje dG(u, v) od cvora u

do cvora v jednako duzini najkraceg puta izmedu cvorova u i v. Ako cvorovi u i v nisu povezani,

onda je rastojanje dG(u, v) = 1

Definicija 2.1.21. Dijametar D(G) grafa G = (V,E) je maxu,v2V dG(u, v). Ekscentricitet

✏G(u) cvora u je maxv2V dG(u, v). Radijus r(G) grafa G je minu2V ✏G(u). Centar grafa G cine

cvorovi ciji je ekscentricitet jednak radijusu.

Definicija 2.1.22. Graf G = (V,E) je bipartitan ako postoji particija skupova cvorova V =

V1[V2, V1\V2 = ;, tako da za svaku granu e 2 E vazi da ona spaja cvor iz V1 sa cvorom iz V2.


Definicija 2.1.23. Komplement G grafa G = (V,E) je graf G = (V,�V2

�\E)

Definicija 2.1.24. Povezani graf bez ciklusa naziva se stablo. Graf koji ne sadrzi cikluse, tj.

graf cija je svaka komponenta povezanosti stablo naziva se suma.

Definicija 2.1.25. Cvor stepena 1 u grafu G naziva se list.

Definicija 2.1.26. Centar stabla se sastoji od jednog ili dva susedna cvora, a dobija se istovre-

menim uklanjanjem svih listova stabla i ponavljanjem ovog postupka dok ne ostane najvise dva

cvora pocetnog stabla.

Definicija 2.1.27. Zatvorena staza koja prolazi kroz sve grane grafa G naziva se Ojlerova

kontura. staza, koja nije zatvorena i koja prolazi kroz sve grane grafa G, naziva se Ojlerov put.

Graf G je Ojlerov ako sadrzi Ojlerovu konturu.

Definicija 2.1.28. Ciklus koji prolazi kroz sve cvorove grafa G naziva se Hamiltonova kontura.

Put koji prolazi kroz sve cvorove grafa G naziva se Hamiltonov put. Graf G = (V,E) je

Hamiltonov ako sadrzi Hamiltonovu konturu.

Primer 2.1.2. Konacno grafovi predstavljaju mozda i najzanimljiviju strukturu podataka,

kako sustinski tako i vizuelno. Primera radi evo kako izgledaju svi povezani grafovi sa 6 cvorova.


Definicija 2.1.29. Dva grafa G1 = (V1, E1) i G2 = (V2, E2) su izomorfna ako postoji bijekcija

f : V1 ! V2 za koju vazi da je {u, v} 2 E1 ako i samo ako je {f(u), f(v)} 2 E2. Funkcija

f se naziva izomorfizam grafova, a cinjenicu da su grafovi G1 i G2 izomorfni oznacavamo sa

G1⇠= G2

S obzirom da izomorfni grafovi imaju istu strukturu, uvodimo jos jednu vaznu definiciju.

Definicija 2.1.30. Funkcija i, definisana na skupu grafova, se naziva invarijantom grafova,

ukoliko za svaka dva izomorfna grafa G ⇠= H vazi da je i(G) = i(H).

Prema tome invarijante grafova zavise od strukture a ne od oznacavanja grafa. Ima veoma

puno invarijanti grafova i one, u stvari, predstavljaju glavni predmet proucavanja Teorija

grafova. Sledece funkcije su primeri jednostavnih invarijanti grafa: broj cvorova u grafu, broj

grana u grafu, itd..

Invarijante grafova se mogu koristiti i prilikom provere da li su grafovi izomorfni. Naime,

ukoliko uspemo da pronademo invarijantu koja za dva grafa dobija dve razlicite vrednosti, onda

je sigurno da ta dva grafa nisu izomorfna.


2.2 Graph6 (.g6) format

Graph6 (.g6) format se koristi za pamcenje neorijentisanih grafova u kompaktnom formatu

koji se sastoji samo od stampajucih (eng. printable) ASCII karaktera. Obicno se koristi za

pamcenje vecih kolekcija grafova. Fajlovi u kojima se cuvaju ovakvi grafovi su tekstualni sa

jednom linijom teksta po grafu. Razvio ga je Brendan McKay, Australian National University.

Primera radi regularni grafovi reda 8 i stepena 2 izgledaju u Graph6 (.g6) formatu ovako:

Za niz bitova x, definisemo funkciju R(x), na sledeci nacin:

• Prosirimo nulama niz sa kraja, tako da njegova nova duzina k bude deljiva sa 6

• Podelimo niz na k/6 grupa od po 6 binarnih cifara, svaka grupa sada predstavlja broj

izmedu 0i63

• Svakom od dobijenih brojeva dodamo 63, svaki od ovih brojeva moze biti zapamcen

jednim bajtom i svaki od njih predstavlja jedan ASCII karakter

• R(x)je niz dobijen spajanjem ovih brojeva

Primer 2.2.1. Neka je x = 1000101100011100. Posle prosirenja, postaje 100010 110001 110000.

Ovo su binarno zapisani brojevi 34 49 48. Konacno, R(x) = 97 112 111.

Funkciju N(n) definisemo za prirodan broj 0 n 236 � 1, na sledeci nacin:

• Ako je 0 n 62, onda je N(n) = n+ 63 - predstavlja jedan karakter iz ASCII tabele

• Ako je 63 n 258047, onda je N(n) = 126R(x), gde je x 18-bitna bigendian (https:

//en.wikipedia.org/wiki/Endianness) reprezentacija broja n

• Ako je 258047 n 236 � 1, onda je N(n) = 126 126R(x), gde je x 36-bitna bigendian

reprezentacija broja n

Primer 2.2.2. N(30) = 93,

N(12345) = N(000011 000000 111001) = 126 66 63 120,

N(460175067) = N(000000 011011 011011 011011 011011 011011) = 126 126 63 90 90 90 90 90

Ovakav format omogucava da se zapamte prosti neorijentisani grafovi velicine od 0 do 22361

cvorova. Opciono, moze sadrzati zaglavlje >>graph6<<, bez novog reda na kraju. Pret-

postavimo da graf ima n cvorova. Ako gornji trougao matrice susedstva (deo iznad glavne

https://en.wikipedia.org/wiki/Endianness

https://en.wikipedia.org/wiki/Endianness


dijagonale) zapisemo kao niz bitova x duzine n(n� 1)/2, citajuci elemente po kolonama, onda

graf predstavljamo kao N(n)R(x).

Postoje i drugi formati: Sparse6, GraphML, GXL

Reference:

• http://reference.wolfram.com/language/ref/format/Graph6.html.en

• http://users.cecs.anu.edu.au/

~

bdm/data/formats.txt

http://reference.wolfram.com/language/ref/format/Graph6.html.en

http://users.cecs.anu.edu.au/~bdm/data/formats.txt

Glava 3

Prevodioci i interpretatori

3.1 Uvod

Programski jezici su notacija za opisivanje racunskih operacija koje su razumljive kako ljudima

tako i samim racunarima. Svet kakav ga znamo danas, zavisi od programskih jezika, jer je soft-

ware koji postoji na danasnjim racunarima napisan u nekom od programskih jezika. Medutim,

pre nego sto se program moze pokrenuti, najpre mora biti preveden u oblik u kojem ga moze

izvrsiti racunar. Software-ski sistemi koji prevode se nazivaju kompajleri ili prevodioci. U ovoj

glavi se necemo previse baviti samim prevodiocima ali cemo dati neke osnovne pojmove i ob-

jasniti njihovu sustinu. Razmotricemo takode nekoliko osnovnih ideja koje se mogu koristiti za

izgradnju prevodioca za sirok spektar jezika i masina.

Neformalno, kompajler je software koji je u stanju da procita program koji je napisan u

jednom jeziku (source) i prevede ga u ekvivalentan program na drugom jeziku (target). Vazna

uloga kompajlera je da prijavi sve greske koje detektuje prilikom procesa prevodjenja.

Dakle, programski prevodilac je program koji sa nivoa viseg programskog jezika prevodi na

nizi programski jezik ili bolje receno na nizi nivo apstrakcije masinskog jezika. U najcescem

slucaju prevodi se upravo na masinski jezik. Postoje i slucajevi kada se masinski kod prevodi

u asemblerski jezik, ali su oni dosta redi. Tada je rec o prevodenju sa nizeg na visi nivo.

Prevodenje se u principu svodi na uspostavljanje korespodencije izmedu iskaza izvornog i ciljnog

programskog jezika

Programski prevodioci su se razvijali kroz istoriju zajedno sa razvojem hardware-a i soft-

ware-a. Pojava prvog kompajlera krajem 50-ih i pocetkom 60-ih bio je vrlo vazan momenat,

koji je oblast programiranja podigao na znatno visi i profesionalniji nivo.

Poseban tip prevodioca je kompilator ili kompajler, koji prevodi kod u celini i generise

masinski kod. On prolazi kroz fazu sinteze i analize.

12

GLAVA 3. PREVODIOCI I INTERPRETATORI 13

Sinteza se sastoji iz dve faze: generisanje koda i optimizacija koda, dok je analiza nesto kom-

pleksnija. Ona se sastoji iz tri faze: Leksicka analiza, Sintaksna analiza i Semanticka analiza.

Pored kompajlera postoje i interpretatori cija je uloga da interpretiraju naredbu po naredbu.

Interpretatori se primenjuju onde gde je potrebna interakcija korisnika i same masine.

Naravno, postoje i hibridna resenja. Dobar primer je programski jezik Java, gde se prolazi

kroz analizu, dobija se medukod, koji se kasnije interpretira.

3.2 Leksicka analiza

Leksicka analiza je prva faza u procesu kompilacije. Zadatak leksickog analizatora je da ulazni

tekst transformise u niz ulaznih simbola (tokena) koji se dalje prosleduju sintaksnom analiza-

toru. Za prepoznavanje tokena iz ulaznog niza znakova koriste se sabloni. Dakle, iz ulaznog

niza karaktera izdvajaju se oni nizovi koji predstavljaju osnovne jezicke konstrukcije - reci ili

lekseme, a koje se potom preslikavaju u odgovarajuce tokene.

Pored izdvajanja tokena leksicki analizator treba da odredi i pojedine atribute tokena koje

pronade. Recimo, atribut konstante je njena vrednost, sto ce reci da leksicki analizator treba da

generise vrednosti konstanti i da ih upise u memoriju u formatu za odgovarajuci tip podataka.

S obzirom da leksicki analizator prvi pristupa izvornom kodu njegovi sekundarni zadaci su:

uklanjanje praznina i komentara.

Sabloni kojima se definisu tokeni se uglavnom zadaju pomocu regularnih izraza (regularnih

gramatika). Otuda se za prepoznavanje tokena koriste konacni automati. Tako se projektovanje

leksickog analizatora svodi na kreiranje konacnog automata. Prvi korak pri tome je kreiranje

grafa prelaza konacnog automata. Kada je dijagram prelaza formiran prelazi se na njegovu

implementaciju. Leksicki analizator moze biti implementiran na:

• nekom visem programskom jeziku za koji vec postoji kompilator za odgovarajuci racunar

• asemblerskom jeziku odredisnog racunara

• jeziku nekog od alata za automatsko generisanje leksickog analizatora

Kada se leksicki analizator implementira na asemblerskom ili nekom visem programskom

jeziku, uobicajeno je da se za svako stanje automata generise posebna funkcija. Na taj nacin

se postize relativno jednostavna izmenljivost i prosirljivost automata.

Dakle, izvorni kod se pojednostavljuje i kao takav je spreman za dalju analizu, tacnije za

fazu sintaksne analize.

GLAVA 3. PREVODIOCI I INTERPRETATORI 14

3.3 Sintaksna analiza

Sintaksni analizator prima niz tokena od leksickog analizatora i proverava da li taj niz pripada

jeziku zadate gramatike. Dakle, sintaksni analizator generise takozvano sintaksno stablo za

ulazni niz tokena. Sintaksno stablo se moze generisati na dva nacina:

• metodom odozgo nanize (top-down), ili

• metodom odozdo navise (bottom-up).

Top-down sintaksni analizatori formiraju sintaksno stablo od korena prema listovima. Oni

krecu od startnog simbola gramatike (koji se nalazi u korenu svakog sintaksnog stabla) i

pokusavaju da ga, primenom konacnog broja smena, preslikaju u ulazni niz; tj. oni ulazni

niz izvode iz startnog simbola.

Bottom-up sintaksni analizatori formiraju sintaksno stablo od listova prema korenu (dakle

obrnuto). Oni ulazni niz tokena pokusavaju da redukuju na startni simbol gramatike.

I jedan i drugi postupak sintaksne analize mogu da budu veoma dugi i komplikovani. U oba

postupka, najpre se pokusava sa primenom jedne smene. Ako se u daljem toku analize ne dode

do zeljenog rezultata, vrsi se vracanje unazad, ponistava se dejstvo te smene i pokusava neka

druga. Postupak se nastavlja dok se ulazni niz ne prepozna ili dok se ne iscrpe sve alternative.

Zbog toga su definisani posebni tipovi gramatika koje omogucavaju da se postupak sintaksne

analize vrsi bez vracanja.

Dakle, sintaksni analizator je glavni deo kompajlera. Ulaz u sintaksni analizator je pojed-

nostavljeni kod iz leksickog analizatora. Zadatak sintaksnog analizatora je da ustanovi koja

su pravila jezika i kojim redosledom su primenjivana. On generise sintaksno stablo tj. stablo

sintaksne analize koje pokazuje koji skup pravila kojim redosledom je primenjen. Leva strana

pravila je cvor a desna svaki token.

Kao i za leksicke analizatore, tako i za sintaksne analizatore postoje vec gotovi programi

koji ih generisu. Veoma popularni alati koji se aktivno koriste i izucavaju na studijama su LEX

i YACC. Medutim, kako je ovaj projekat pisan u programskom jeziku Java, odlucio sam se

da koristim alate koji su dostupni: JavaCC kao predstavnik alata za automatsko generisanje

sintaksnih analizatora kao i JJTree koji generise sintaksno stablo koje se koristi za konstrukciju

parsera i interpretera. Nessto vise o samim alatima se nalazi u poslednjoj glavi, kada se opisuje

nacin na koji su korisceni.

Glava 4

Distribuirani sistemi

Sve cesce se u danasnjem IT svetu moze cuti pojam distribuiranih sistema. Danasnje najvece

IT kompanije na svetu poput Google-a, Microsoft-a, Facebook -a, Amazon-a i ostalih, veliki

deo svojih resursa u smislu vremena i novca potrose na razvoj ovakvih sistema ne bi li im isti

omogucili skalabilnost, pouzdanost i performanse. Takode, male kompanije (eng. startups) u

toku svog zivotnog veka vrlo brzo dostignu fazu u kojoj se jave realne potrebe za resavanjem

ovakvih problema. Dakle, za razvoj ozbiljnog sistema je neophodno dati odgovore na sledeca

pitanja:

• Koliko je sistem skalabilan?

• Koliko je sistem pouzdan? Sta se desava u slucaju otkaza sistema?

• Koliko je sistem brz?

Drugim recima zahtevi koji se prirodno namecu u mnogobrojnim oblastima primene racunara

sve vise i vise ukazuju na potrebu za stvaranjem novih generacija racunara od kojih se ocekuje

velika fleksibilnost arhitekture i njenih komponenti. Takode je veoma bitno da povecanje per-

formansi sistema ne utice u velikoj meri na cenu tj. da ona ostane u razumnim granicama.

Sa druge strane sve vise se javlja potreba za sistemima u kojima su racunari sposobni da

komuniciraju putem mreze.

Odgovore na ova pitanja daje upravo oblast distribuiranih sistema o kojima ce u ovoj glavi

biti reci.

15

GLAVA 4. DISTRIBUIRANI SISTEMI 16

4.1 Osnovni pojmovi

Mreze i racunari su svuda oko nas. Internet je jedan od njih kao i mnoge podmreze od kojih je

on sastavljen. Mobilne mreze, korporativne mreze, mreze u okviru fabrika, kucne mreze, mreze

unutar jednog automobila - sve one, pojedinacno ili u nekoj od kombinacija dele zajednicke

karakteristike koje ih cine relevantnim za posmatranje kao deo nekog distribuiranog sistema.

Vrlo cesto se spominje pojam horizontalnog i vertikalnog skaliranja. Kada imate monolitan

sistem (jedan racunar) onda je vertikalno skaliranje jedina opcija koju imate na raspolaganju.

Dakle mozete da dodate RAM ili CPU i na taj nacin poboljsate performanse. Medutim koliko

god da je brz najbolji CPU, jos veca brzina se postize ukoliko vise takvih procesora radi u

paraleli.

Poboljsanje performansi koje se dobija poboljsanjem nekog odredenog dela racunara moze

da se izracuna na osnovu Amdalovog zakona.

Teorema 4.1.1. (Amdalov zakon). Ubrzanje programa, koji koristi vise procesora u paralelnom

okruzenju, je ograniceno vremenom koje je potrebno da se obradi sekvencijalni deo programa.

Zakon je dobio ime po racunarskom arhitekti Dzinu Amdalu (Gene Amdahl). Zakon je

predstavljen u americkoj federaciji drustva za obradivanje podataka (engl. American Federation

of Information Processing Societies, AFIPS) na Spring Joint racunarskoj konferenciji 1967.

Suprotno ovom zakonu vrlo cesto kada se govori o projektovanju sistema koristi se Gus-

tavsonov zakon.

Teorema 4.1.2. (Gustavsonov zakon). S(P ) = P � ↵ ⇤ (P � 1), gde je P broj procesora, S je

ubrzanje i ↵ je neparalelizovan deo bilo kog paralelnog procesa

Formulisao ga je Dzon L. Gustavson. On zapravo govori o manama Amdalovog zakona, koji

ne eksploatise potpuno moc izracunavanja koja postaje dostupna kako se povecava broj masina.

Umesto toga Gustavsonov zakon predlaze da se tezi ka odredivanju velicine problema da bi onda

koristili dostupnu opremu kako bi resili probleme u prakticnom fiksnom vremenskom periodu.

Dakle, ukoliko je brza oprema dostupna, veci problemi ce se resavati u istom vremenskom roku.

Pojavom ovog zakona uneto je malo vise optimizma.

Jasno je da su ovakvi sistemi veoma slozeni i da imaju veliki broj osobina. Medutim, postoji

nekoliko osobina koje su zajednicke za sve njih, i ovde cu ih navesti kao definicije.

Definicija 4.1.1. Za sistem kazemo da je konzistentan, odnosno da zadovoljava uslov konzis-

tencije (eng. Consistency) ukoliko garantuje da svaka operacija citanja (eng. read) kao rezultat

dobija poslednji upisani (write) podatak ili dobija gresku.

Neformalno, ovo znaci da sistem ne dozvoljava takozvane dirty-reads.


Definicija 4.1.2. Za sistem kazemo da je dostupan, odnosno da zadovoljava uslov dostupnosti

(eng. Availability) ukoliko nastavlja da radi normalno bez obzira na otkaz neke od racunarskih

komponenti u sistemu.

Ukoliko sistem zadovoljava ovu osobinu onda je jasno da ovde nema garancije da odgovor

koji se dobije prilikom citanja, sadrzi poslednje upisani podatak (eng. record).

Definicija 4.1.3. Za sistem kazemo da je tolerantan na particionisanje, (eng. Particion toler-

ance) ukoliko je sistem je u stanju da radi normalno bez obzira na proizvoljan broj poruka koje

se izgube (ili zakasne) u komunikaciji (mrezi) izmedu nodova (racunara)

Iz prethodno navedenih osobina formulisacemo najvazniju teoremu iz ove oblasti:

Teorema 4.1.3. (CAP teorema) Ne postoji distribuirani sistem koji zadovoljava sve tri osobine

istovremeno.

Dakle nije moguce konstruisati sistem koji bi ispunio svaki od ovih uslova. Primera radi

relacione baze podataka zadovoljavaju konzistentnost ali ne i dostupnost, dok sa druge strane

takozvane Document based baze ili NoSQL biraju pre dostupnost nego konzistentnost.

Pitamo se sta je onda distribuirani sistem? Formalna definicija ne postoji ali je ovde data

ona koja je najprihvacenija.

Definicija 4.1.4. Distribuirani sistem je kolekcija nezavisnih racunarskih komponenti (soft-

ware, hardware) koje se predstavljaju korisnicima kao jedan sistem, a komuniciraju i koordini-

raju iskljucivo slanjem poruka putem komunikacionog kanala (mreze) ciji su sastavni deo.

Jednostavno, to je kolekcija racunara koji rade zajedno na resavanju konkretnog problema

koji se za krajnjeg korisnika predstavljaju kao jedna stvar, cineci implementaciju i arhitekturu

sistema sakrivenom.

Geografska nezavisnost komponenti. Racunari koji su deo neke mreze mogu biti geograf-

ski razdvojeni. Dakle, sasvim je legitimno da u okviru jednog distribuiranog sistema postoje

racunarske komponente koje su fizicki resprostranjene na razlicitim geografskim lokacijama

(kontinentima, drzavama, gradovima). Isto tako one mogu biti u okviru jedne zgrade ili sobe.

Dakle, od sustinske je vaznosti da komponente distribuiranog sistema ne zavise od geografije

sto sistem cini izuzetno robusnim.


Osobina konkurentnosti. U jednoj racunarskoj mrezi i distribuiranom sistemu, konkurentno

izvrsenje programa se podrazumeva. Svaki racunar obavlja svoj posao nezavisno od ostalih, dok

pri tom medusobno dele resurse kada je to potrebno. Drugim recima, vise racunara izvrsava

svoje zasebne zadatke u isto vreme.

Nezavisnost otkaza komponenti. U slucaju velikog klastera (eng. cluster) masina koje rade

zajedno, regularna je situacija da dode do otkaza neke od komponenti ili mozda citavog pod-

sistema, a da korisnik sistema nista ne zna o tome. Zato se u toku dizajniranja distribuiranog

sistema mora voditi racuna o problemima otkaza, tj. mora se racunati na njih.

Globalni sat (eng. global clock). Racunarske kompenente distribuiranog sistema ne dele

globalni clock. To zapravo znaci da postuju asinhroni model u odnosu na druge masine u

sistemu. Posao koji jedna komponenta radi ne blokira izvrsenje druge komponente, osim u

slucaju kada se to eksplicitno ne ocekuje od sistema. Blokiranje u ovom smislu se realizuje

pomocu nekih od algoritama i tehnologija sinhronizacije o kojima ce kasnije biti reci.

Do sada smo govorili o distribuiranom sistemu kao celini. Medutim vise je nego jasno da je

konkretna implementacija ovakvog sistema zapravo odredena manjim komponentama koje ga

cine. Tako mozemo da podelimo problem distribuiranosti na:

• Distribuiranje podataka (eng. storage)

• Distribuiranje izracunavanja (eng. computation)

• Vremenska sinhronizacija medu komponentama sistema

• Logicka sinhronizacija medu komponentama sistema

• Komunikacija

Svaka od ovih celina zasluzuje posebnu paznju. Ovde se ne bavimo izvucavanjem svake od

tehnika pojedinacno ali ukazujemo na neke od najbitniji problema i kako se oni mogu resiti.

Dakle, akcenat je na sinhronizaciji i komunikaciji.


4.2 Sinhronizacija

U slucaju sinhronizacije u okviru distribuiranog sistema, uglavnom se posmatraju dva tipa:

logicka i vremenska sinhronizacija.

Logicka sinhronizacija se odnosi na koordinaciju izmedu procesa. U slucaju nedistribuira-

nog sistema relativno je lako koordinisati medu procesima. Postoje razne sistemske rutine

na nivou samih operativnih sistema, takode mogu se koristiti razne multithreading tehnike

poput semafora, monitora i slicno. Medutim, u slucaju racunara koji su potpuno nezavisni

(stavise nalaze se na razlicitim geografskim lokacijama), problem logicke sinhronizacije postaje

veoma slozen. U praksi se ovaj problem resava tako sto se koriste neka od vec gotovih resenja

poput Zookeeper -a (https://zookeeper.apache.org/). Zookeeper je mozda jedno od na-

jboljih resenja; veoma se lako instalira i podesava, biblioteke postoje gotovo za sve moderne

programske jezike i ono sto je mozda najvaznije, veoma se lako skalira. Dakle, ukoliko je sistem

toliko slozen da je i sam Zookeeper potrebno skalirati, moze se koristiti Zookeeper klaster kao

i servis po imenu Exhibitor (https://github.com/soabase/exhibitor) koji je na neki nacin

odgovoran za njegov menadzment.

Sa druge strane, imamo problem vremenske sinhronizacije. Ovaj problem se odnosi na

sinhronizaciju satova izmedu racunara. Bitno je da komponente ukazuju na isto ili barem do-

voljno slicno vreme. Ukoliko je vremenska razlika izmedu racunara velika i rizik da podaci

postanu nekonzistentni je veci. Jedno od resenja ovakvog problema jeste takozvani NTP -

Network Time Protocol (https://en.wikipedia.org/wiki/Network_Time_Protocol). NTP

protokol radi po principu razmene paketa izmedu racunara sistema i nekih globalnih NTP

servera. Prilikom razmene paketa racuna se procenjeno vreme primenom razlicitih algoritama

optimizacije i na taj nacin se ne dozvoljava racunarima da dodu u nekonzistentno stanje. Pos-

toji jos jedna tehnika pod imenom Vector clocks (https://en.wikipedia.org/wiki/Vector_

clock).

https://zookeeper.apache.org/

https://github.com/soabase/exhibitor

https://en.wikipedia.org/wiki/Network_Time_Protocol

https://en.wikipedia.org/wiki/Vector_clock

https://en.wikipedia.org/wiki/Vector_clock


4.3 Komunikacija

Kada je rec o komunikaciji zapravo se misli na nacin razmene informacija medu racunarima.

Najcesce se koristi neka od poznatih tehnika komunikacionih kanala (eng. Message Queue).

Navescu samo neke od najrasprostranjenijih tehnologija:

• RabbitMQ - https://www.rabbitmq.com/

• Kafka - https://kafka.apache.org/

• ZeroMQ - http://zeromq.org/

Message queue pruza nivo apstrakcije u komunikaciji, jer konkretnu implementaciju prenosa

podataka sakriva od korisnika, a sa druge strane pruza mnogobrojne nacine konfiguracije. Per-

formanse prenosa podataka kroz kanal su veoma dobre ali je bez obzira na ovu cinjenicu vrlo

lako (u slucaju velikih sistema) moguce doci u situaciju da ovo postane usko grlo. Skaliranje

samog Message queue-a kao komponente je tezak zadatak. Potrebno je povezati message bro-

ker racunare u klaster. Tom prilikom, dolazi do slozenijih problema klasterizacije. Svaka od

pomenutih tehnologija ima odlican interfejs za skaliranje koji je itekako otvoren za klasteri-

zaciju. Postoje i takozvana cloud based resenja poput Cloud AMQP (u slucaju RabbitMQ-a)

koja komunikaciju medu komponentama podizu na najvisi nivo.

https://www.rabbitmq.com/

https://kafka.apache.org/

http://zeromq.org/

Glava 5

WebGraph

U ovom poglavlju je opisan WebGraph kao distribuirani sistem za pretragu grafova. Citava

aplikacija kao i sve njene komponente su izradene u programskom jeziku Java. Najpre je

opisan sistem iz perspektive krajnjeg korisnika. Dalje se opisuje biblioteka newGRAPH koja

predstavlja osnovu sistema. Zatim se govori o WebGraph gramatici, parseru i interpreteru.

Nakon toga razmatra se arhitektura sistema i svih njegovih komponenti i servisa. Nesto veci

akcenat je na realizaciji komunikacije izmedu servisa koji ovaj sistem cine robusnim u smislu

skalabilnosti, stabilnosti i performansi.

5.1 Iz perspektive korisnika

WebGraph je web aplikacija, tako da se njoj pristupa pomocu browser-a, tableta ili mobilnog

uredaja. Napomenucu da je korisnicki interfejs aplikacije responsive, sto zapravo znaci da je

dovoljno pametan da se prilagodi mobilnim uredajima i tabletima koji imaju manje ekrane

od onih koji se koriste na desktop racunarima, tako da prilikom pristupa aplikaciji sa ovakvih

uredaja moguce je da korisnicki interfejs izgleda neznatno drugacije (optimalnije).

Naslovna strana WebGraph sistema izgleda ovako:

Kao sto se moze videti, na naslovnoj strani postoji par sekcija u glavnom meniju, ali je vrlo

bitno napomenuti da anonimni korisnik (onaj koji se jos uvek nije registrovao), moze odmah da

21

GLAVA 5. WEBGRAPH 22

unese svoj izraz, da isti validira i izvrsi nad odredenim minimalnim skupom grafova. Naravno,

skup grafova koji su dostupni anonimnim korisnicima je znatno manji od onog koji se dobija

nakon registracije. Da bi se korisnik registrovao na sistem, nephodno je da otvori stranicu

Registration koja izgleda ovako:

Nakon unosenja potrebnih informacija jednostavnim click -om na dugme Submit poslace se

aktivacioni link na email adresu korisnika. Kada se nalog uspesno aktivira, povezivanje na

sistem je jednostavno, putem Login stranice.

Ukoliko je korisnik zaboravio svoju lozinku, moze da iskoristi mehanizam resetovanja (link

Forgot your password? )


Nakon uspesnog login-ovanja, otvaraju se vrata WebGraph sistema. Najvaznija stranica je

Run, koja predstavlja njegovu sustinu.

Ovde moze da se unese i validira zeljeni izraz, kao i da se izvrsi nad odredenim skupom grafova.

Rezultat izvrsenja je CSV fajl u kome se nalaze svi izabrani grafovi sa vrednostima True ili

False ukoliko odgovarajuci graf zadovoljava izraz ili ne.

Primetimo da korisnik ima mogucnost da izabere dva razlicita izvora grafova: fajl ili bazu.

U slucaju baze kao izvora, pretraga se vrsi nad posebnom WebGraph bazom koja je unapred

definisana od strane sistema i sadrzi veliki broj grafova i njihovih osobina. Sa druge strane ako

korisnik izabere fajl kao data source onda moze da upload -uje svoje .g6 fajlove i da ih kasnije

koristi. Za azuriranje WebGraph baze zaduzeni su administratori sistema, ali nije iskljucivo da

ovo postane buduca funkcionalnost za korisnike. Na raspolaganju je i sekcija Documentation u

kojoj je detaljno opisan WebGraph jezik i nacin na koji se njegovo koriscenje preporucuje.


Na kraju, ukoliko korisnik ima pitanja koja bi zeleo da postavi WebGraph timu, moze to da

uradi putem stranice Contact, na kojoj je takode prikazana adresa i tacna lokacija WebGraph

tima.


5.2 newGRAPH biblioteka

Biblioteka newGRAPH je napisana u programskom jeziku Java. Ona predstavlja srce sistema

i koristi se kao direktan interfejs za izracunavanje invarijanti grafova. Ova sekcija se ne bavi

samom bibliotekom i njenom detaljnom implementacijom, vec opisuje nacin na koji se ona

koristi. Prikazan je jednostavan primer koji ucitava model grafa na osnovu String-a koji je u

.g6 formatu, i kao rezultat vraca sve njegove cvorove.

1 import rs.ac.ni.pmf.newgraph.graphdata.Graph;2 import rs.ac.ni.pmf.newgraph.util.G6FormatManager;3 import rs.ac.ni.pmf.newgraph.graphdata.VertexData;4

5 String g6String = "??|e||x==-?"6 Graph graph = new Graph();7 graph.createFromAdjacencyMatrix(G6FormatManager.decode(graphString));8 GraphData graphData = graph.getData();9 Enumeration<VertexData> vertices = graphData.vertices()

Jasno je da klasa Graphmodelira graf. Klasa G6FormatManager i metod decode su korisni

jer omogucuju mehanizam import-ovanja .g6 String-a. Povezivanje grafa sa njegovom matricom

susedstva obezbeduje metod createFromAdjacencyMatrix. Korisna klasa je GraphData. Ona

sadrzi veliki broj funkcija koje mozemo da izvrsimo nad grafom. Da bi dobili objekat ove klase

koristi se metod getData. U konkretnom primeru metod vertices kao rezultat vraca listu svih

cvorova tog grafa. Dakle vise je nego ocigledan znacaj ove biblioteke. Naravno, ona zasluzuje

detaljnu analizu ali je moj cilj ovde bio da ukazem na njenu vaznost i sustinu, kao i da opisem

nacin na koji sam je koristio.

5.3 Gramatika

WebGraph poseduje svoju gramatiku za konstrukciju izraza nad grafovima. Za njeno kreiranje,

kao i za kreiranje parsera i interpretera, korisceni su alati JavaCC i JJTree. Nesto vise o

principima rada pomenutih alata je naglaseno u ranijoj sekciji koja se bavi prevodiocima i

interpretatorima, dok se ovde kroz konkretan primer pokazuje kako se oni zapravo koriste.

Sustina implementacije parsera, odnosno interpretera lezi u gramatici. U slucaju WebGraph-a,

leksicka specifikacija poput regularnih izraza, tokena i sl. kao i specifikacija same gramatike,

takozvana Bekusova normalna forma (BNF) se nalaze zajedno u jednom fajlu (definition.jjt).

Korisceni alati nalazu da to bude tako iz razloga jer je u tom slucaju pojednostavljeno citanje

gramatike i njenih pravila, pogotovu jer je dozvoljeno da se koriste regularni izrazi u okviru

same specifikacije gramatike. To takode daje vecu fleksibilnost i u mnogome olaksava kas-

nije odrzavanje. Tokeni koji su definisani kao specijalni se ignorisu prilikom parsiranja, ali su

dostupni za procesiranje na strani samih alata. Ovo je vrlo korisna cinjenica kada se radi o

procesiranju komentara.

WebGraph gramatika je vrlo intuitivna i dosta bliska terminologiji koja se koristi u teoriji


grafova. Primera radi graf se oznacava simbolom G a ivica simbolom e. Operatori su prirodno

uvedeni pomocu simbola: +,�, ⇤, /, <,<=, .... Kako jeWebGraph sistem opste namene, korisceni

su engleski nazivi. Na primer: NumberOfBridges (broj mostova u grafu), Diameter (di-

jametar grafa), IsHamiltonian (da li je graf Hamiltonov) itd.

Dakle, gramatika je vrlo prirodno uvedena sa ciljem da priblizi sistem profilu ljudi koji se

prvenstveno bave teorijom grafova. Evo i nekoliko primera validnih izraza u skladu saWebGraph

gramatikom.

1 G.IsEulerian and G.IsHamiltonian and G.CyclomaticNumber > 22 Sum(Edges(G), e.v.Degree * e.u.Degree) > Power(G.NumberOfEdges, 2)3 All(Eigonvalues(G), ev > 3)4 !G.IsHamiltonian && G.Delta < 5 || G.delta > 05 Sum(Vertices(G), v.NumTrianglesContaining) > Sum(Vertices(G), v.NumCliquesContaining)

5.4 Parser

JavaCC je parser generator koji je napisan u programskom jeziku Java. Kao rezultat parsiranja

on generise cist Java kod. Prilikom generisanja parsera JavaCC koristi takozvani Top-down

pristup, sto je u suprotnosti sa recimo alatima koji se izucavaju na studijama poput YACC -a.

Iako je ovde leva rekurzija zabranjena, ovaj pristup daje mogucnost rada sa nesto generalnijim

gramatikama. Takode, velika prednost Top-down parsera ogleda se u trazenju gresaka (eng.

debugging), jer pruza mogucnost parsiranja bilo kog neterminala u gramatici, kao i mogucnost

prosledivanja vrednosti tj. atributa u oba smera (up, down) kroz drvo parsiranja. Ovaj alat

dolazi u paketu sa alatom JJTree koji je veoma dobar za generisanje preprocesora tj. sintaksnog

stabla. Formalno, JavaCC generise LL(1) parser. Kako dakle izgleda WebGraph parser?

Pomocu specifikacije gramatike i pravila (definition.jjt), uz pomoc pomenutih alata, kao

rezultat generisanja parsera dobija se cist Java kod koji se nalazi u paketu

rs.ac.ni.pmf.newgraph.parser

Vrlo je bitno da se u okviru gramaticke specifikacije navede ime klase koja ce nakon gener-

isanja, predstavljati konkretan parser. U primeru koji se opisuje to je klasa

rs.ac.ni.pmf.newgraph.parser.NewGraphParser

ciji je najvazniji metod Parse.

1 final public SimpleNode Parse() throws ParseException2 {3 /* ... */4 }

On se zapravo koristi za validaciju izraza koji se unosi. Sledi primer njegove konkretne

upotrebe:


1 final public SimpleNode Parse() throws ParseException2 public Boolean validate(String expression)3 {4 StringReader reader = new StringReader(expression);5 NewGraphParser parser = new NewGraphParser(reader);6 Boolean result = Boolean.FALSE;7 try8 {9 parser.Parse();

10 result = Boolean.TRUE;11 }12 catch (ParseException e)13 {14 e.printStackTrace();15 }16 return result;17 }

Ukoliko nije doslo do greske prilikom izvrsavanja metode Parse, smatra se da je izraz validan.

U suprotnom, desice se ParseException sto dalje WebGraph sistem tretira kao nevalidan izraz.

Dakle, uloga parsera je da validira izraz. Medutim, validacija izraza i nije od neke koristi ukoliko

se isti ne izvrsi nad trazenim skupom grafova. Logika ovog izrsavanja nalazi se u WebGraph

interpreteru.

5.5 Interpreter

Generisanje parsera je od velike vaznosti kada je rec o validaciji izraza. Alati poput JavaCC i

JJTree omogucuju odredene mehanizme pomocu kojih je lako ugraditi sopstvenu logiku koja je

u stanju da se izvrsi prilikom parsiranja. Idealno bi bilo kada bi ”prolazom kroz graf” prilikom

parsiranja i obilaska sintaksnog stabla mogli da izvrsimo odredene akcije. Ovaj mehanizam

obezbeduje Java interface

rs.ac.ni.pmf.newgraph.parser.NewGraphParserVisitor

koji je takode kao i sam parser automatski generisan od strane pomenutih alata. Sama rec

Visitor gotovo da u potpunosti opisuje njegovu ulogu.

Drugim recima, dovoljno je kreirati gramaticku specifikaciju (definition.jjt), izvrsiti pomenute

alate nad njom i kao rezultat generisace se parser klasa i Visitor interface. JavaCC i JJTree

se mogu koristiti na vise razlicitih nacina. Kako je za realizaciju WebGraph sistema koriscen

eclipse (http://www.eclipse.org/) kao IDE, nakon instalacije takozvanih plugin-ova za rad sa

alatima JavaCC i JJTree, dovoljno je selektovati definition.jjt fajl i desnim klikom misa izabrati

opciju compile with javacc/jjtree...


NewGraphParserVisitor je dakle Java interface koji je sastavljen od metoda visit koje se

odnose na svaki od cvorova kroz koje parser prolazi prilikom parsiranja tj. obilaska sintaksnog

stabla. Ovaj mehanizam je idealan za ono sto se od interpretera ocekuje. U slucaju Web-

Graph interpretera, klasa rs.ac.ni.pmf.newgraph.execution.Interpreter je upravo ona klasa koja

implementira Java interface NewGraphParserVisitor.

Kao jednostavan primer, predstavljen je slucaj, kada je parser prilikom parsiranja, pronasao

cvor u grafu (eng. vertex), za koji se ocekuje da kao rezultat vrati listu njegovih suseda (eng.

Neighborhoods)

1 import rs.ac.ni.pmf.newgraph.parser.NewGraphParserVisitor2 import rs.ac.ni.pmf.newgraph.parser.ASTVNeighborhoods;3 import rs.ac.ni.pmf.newgraph.graphdata.VertexData;4

5 public class Interpreter implements NewGraphParserVisitor6 {7 /* ... */8 @Override9 public Object visit(ASTVNeighborhoods node, Object data)

10 {11 VertexData vertex = (VertexData) data;12 return vertex.getNeighbors();13 }14 /* ... */15 }

Primetimo da se na liniji 12 zapravo poziva metod biblioteke newGRAPH.


Sada je jasno na koji su nacin WebGraph parser i interpreter povezani sa newGRAPH

bibliotekom.

Postoji jos par metoda (setGraph, validate i execute), ciji je cilj da pojednostave interpreter

kao klasu koja se dalje moze koristiti od strane drugih servisa.

1 public class Interpreter implements NewGraphParserVisitor2 {3 private Graph _graph = new Graph();4 private Integer _counter = 0;5

6 public void setGraph(String graphString)7 {8 _graph.createFromAdjacencyMatrix(G6FormatManager.decode(graphString));9 }

10

11 public Boolean validate(String expression)12 {13 StringReader reader = new StringReader(expression);14 NewGraphParser parser = new NewGraphParser(reader);15 Boolean result = Boolean.FALSE;16 try17 {18 parser.Parse();19 result = Boolean.TRUE;20 }21 catch (ParseException e)22 {23 e.printStackTrace();24 }25 return result;26 }27

28 public Boolean execute(String graph, String expression) throws ParseException29 {30 StringReader reader = new StringReader(expression);31 NewGraphParser parser = new NewGraphParser(reader);32 SimpleNode parseResult = parser.Parse();33 setGraph(graph);34 Object val = this.visit(parseResult, null);35 return Boolean.parseBoolean(val.toString());36 }37

38 @Override39 public Object visit(SimpleNode node, Object data)40 {41 return node.jjtGetChild(0).jjtAccept(this, data);42 }43

44 @Override45 public Object visit(ASTParse node, Object data)46 {47 return node.jjtGetChild(0).jjtAccept(this, data);48 }49 /* ... */50 }


Od velike vaznosti je i metod execute koji u pomenutom primeru izvrsava sledeci scenario:

• Kao parametre prihvata graph kao String u formatu .g6 i expression kao String koji

predstavlja zeljeni izraz

• Najpre se kreira StringReader nad izrazom i prosledi se parseru na parsiranje.

• Kao rezultat parsiranja tj. izvrsenja metode Parse dobija se koren sintaksnog stabla grafa

kao objekat tipa SimpleNode

• Zatim se poziva metoda setGraph koja ima zadatak da interpreteru postavi vrednost grafa

kao lokalnu promenljivu koju kasnije moze da koristi prilikom obilaska grafa

• Poziva se metoda visit sa parametrom koji smo dobili parsiranjem. Preciznije, obilazi se

stablo sa pocetkom u korenu. Prilikom obilaska, u odredenim tackama bice izvrsene neke

od metoda iz biblioteke newGRAPH

• Konacno kao rezultat vraca se vrednost True ili False koja nam govori da li izabrani graf

zadovoljava zadati izraz ili ne.


5.6 Arhitektura

WebGraph arhitektura je dizajnirana u vise slojeva.

Prvi sloj sa kojim korisnik direktno dolazi u dodir jeste WEB. Izraz koji se unosi kao i

skup grafova se prosleduju dalje na obradu sloju Worker -a. Prosledivanje podataka se vrsi

pomocu komunikacijskog sloja Message Queue (putem slanja poruka). Konacno, Worker -i

imaju mogucnost citanja i upisa u relacionu bazu podataka ili fajl sistem po potrebi.

U ovoj sekciji detaljno je opisana svaka od pomenutih komponenti.

5.7 Frontend

Za realizaciju frontend -a koriscene su tehnologije: Java servlets, JSP, MVC kao dizajn patern,

HTML5, JavaScript (Ajax), jQuery, CSS itd. U ovom radu se ne opisuju same tehnologije, ali

se nesto vise o njima moze naci ovde:

• JSP - http://www.oracle.com/technetwork/java/javaee/jsp/index.html

• Servlets - http://docs.oracle.com/javaee/6/tutorial/doc/bnafd.html

• MVC - https://martinfowler.com/tags/model-view-controller.html

WebGraph frontend je struktuiran na principu MVC, sa napomenom da je kreiran sopstveni

MVC framework. MVC (Model View Controller) je dizajn patern koji se uveliko primenjuje na

WEB -u. Ideja ovakve arhitekture jeste da se sistem podeli na tri komponente: Model, View i

Controller.

http://www.oracle.com/technetwork/java/javaee/jsp/index.html

http://docs.oracle.com/javaee/6/tutorial/doc/bnafd.html

https://martinfowler.com/tags/model-view-controller.html


Model je deo sistema koji je zaduzen za rad sa podacima. Controller je komponenta koja

se bavi biznis logikom. View je komponenta koja dobija podatke od odredenog controller-a i

jednostavno ih prikazuje. Takode je zaduzena da potrebne informacije prosledi odgovarajucem

kontroleru za dalju obradu.

Bitno je da se napomene da je uveden jos jedan sloj u arhitekturi, takozvani ViewModel

sloj. Njegova uloga jeste da olaksa internu komunikaciju izmedju View -a i Controller -a.

Sa druge strane komponenta Model cija je osnovna uloga da obraduje podatke, je imple-

mentirana po principu Active record koji je cesto koriscen kao arhitekturalni patern kada je

baza podataka relaciona. Primera radi najrasprostranjeniji Python framework Django koristi

ORM - Object relational Mapper koji je zasnovan na ovom principu. Konkretno, ovaj deo je

predstavljen kao DAL - Data Access Layer koji za svaku od tabela u relacionoj bazi (MySQL)

ima poseban entitet. Konacno na samom korisnickom interfejsu su koriscene tehnologije poput:

HTML5, JavaScript (Ajax), jQuery, CSS, Bootstrap, SemanticUI itd.

Views. Ova komponenta je zaduzena za prikaz podataka, kao i za razmenu informacija sa

slojem controller -a. Svaki View je zasebna .jsp stranica.

Svaka od pomenutih .jsp stranica sadrzi HTML, CSS i JavaScript kod.

Takode treba napomenuti da se u fajlu web.xml nalazi XML konfiguracija koja opisuje

naslovnu stranicu (Home page) koju korisnik vidi kada prvi put poseti WebGraph.

1 <?xml version="1.0" encoding="UTF-8"?>2 <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"3 xmlns="http://java.sun.com/xml/ns/javaee"4 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"5 id="WebApp_ID" version="3.0">6 <welcome-file-list>7 <welcome-file>index.jsp</welcome-file>8 </welcome-file-list>9 ...


Controller -i su organizovani unutar posebnog paketa koji je odvojen od WEB sloja, sa

ciljem da se kasnije mogu iskoristiti u druge svrhe (ukoliko je primera radi potrebno da se

izradi WebGraph desktop aplikacija). Za svaku grupu view -ova postoji odgovarajuci controller.

Primer 5.7.1. Tako recimo za grupu views/account kojoj pripadaju: activateCompleted.jsp,

changePassword.jsp, changePasswordCompleted.jsp, forgotPassword.jsp, forgotPasswordCom-

pleted.jsp, login.jsp, register.jsp i registerCompleted.jsp, odgovara AccountController.

Nalaze se u okviru paketa rs.ac.ni.pmf.newgraph.web.controllers.

Ovaj sloj je veoma vazan jer predstavlja biznis logiku celog sistema. Napomenucu da je svaki

controller zapravo javax.servlet.http.HttpServlet. Takode je bitno da se naglasi da je konfigu-

racija koja povezuje odgovarajuci view sa constroller -om deklarisana u okviru web.xml fajla.

1 <servlet>2 <servlet-name>HomeController</servlet-name>3 <servlet-class>rs.ac.ni.pmf.newgraph.web.controllers.HomeController</servlet-class>4 </servlet>5 <servlet-mapping>6 <servlet-name>HomeController</servlet-name>7 <url-pattern>/home/*</url-pattern>8 </servlet-mapping>9

10 <servlet>11 <servlet-name>AccountController</servlet-name>12 <servlet-class>rs.ac.ni.pmf.newgraph.web.controllers.AccountController</servlet-class>13 </servlet>14 <servlet-mapping>15 <servlet-name>AccountController</servlet-name>16 <url-pattern>/account/*</url-pattern>17 </servlet-mapping>18

19 <servlet>20 <servlet-name>RunController</servlet-name>21 <servlet-class>rs.ac.ni.pmf.newgraph.web.controllers.RunController</servlet-class>22 </servlet>23 <servlet-mapping>24 <servlet-name>RunController</servlet-name>25 <url-pattern>/run/*</url-pattern>26 </servlet-mapping>


Na ovaj nacin se postize da URL-ovi WebGraph-a budu jednostavni sto u mnogome utice na

takozvanu SEO optimizaciju (https://en.wikipedia.org/wiki/Search_engine_optimization).

Osnovna klasa ovog sloja jeste rs.ac.ni.pmf.newgraph.web.controllers.WebController. Svaki

konkretan controller je u obavezi da je implementira.

Ona izgleda ovako:

1 @WebServlet("/WebController")2 public class WebController extends HttpServlet3 {4

5 private static final long serialVersionUID = 1L;6

7 public HttpServletRequest request = null;8 public HttpServletResponse response = null;9 public HttpSession session = null;

10

11 private void dispatchRequest(HttpServletRequest request, HttpServletResponse response);12

13 @Override14 protected void doGet(HttpServletRequest request, HttpServletResponse response) throws

ServletException, IOException;15

16 @Override17 protected void doPost(HttpServletRequest request, HttpServletResponse response) throws

ServletException, IOException;18

19 public void renderView(String view, Object model) throws ServletException, IOException;20

21 public void redirectToView(String view, Object model) throws ServletException,IOException;

22

23 public void jsonResponse(Object data) throws ServletException, IOException;24

25 }

Sustina ove klase jeste u tome da rutira zahteve ka odgovarajucim kontrolerima. Metod

koji je odgovoran za rutiranje je dispatchRequest koji kao argumente prihvata (HttpServle-

tRequest) i (HttpServletResponse). Kako je WebGraph u osnovi WEB aplikacija, citava ko-

munikacija odvija se putem HTTP protokola (https://www.w3.org/Protocols/rfc2616/

rfc2616.html). Od znacaja su nam GET i POST zahtevi za ciju obradu su zaduzene metode

doGET i doPOST respektivno. Takode postoje i metode za komunikaciju sa view -ovima:

renderView, redirectToView, jsonResponse. Napomenucu da su za implementaciju rutiranja

koriscene napredne tehnike u Java-i poput refleksije, kao i poseban pomocni paket package

rs.ac.ni.pmf.newgraph.utils.

https://en.wikipedia.org/wiki/Search_engine_optimization

https://www.w3.org/Protocols/rfc2616/rfc2616.html

https://www.w3.org/Protocols/rfc2616/rfc2616.html


U ovom paketu se nalaze rutine za rad sa JSON formatom, neki od kriptografskih algoritama

koji su korisceni radi postizanja sigurnosti i sl.

ViewModels. Skup svih modela koji sluze za internu komunikaciju view -ova i controller -a

se nalazi u posebnom paketu rs.ac.ni.pmf.newgraph.web.viewmodels.

I ovde kao kod controller -a postoji apstraktna klasa ViewModel koju svaki konkretan model

mora da implementira.

Models. Konacno preostaje da se opise sloj koji se bavi obradom podataka i komunikacijom

sa bazom. Implementacija ovog sloja prati Active record dizajn patern. Podeljen je u dva

paketa: rs.ac.ni.pmf.newgraph.dal.entities i rs.ac.ni.pmf.newgraph.dal.


Paket rs.ac.ni.pmf.newgraph.dal.entities sadrzi osnovne modele koji predstavljaju mapiranja

na konkretne tabele u relacionoj bazi podataka. Kao izbor za relacionu bazu podataka, iz-

abran je MySQL, ali je sistem veoma lako konfigurisati da radi sa bilo kojom drugom rela-

cionom bazom. Takode je veoma lako podici sistem na nivo gde bi MySQL zamenili cloud

resenjem, recimo na AWS -u (RDS ). Ovo unapredenje je ostavljeno po strani jer prevazilazi

okvire ovog rada, ali je bitno da se napomene da je sistem sposoban da lako prede cak i

na ovakvu arhitekturu koja bi sigurno poboljsala performanse, sigurnost i stabilnost. Dakle,

rs.ac.ni.pmf.newgraph.dal.entities.Entity predstavlja apstrakciju entiteta tj. tabele u bazi.

Svaki od modela mora da je implementira. Sa druge strane, srce WebGraph ORM -a pred-

stavlja klasa

rs.ac.ni.pmf.newgraph.dal.DataAccess

koja je interfejs ka samoj bazi podataka. Njen posao je da vodi racuna o konekcijama ka bazi, da

izvrsava upite i sl. I ovde, konkretna implementacija DAL - Data Access Layer -a za odredeni en-

titet, mora da implementira apstraktnu (i genericku) klasu rs.ac.ni.pmf.newgraph.dal.DataAccess.

1 public class Category extends Entity { ... }2 public class Categories extends DataAccess<Category> { ... }3 ArrayList<Category> categories = new ArrayList<Category>();4 categories = Categories.objects().getAll();

U ovom primeru klasa rs.ac.ni.pmf.newgraph.dal.Categories koja predstavlja DAL za entitet

rs.ac.ni.pmf.newgraph.dal.entities.Category je duzna da implementira klasu

rs.ac.ni.pmf.newgraph.dal.DataAccess bas za taj konkretan model (entitet).


5.8 Backend

Ovo je najslozenija komponenta sistema. Sastoji se od takozvanog Message Broker -a cija je

jedina uloga da na pouzdan, brz i siguran nacin obezbedi prenos poruka izmedu komponenti. Sa

druge strane postoji veliki broj Worker -a cija je uloga ili da generisu nove poruke (Producers)

ili da slusaju tj. cekaju na njihovo pojavljivanje (Consumers), pri cemu je bitno da reaguju po

prijemu poruke tako sto izvrsavaju odredene akcije.

Kao implementaciono resenje problema komunikacijskog kanala koriscen je RabbitMQ (https:

//www.rabbitmq.com/). RabbitMQ je mozda jedno od najpouzdanijih resenja danas. Izuzetno

je brz, besplatan je (open source), omogucuje asinhroni mehanizam komunikacije, ima veliki

broj biblioteka za sirok spektar programskih jezika, takode omogucuje takozvani distributed

deployment, vrlo lako se skalira. Takode se lako instalira u cloud okruzenju, stavise pos-

toji vec gotovo cloud resenje (https://www.cloudamqp.com/). Koristi ga gotovo svaka od

danasnjih velikih IT kompanija. Takode ima veliki broj alata za management i profiling. Zas-

novan je na AMQP protokolu (http://www.amqp.org/) Ono sto je jos jedna od mnogobrojnih

prednosti RabbitMQ-a je sto se pomocu njega mogu realizovati razni algoritami komunikacije:

WorkQueues, Publish/Subscribe, Routing, Topics, RPC itd. Listu najbitnijih komunikacijskih

protokola mozete pronaci na ovoj lokaciji https://www.rabbitmq.com/getstarted.html.

Struktura fajlova u kojima se nalazi implementacija je:

Ovaj deo sistema moze da se podeli na dve komponente: Communication i Execution.

Communication. Zaduzen je iskljucivo za komunikaciju izmedu procesa. Paket koji sadrzi

implementaciju je rs.ac.ni.pmf.newgraph.communication. Najbitnije klase su MessageCon-

sumer i MessagePublisher. Kao sto samo ime kaze, klasa MessageConsumer je zaduzena za

uzimanje poruka sa Message queue-a dok je MessagePublisher zaduzen za generisanje novih

poruka.



https://www.rabbitmq.com/getstarted.html


rs.ac.ni.pmf.newgraph.communication.MessageConsumer

1 public class MessageConsumer<T>2 {3

4 private Connection _conn;5 private Channel _channel;6 private QueueingConsumer _consumer;7 private Class<T> _klass;8 private String _queueName;9

10 public MessageConsumer(Class<T> klass) throws IOException11 {12 _klass = klass;13 Properties config = new Properties();14 InputStream inputStream =

getClass().getClassLoader().getResourceAsStream("app.properties");15 config.load(inputStream);16 String broker = config.getProperty("rmq.broker");17 ConnectionFactory factory = new ConnectionFactory();18 factory.setHost(broker);19 _conn = factory.newConnection();20 _channel = _conn.createChannel();21 _queueName = "qeue.for." + _klass.getName();22 _channel.queueDeclare(_queueName, false, false, false, null);23 // very important - prefetch count, number of messages that consumer can24 // read at once25 _channel.basicQos(1);26 _consumer = new QueueingConsumer(_channel);27

28 _channel.basicConsume(_queueName, true, _consumer);29 }30

31 public T getMessage() throws ShutdownSignalException, ConsumerCancelledException,InterruptedException

32 {33 Delivery delivery = _consumer.nextDelivery();34 String message = new String(delivery.getBody());35 T obj = JsonHelper.deserialize(message, _klass);36 return obj;37 }38

39 /* ... */40 }

U slucaju MessageCosumer klase se kroz konstruktor prosleduje objekat koji zapravo pred-

stavlja tip tj. klasu. Zasto je ovo vazno? Ideja je bila da sve poruke koje su istog tipa prolaze

kroz jedan isti komunikacijski kanal (queue), tako da je ovde iskoriscen naziv klase za generisanje

imena queue-a. Parameteri za povezivanje na takozvani host tj. message broker (RabbitMQ)

se citaju iz app.properties. Dalje se kreira konekcija nad kojom se otvara komunikacijski kanal.

Kada je komunikacijski kanal kreiran ostaje da se deklarise queue i da se zapocne sesija konzu-

miranja poruka. Od velike je vaznosti parametar koji se prosleduje metodi basicQos. U nasem

slucaju to je 1. On se zargonski naziva prefetch count i predstavlja informaciju prema brokeru


koja opisuje nacin na koji ce se citanje poruka obavljati. U nasem konkretnom slucaju 1 znaci

da ce se citanje obavljati poruka po poruka. Napomenucu da je sasvim legitimno postaviti ovaj

parametar na neki veci broj, mada je heuristika da ovaj broj ne prelazi 10 jer se u suprotnom

moze doci u situaciju da se procitaju vise poruka istovremeno za koje je potrebno duze vreme

da se obrade, pa se tako moze smanjiti protocnost kanala. Dakle odluka da prefetch count

bude 1 je vise nego opravdana. Ono sto je olaksavajuca okolnost RabbitMQ-a je to sto njegova

implementacija sama garantuje perzistentnost poruka, kao i redosled pristizanja. Ukoliko se

prefetchCount postavi na vrednost vecu od 1 onda potrebno obezbediti mehanizam ocuvanja

redosleda poruka. Postoje nacini i principi gde se ovo moze podesiti drugacije ali to prevazilazi

temu ovog rada. Poslednja stvar koja je veoma bitna jeste da protokol citanja poruka sa kanala

ocekuje da consumer javi brokeru da je obradio poruku, takozvani ack - acknowledge. Ukoliko se

ack ne desi za predefinisano vreme, komunikacijski kanal smatra da je doslo do greske (timeout)

i poslatu poruku vraca nazad u kanal kao neobradenu. Dakle metod getMessage() je zapravo

zaduzen za citanje poruka. Format poruka koji se prosleduje kroz kanal je proizvoljan, te sam

se odlucio za JSON. Naravno, u skladu sa potrebama veoma je lako promeniti ga. Prednost

JSON formata u odnosu na druge (recimo XML) je u tome sto se lako i brzo de/serijalizuje,

sto ne zauzima veliki memorijski prostor i sto je citljiv ljudskom oku. Dakle jednostavnim

pogledom na poruku covek moze jasno da vidi i razume njen sadrzaj. Sa druge strane neki

drugi formati (binarni) poput BSON -a (http://bsonspec.org/) jesu bolji u smislu perfor-

mansi ali su sa druge strane nerazumljivi ljudskom oku sto dodatno otezava kasniji debugging.

Dakle citanje poruke sa queue-a se svodi prakticno na JSON deserijalizaciju. Napomenucu

da je takode moguce uneti dodatnu redudansu nad porukama koje kruze kroz kanal, tako sto

se na transportnom nivou uvede enkripcija. Dakle, ukoliko je potrebno da se postigne velika

sigurnost, poruke se mogu enkriptovati i kao takve slati kroz kanal. Postupak slanja poruka je

opisan sledecom klasom:

http://bsonspec.org/


rs.ac.ni.pmf.newgraph.communication.MessagePublisher

1 public class MessagePublisher<T>2 {3

4 private Connection _conn;5 private Channel _channel;6 private String _queueName;7 private Class<T> _klass;8 private BasicProperties _props;9

10 public MessagePublisher(Class<T> klass) throws IOException11 {12 _klass = klass;13 Properties config = new Properties();14 InputStream inputStream =

getClass().getClassLoader().getResourceAsStream("app.properties");15 config.load(inputStream);16 String broker = config.getProperty("rmq.broker");17 ConnectionFactory factory = new ConnectionFactory();18 factory.setHost(broker);19 _conn = factory.newConnection();20 _channel = _conn.createChannel();21 _queueName = "qeue.for." + _klass.getName();22 _channel.queueDeclare(_queueName, false, false, false, null);23 _props = new BasicProperties();24 _props = _props.builder().deliveryMode(2).build();25 }26

27 public void publishMessage(T message) throws IOException28 {29 String json = JsonHelper.serialize(message);30 _channel.basicPublish("", _queueName, _props, json.getBytes());31 }32

33 /* ... */34 }

MessagePublisher je kako to ime samo kaze klasa koja je zaduzena za slanje poruka. Pos-

tupak kreiranja konekcije i kanala prema brokeru je veoma slican kao kod citanja. Ono sto je

bitno jeste metod publishMessage koji kao parametar prihvata genericki tip T . Vrlo je vazno da

je moguce serijalizovati objekat ovog tipa u zeljeni format (JSON ). Da bi ovako serijalizovanu

poruku poslali kroz kanal potrebno je da koristimo metod basicPublish i da mu prosledimo

poruku kao niz bajtova. Treba istci da je postupak slanja poruke na kanal izuzetno brz tj. da

je gotovo nemoguce doci u situaciju da slanje poruka postane usko grlo. Uglavnom se problemi

uskog grla kod slanja poruka na kanal svode na problem serijalizacije samih poruka. Serijal-

izacija u slucaju velikih poruka moze da bude kako vremenski tako i CPU zahtevna. U slucaju

WebGraph-a ovaj problem je resen tako sto je izracunata maksimalna velicina poruke tj. niza

poruka (message chunk), tako da ukoliko je potrebno poslati nesto vecu poruku ona ce biti

podeljena na manje i kao takva (podeljena) biti poslata na obradu u takozvanim chunk -ovima.

Parametar koji opisuje ovu velicinu je konfigurabilan. Njegova konkretna vrednost se nalazi u


konfiguracijskom fajlu app.properties u okviru sekcije chunk size i u nasem slucaju je 100.

U WebGraph sistemu ulogu consumer -a ima klasa Worker koja dobija objekat WorkItem-

Request na obradu. WorkItemRequest sadrzi sve potrebne informacije: izraz koji je potrebno

izvrsiti kao i listu grafova (kao listu Graph entiteta). Napomenimo da je velicina ove liste

pazljivo odabrana i direktno je povezana sa velicinom koju sam gore opisao (chunk size). Sa

druge strane klasa TaskQueue je interna implementacija raspodele taskova na manje celine

sa ciljem da se postignu bolje performanse. Sustinski je ovo jednostavna logika ciji je cilj da

inicijalni zahtev koji moze da sadrzi veliki broj grafova jednostavno podeli na manje celine,

formalno vrsi se deljenje po modulu chunk size. Kada se incijalni task podeli na manje celine,

svaki deo se salje na obradu putem komunikacijskog kanala. Nakon slanja poruke ovaj servis

se oslobada i spreman je da prihvati druge zahteve.

Da bi sistem bio jos robusniji, uveden je jos jedan sloj u komunikaciji. Rezultat izvrsavanja

izraza nad odredenim skupom grafova je fajl. Kako je fajl kao resurs veoma skup u dis-

tribuiranim sistemima, i kako sam inicijalno podelio obradu jednog zadatka na manje celine koje

se putem komunikacijskog kanala prosleduju na dalju obradu drugim komponentama sistema

(Worker -ima), potrebno je rezultate te obrade na neki nacin sakupiti na jedno mesto, tacnije

u zeljeni fajl. Jasno je da su Worker -i zasebni procesi tj. niti (eng. threads) koje zive u zaseb-

nim procesima na zasebnim masinama koje mogu biti geografski na razlicitim lokacijama. Ako

uzmemo ovu cinjenicu u obzir onda je i vise nego jasno da Worker -i jednostavno nisu u stanju

da kreiraju zeljeni fajl. Jedno od najoptimalnijih resenja ovog problema jeste distribuirani fajl

sistem ili cak neko od cloud resenja poput S3 - AWS (https://aws.amazon.com/s3/) ili pak

AFS - Azure(https://azure.microsoft.com/en-us/services/storage/files/).

U slucaju WebGraph-a problem je resen na sledeci nacin. Svaki Worker, kada zavrsi obradu

generise rezultat kao GraphExecutionResponse. Onog trenutka kada je rezultat spreman, on se

dalje salje(takode kroz komunikacijski kanal) poslednjoj komponenti u komunikaciji (Output-

Worker). OutputWorker je dakle jos jedan tip consumer -a, koji slusa na posebnom queue-u.

Njegova uloga jeste da prihvati rezultat i da ga jednostavno upise u odgovarajuci fajl. Ovakva

implementacija ima ogranicenje u smislu da consumer -i koji kreiraju fajlove jednostavno moraju

da budu na istoj masini. Vrlo je bitno da se napomene da ukoliko je sistem podesen da ima vise

od jednog OutputWorker -a, moze doci do sinhronizacijskih problema prilikom upisa u fajl. Ovo

moze da se resi na nivou samog fajl sistema, ali je najbolje resenje da se koristi mehanizam dis-

tribuiranog LOCK -a poput Zookeeper -a (https://zookeeper.apache.org/) Trenutno WebGraph

sistem ne podrzava vise od jednog OutputWorker -a ali je veoma lako prosiriti ovu komponentu

na gore opisan nacin.

Konacno, treba napomenuti da suWorker -i i OutputWorker -i zargonski receno umotani kao

konzolne aplikacije: AgentConsole i OutputAgentConsole. Dakle pokretanje agenata je veoma

jednostavno i svodi se na startovanje .jar fajla iz terminala.


Kako je ova komponenta pisana u programskom jeziku Java koji je u stanju da se izvrsava

na razlicitim platformama tj. operativnim sistemima (eng. cross platform), citav WebGraph

backend je dakle nezavisan u smislu platforme i bez problema se moze izvrsavati na Linux-u,

OSX -u ili Windows-u (ili ostalim pratformama na kojima je dostupna Java).


5.9 Logovanje

Ukoliko dode do nekih neocekivanih gresaka u sistemu ili otkaza pojedinih komponenti veoma

je bitno da se na brz nacin ustanovi uzrok problema i resi. Upravo iz ovih razloga vazno je

uspostaviti stabilan sistem logovanja. On mora da bude brz, jednostavan i pouzdan. Takode

je potrebno da pruza mogucnost konfiguracije formata logova (JSON, XML i sl).

Sa ciljem da WebGraph zadovolji pomenute potrebe, izaberana je biblioteka log4j

(https://logging.apache.org/log4j/2.x/) Logovanje se vrsi u fajl i console-u. Log fajlovi

se rotiraju, sto zapravo znaci da kada se log fajl popuni do odredene velicine (u nasem slucaju

5MB), kreira se novi log fajl i dalje logovanje se nastavlja u novom fajlu. Konkretna konfigu-

racija logera se nalazi u log4j.properties fajlu.

1 # Root logger option2 log4j.rootLogger=DEBUG, stdout, file3

4 # Redirect log messages to console5 log4j.appender.stdout=org.apache.log4j.ConsoleAppender6 log4j.appender.stdout.Target=System.out7 log4j.appender.stdout.layout=org.apache.log4j.PatternLayout8 log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n9

10 # Redirect log messages to a log file, support file rolling.11 log4j.appender.file=org.apache.log4j.RollingFileAppender12 log4j.appender.file.File=newgraphLogs/newgraph.log13 log4j.appender.file.MaxFileSize=5MB14 log4j.appender.file.MaxBackupIndex=1015 log4j.appender.file.layout=org.apache.log4j.PatternLayout16 log4j.appender.file.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n

Vazno je napomenuti da kada je rec o distribuiranim sistemima, vrlo cesto se javi potreba

da se sistem logovanja podigne na visi nivo. Zato postoje takozvani log agregatori kao ex-

tern-i servisi. Poznatiji log agregatori su: loggly (https://www.loggly.com/), sumologic

(https://www.sumologic.com/), logentries (https://logentries.com/).Dakle, Prednost log

agregatora je u tome sto donose veliku sigurnost sistemu. Sa druge strane pruzaju pouzdan

sistem kolaboracije gde veliki broj ljudi moze da posmatra i pretrazuje logove kako u realnom

vremenu tako i radi statistike. Takode svaki poznatiji log agregator pruza odlican aplikativni

interfejs API (recimo u vidu RESTfull servisa).

https://logging.apache.org/log4j/2.x/

https://www.loggly.com/

https://www.sumologic.com/

https://logentries.com/


5.10 Konfiguracija

Jedna od veoma bitnih osobina jednog sistema jeste konfigurabilnost. Ona se ogleda u tome

koliko brzo i jednostavno je moguce promeniti ponasanje sistema a da pritom sistem natavi da

radi nesmetano iz perspektive korisnika. Citava konfiguracija WebGraph sistema je opisana u

fajlu app.properties

1 # database settings2 db.server=33.33.33.113 db.port=33064 db.name=newgraph5 db.username=newgraph6 db.password=QG.>(wQFR*a8^nd7

8 # email settings9 mail.smtp.host=smtp.gmail.com

10 mail.smtp.port=58711 mail.username=newgraph.pmf.ni.ac.rs12 mail.password=m!w,TNcw+Z\;5q+h13 [email protected]

15 # rmq16 rmq.broker=localhost17

18 # execution19 task.chunk.size=10020 output.files.root=c:/projects/webgraph/newgraph/WebContent/output/

Dakle, kao sto se moze videti, moguce je podesitiDatabase server, takode je moguce konfigurisati

administratorsku email adresu, komunikacijski kanal (RMQ) kao i nacin izvrsavanja i podele

taskova na manje atomicne celine.

Glava 6

Zakljucak

Ovaj rad je posledica mog dugogodisnjeg iskustva u IT industriji kao inzenjera, kao i temeljnih

studija i saznanja koja sam stekao na tom putu. Njegov cilj je da ukaze na neke od mnogobro-

jnih tehnika i problema prilikom dizajniranja i implementacije arhitukture jednog distribuira-

nog sistema. Koriscena je web aplikacija za distribuiranu pretragu grafova kao primer jedne

od realizacija gore pomenutog izazova. Zalazi se donekle u oblast teorije prevodioca i inter-

pretatora gde se pokazuje jedan od nacina na koji se moze konstruisati parser i interpreter za

proizvoljnu gramatiku. Jezik koji je deklarisan se koristi za generisanje izraza za pretrazivanje

grafova. Ukazuje se na razlicite ideje i pristupe u okviru WEB programiranja i detaljnije se

opisuje jedan od arhitekturalnih pristupa na WEB-u (MVC - Model View Controller). Nesto

veca paznja je posvecena samoj komunikaciji i sinhronizaciji izmedu komponenti u okviru dis-

tribuiranih sistema. Takode su opisane neke od najstabilnijih i siroko koriscenih tehnologija

danasnjice.

Dakle, ovaj rad bi trebao da bude dobra polazna tacka za dalje proucavanje distribuiranih

sistema, takode se nadam da ce u mnogome pomoci naucna istrazivanja iz oblasti teorije grafova.

Postoji jos mnogo toga sto nisam obuhvatio. Potrebno je detaljno izuciti specificnosti svake od

pomenutih tehnologija. Sa druge strane postoji veliki broj knjiga, naucnih radova na ovu temu,

blog-ova, raznovrsnih IT konferencija itd. Problem koji je opisan je izuzetno tezak. Razvoj i

uvodenje distribuiranih sistema po prirodi unosi veliki broj ozbiljnijih i vecih izazova. Vrlo je

bitno, u toku razvoja ovakvog sistema, voditi racuna o tome da su komponente koje ga cine

sklone otkazu i sa takvim pristupom dizajnirati arhitekturu.

Buducnost WebGraph-a bi se ogledala u optimizaciji pojedinacnih komponenti sistema kao

i u razvoju novih funkcionalnosti.

Konacno, izazov jeste veliki, ali je sa razlogom. Distribuirani sistemi nisu vestacki uvedeni,

vec su proizvod realnih ljudskih potreba kojima se danasnje vodece IT kompanije aktivno bave.

45

Literatura

[1] Diestel, Reinhard, Graph Theory, 2017 Springer

http://www.springer.com/gp/book/9783662536216

[2] Alfred V. Aho, Columbia University, Monica S. Lam, Stanford University, Ravi Sethi,

Avaya Labs, Compilers: Principles, Techniques, and Tools, 2nd Edition, 2007 Je↵rey D.

Ullman, Stanford University

[3] RabbitMQ documentation


[4] JavaCC Parser generator

https://javacc.org/

46

Прилог 5/1ПРИРОДНO - MАТЕМАТИЧКИ ФАКУЛТЕТ

НИШ

КЉУЧНА ДОКУМЕНТАЦИЈСКА ИНФОРМАЦИЈА!Редни број, РБР:

Идентификациони број, ИБР:

Тип документације, ТД: монографскаТип записа, ТЗ: текстуални / графичкиВрста рада, ВР: мастер рад Аутор, АУ: Далибор АлексовМентор, МН: Марко МилошевићНаслов рада, НР: Web Graph

Дистрибуирани систем за претрагу графоваЈезик публикације, ЈП: српскиЈезик извода, ЈИ: енглескиЗемља публиковања, ЗП: Р. СрбијаУже географско подручје, УГП: Р. СрбијаГодина, ГО: 2017Издавач, ИЗ: ауторски репринтМесто и адреса, МА: Ниш, Вишеградска 33.Физички опис рада, ФО:(поглавља/страна/ цитата/табела/слика/графика/прилога) 49 стр. ; граф. прикази

Научна област, НО: рачунарске наукеНаучна дисциплина, НД: дистрибуирани системи / веб програмирањеПредметна одредница/Кључне речи, ПО: граф, компајлер, интерпретатор, дистрибуирани

системи, вебУДК 519.17

519.179.2Чува се, ЧУ: библиотекаВажна напомена, ВН:

Извод, ИЗ: У раду сy представљене технике и принципи имплементације дистрибуираних система кроз веб апликацију "WebGraph" са детаљним описом начина рада и архитектуре.

Датум прихватања теме, ДП: 04.07.2017Датум одбране, ДО:

Чланови комисије, КО: Председник:

Члан:

Члан, ментор:

Образац Q4.09.13 - Издање 1

Прилог 5/2ПРИРОДНO - MАТЕМАТИЧКИ ФАКУЛТЕТ

НИШ

KEY WORDS DOCUMENTATION!Accession number, ANO:

Identification number, INO:

Document type, DT: monographType of record, TR: textual / graphicContents code, CC: university degree thesis (master thesis)Author, AU: Dalibor AleksovMentor, MN: Marko MiloševićTitle, TI: Web Graph

Distributed graph search systemLanguage of text, LT: SerbianLanguage of abstract, LA: EnglishCountry of publication, CP: Republic of SerbiaLocality of publication, LP: Serbia Publication year, PY: 2017Publisher, PB: author’s reprintPublication place, PP: Niš, Višegradska 33.Physical description, PD:(chapters/pages/ref./tables/pictures/graphs/appendixes) 49 p. ; graphic representations

Scientific field, SF: computer scienceScientific discipline, SD: distributed systems / web programmingSubject/Key words, S/KW: graph, compiler, interpreter, distributed systems, web

UC 519.17519.179.2

Holding data, HD: libraryNote, N:

Abstract, AB: The thesis represents techniques and principles of distributed systems implementations through the web application "WebGraph" with detailed manual and architecture description

Accepted by the Scientific Board on, ASB: 04.07.2017Defended on, DE:

Defended Board, DB: President:

Member:

Member, Mentor:

Образац Q4.09.13 - Издање 1

Documents

Web Graph - pmf.ni.ac.rsunarske... · vaˇzno dobiti odgovore na ova pitanja u ˇsto kra´cem vremenskom roku. Inteligentne aplikacije i sistemi se baziraju na povezanosti izmed¯u